# MySQL Databases > Create databases and users for an account, and work with the data directly from the panel — browse, inspect structure, run SQL and watch activity. Source: https://www.corepanel.net/docs/accounts/databases/ Last updated: 2026-08-09 Part of the CorePanel documentation — https://www.corepanel.net/docs --- CorePanel manages MySQL/MariaDB databases per account: the account owns its databases, its database users, and the limit on how many it may create. A built-in database manager lets you work with the data without installing phpMyAdmin. ## Naming: everything is prefixed Database and user names are always prefixed with the account's system username: ``` account "example" + suffix "shop" → database example_shop account "example" + suffix "app" → user example_app ``` You type the suffix; CorePanel builds the full name. This is what keeps two accounts from colliding on a shared MySQL server, and it means a name you see in a config file tells you which account owns it. Suffixes may contain letters, digits and underscores. The **full** name is limited by MySQL: 64 characters for a database, 32 for a user — the prefix counts. ## Creating a database From **Databases** (pick the account) or the account workspace's **Databases** section: 1. **Create database** — enter the suffix. 2. **Create user** — enter a suffix, a password, the host and the privileges. A database with no user is not reachable by an application; a user is created against a database and granted privileges on it. ### Users and hosts A MySQL user is identified by *name plus host*. The host defaults to `localhost`, which is what an application running on this same server needs. The same suffix can exist for different hosts, but not twice for the same one. Privileges are chosen when the user is created and can be changed afterwards, along with the password. ### Limits Database creation is capped by the account's *MySQL databases* limit (`0` = unlimited). When the limit is reached, creation is refused until a database is deleted or the limit raised. ## The database manager Opening a database from the list gives you a full manager with five views: | View | What it does | |---|---| | **Overview** | Size, table count, engine and collation, at a glance | | **Browse** | Paginated table data, sortable, with row add / edit / delete | | **Structure** | Columns, types, keys, indexes and `CREATE TABLE`; create and alter tables | | **SQL** | Run a statement against the database | | **Activity** | Live process list, with the ability to kill a query | Editing rows requires a **primary key** on the table — without one there is no safe way to address a single row, so the manager offers reading only. ### The SQL console is deliberately narrow Statements are parsed and classified before they run, and anything outside the allowed shapes is refused rather than passed through: | Allowed | Refused | |---|---| | `SELECT`, `SHOW`, `DESCRIBE`, `EXPLAIN SELECT` | Anything else — including `WITH` (CTEs) | | `INSERT`, `UPDATE`, `DELETE`, `REPLACE` | `SELECT … INTO`, `INTO OUTFILE`, `INTO DUMPFILE` | | `CREATE`, `ALTER`, `DROP`, `TRUNCATE`, `RENAME` on tables | `CREATE/ALTER/DROP USER` or `ROLE` | | | `CREATE/ALTER/DROP DATABASE` or `SCHEMA` | | | The same statements written `CREATE OR REPLACE …` | | One statement per run | Multiple statements in one run; executable version comments (`/*! … */`) | Statements are also capped at 8 KB. Write statements are recorded in the audit log; reads are not. > **Why user and database management is blocked here** > > Creating MySQL users from the console would produce users CorePanel does not know about — > unprefixed, unattached to any account, invisible in the panel and left behind when the > account is deleted. Creating or dropping a **database** is the same problem with a sharper > edge: a schema dropped from the query box leaves its CorePanel row behind, so the panel > goes on listing a database that is not there. Do both through the panel, where the change > is recorded. ### Importing and exporting a dump **Export** and **Import** sit in the manager's header, next to the database name. They are the way a database moves in or out without a shell. **Export** asks first. The button opens a dialog that says what the file will contain and what producing it costs; the dump starts when you confirm, not when you press the button. That is on purpose: a dump reads every row of the database through the MySQL instance every site on the server shares, and Export sits on a screen people open to look around. A click made to find out what a button does should not be able to start it. Once confirmed, it produces a `mysqldump` of that one database and downloads it as `-.sql.gz`. It is taken with `--single-transaction`, so the site keeps serving while it runs, and it carries table definitions, data, routines, triggers and events — but no `CREATE DATABASE`. The file is built on the spot, so on a large database the dialog waits for minutes rather than seconds; the download then starts on its own. ![The database manager for example_shop, with Export and Import buttons in the top-right of its header. The Import dialog is open over the workspace: it names the target schema, warns in amber that a dump normally recreates the tables it carries so any table of the same name is replaced, shows the chosen file shop-20260801-0300.sql.gz at 18.4 MB, and a progress bar reading "Uploading… 64%" with "11.8 MB of 18.4 MB received" beside it.](https://www.corepanel.net/_astro/database-import-export.BsFy5F-j.svg) **Import** takes a `.sql` or a `.sql.gz` and loads it into the database you are looking at. The file is uploaded in pieces, so it is not bound by the web server's POST limit and a dropped connection costs one piece rather than the whole transfer; the ceiling is **512 MB** per dump. Whether the file is compressed is detected from its contents, not from its name. > **Caution** > > A dump normally recreates the tables it carries, so **any table of the same name in the > target database is replaced**. Export first if you are not sure what is in there. The database is never created by an import — it has to exist first, and you pick it from the panel. That is not a limitation of the uploader: the dump is loaded through a throwaway MySQL user granted privileges on that one schema and nothing else, so a dump carrying `CREATE DATABASE`, a `GRANT`, or a write into another schema meets an engine that refuses it. `LOAD_FILE` and `INTO OUTFILE` get nothing for the same reason. It is the same boundary a migrated account's dump is loaded through, and it applies to an administrator's import exactly as it does to a customer's. One export runs per account at a time, and a handful across the server, because a dump reads every row of a database through the MySQL instance every account shares. > **Stored routines, triggers and events** > > The same confinement has one consequence worth knowing before you meet it. `mysqldump` > writes a `DEFINER=` clause on every routine, trigger and event, and setting a definer other > than yourself requires the `SUPER` privilege — which the loader deliberately does not have. > So a dump that carries them fails with an access-denied error naming `DEFINER`. > > Most applications have none (WordPress, Joomla, Laravel and friends do not), so this is > uncommon. When it happens, remove the clauses before importing: > > ```bash > sed -E 's/DEFINER=`[^`]*`@`[^`]*` //g' dump.sql > dump-nodefiner.sql > ``` > > The routines then belong to whoever loads them. A database that genuinely depends on > definer-based security is a case for the shell, not for the panel. > **Moving a whole account** > > Import/export here is one database. To move an account with its files, mail and DNS, use > [backups](https://www.corepanel.net/docs/backups) or the [cPanel importer](https://www.corepanel.net/docs/import-cpanel). ### Activity The **Activity** view shows what MySQL is doing right now and lets you kill a runaway query — the first thing to look at when a site becomes slow and you suspect the database rather than PHP. ### The manager in the client panel On Business, the account owner reaches this same manager over their own databases from the [client panel](https://www.corepanel.net/docs/client-panel) — Overview, Browse, Structure, the SQL console and import/export, with reads and writes. **Activity is the exception** and stays administrator-only: the process list belongs to the whole MySQL instance, so it shows other accounts' statements while they run, credentials included. What confines a customer is MySQL, not a filter on their SQL. Each account gets a panel-owned MySQL user holding privileges on exactly the databases its rows say it owns, created the first time the manager is opened — there is nothing to provision when you upgrade a server. Their statements run as that user, so a schema they do not own is refused by the engine however the statement is written, and `information_schema` shows them only their own. Dropping a database revokes that privilege at the same time, which matters because you are free to create the same database name again for a different account. That connection also carries a **statement timeout and a row ceiling**. Privileges cannot stop an unindexed join over a large table, and that costs every account on the box, so the bound is a property of the connection rather than an option in the console. ## Connecting from an application Standard MySQL connection settings: | Setting | Value | |---|---| | Host | `localhost` | | Database | `_`, e.g. `example_shop` | | Username | `_`, e.g. `example_app` | | Password | The one you set | For WordPress, [installing through the WordPress Manager](https://www.corepanel.net/docs/wordpress) creates the database, the user and the credentials for you. ## Deleting Deleting a database drops it from MySQL along with its users, and frees the account's counter. Deleting an account drops **all** of its databases and users from the MySQL server, not just CorePanel's records of them. > **Caution** > > Deletion is immediate and there is no undo. A database only exists in a > [backup](https://www.corepanel.net/docs/backups) if a backup was taken before the deletion.