Reseller playbook · Beginner · 5 minutes
How to create a MySQL database — Naming Conventions That Survive the Third Developer
In two years somebody who has never met you will open this account looking for the right database, and what you type today decides how long that takes.
Straight answer first
Creating the database, the user and the grant takes five minutes with the wizard; the decision that matters is the name, because on a reseller account the same convention has to make sense across dozens of client accounts and to whoever inherits them.
cPanel prefixes every database with the account name, which separates clients from each other automatically. What it cannot do is tell you which application a database belongs to, and that half is yours.
Written by the Hosting Seller staff · Checked 24 August 2026
Beginner
Skill assumed
5 minutes
Per database
5
Stages to a convention
24/7
Cover at any hour
Written for whoever will still be administering these accounts in two years. It assumes several client accounts, multiple applications inside some of them, and developers who come and go.
The five-minute version of this job is in every hosting manual. The parts worth reading here are credential ownership and what happens at handover.
The prefix does half your filing for you
cPanel adds the account's own prefix to every database and user, so two clients can both have a database called 'shop' without ever colliding. That is a genuine convenience of the per-account model and it means you never have to encode the client name yourself.
What the prefix does not tell you is what the thing is for. Pick a convention for the part you choose — the application, then the environment if there is more than one — and use it on every account. Six months on, 'db1' and 'test' are pure guesswork, and guesswork on a live client database is how afternoons disappear.
Credentials: yours, the client's, or the developer's
Decide the policy rather than deciding per project. The workable position is that database credentials are infrastructure and belong in your password manager, with the client's own record kept in whatever the client uses, and developers given credentials created for them rather than the ones the application uses.
The failure mode this prevents is the common one: a freelancer holds the only copy of a working credential, disappears, and reappears as a locked-out client eighteen months later. Because you can always reset a database password from the panel this is recoverable, but recovery means downtime on a site that was working fine.
One database per application, per account, no exceptions
Sharing a database between two applications saves nothing measurable and turns every backup, restore and clean-up into a negotiation about which rows belong to whom. On a client account where you may one day need to restore only the shop, that negotiation happens under pressure.
It also keeps the grant simple. Applications expect complete control of their own database, and a restricted user has real uses — a read-only reporting login for a client's analyst, say — but the application's own credential is not one of them.
What migrates cleanly when the client leaves
A cPanel account backup carries the databases with it, which is why the panel choice matters commercially: a client leaving you can be handed a standard archive that restores onto any cPanel host anywhere. Saying that openly tends to make renewal conversations shorter rather than longer.
Keep the four connection values in the client file: host, database name, username, password. Every installer ever written asks for exactly those, and having them recorded turns a migration into an afternoon instead of an archaeology project.
Why per-account separation is the point
Every client sits in a cPanel account of its own, which is what makes database prefixes, quotas and restores per client possible at all.
Because the panel is cPanel, a backup you take restores onto any cPanel host — a portability argument worth making to a cautious client before they ask.
- Prefixes that separate clients automatically
- A credential policy set once, not per project
- One database per application, always
- Backups that restore anywhere cPanel runs
Why Hosting Seller
On every plan, as standard
Names that still make sense later
A convention for the part you choose, so the third developer to open the account is not guessing.
Separation handed to you
Per-account prefixes mean two clients can use the same obvious name without ever colliding.
A credential policy
Settles who holds which password before a freelancer becomes the only copy of one.
Restores that stay narrow
One database per application means you can put back a client's shop without touching anything else.
The grant, explained
Says when a restricted user is right and why the application's own login is not the place for it.
Portability as a selling point
cPanel backups restore onto any cPanel host, which is an argument worth making before a client asks.
First Steps
From choosing to live
- 1
Use the wizard so the grant is never forgotten
It runs the three jobs in order — database, user, privileges — and the third is the one that gets skipped when this is done by hand. A missing grant reports as 'access denied', which reads exactly like a wrong password.
- 2
Name it for the application, on your standard convention
The account prefix already identifies the client, so the part you type should say what the database holds and, if it matters, which environment. Apply the same convention on every account you administer.
- 3
File the generated password where policy says
Let the panel generate it, then put it in your password manager and into the application's config. Developers get credentials created for them rather than a copy of the one the application uses.
- 4
Grant full rights on that database only
The application owns its own database and nothing else. Restricted users are for people — a client's analyst wanting read-only access — not for the application that has to run migrations.
- 5
Record the four connection values in the client file
Host, database name, username, password. Every installer asks for those four, and having them written down is what turns a future migration into an afternoon rather than an investigation.
In the Box
Packed with every plan
- A cPanel of their own for every client, WHM for you
- cPanel, the panel the rest of the trade already knows
- Daily backups across every client account
- Restores you run yourself from the panel
- NVMe SSD storage on every reseller tier
- LiteSpeed caching at the server, not bolted on by plugin
- Imunify360 on guard on every client site
- You set the limits each client account gets
- Site migration done for you by our staff, at no charge
- Real people answer, for you and for them
Across the Counter
Things people ask us all the time
Should a client's database password live in my password manager or theirs?
Both, with yours as the operational copy. It is infrastructure you maintain, so you need it without asking; the client should hold a record because it is their data. What you should avoid is a freelancer holding the only working copy of anything.
A client's developer wants remote MySQL access — is that reasonable?
It is, with two conditions: their address is added under Remote MySQL deliberately rather than left open, and they connect with a user created for them rather than the application's own credential. Remote access is off by default for exactly this reason.
Can a client's account hold more than one website?
Yes, and from the Pro tier upward that is a supported pattern — several sites, each with its own domain, mailboxes and certificate under one account. Where the sites belong to different businesses rather than one client, separate accounts give each proper separation.
How does billing work if I am reselling this?
The reseller platform is ready to wire into WHMCS billing, so provisioning and invoicing your own customers can run automatically rather than by hand. Setup on the reseller plan costs nothing, and the renewal price on the tag matches the order price.
Read next
Secure Hosting
Imunify360, account isolation and hardened defaults for the client who asks about security.
Web Hosting
cPanel hosting on NVMe with SSL, migration and year-one domain — the single-site option.
Moving your site to another host? Start with this checklist.
A step-by-step order of work for a move your visitors never spot: which files to copy first, how to carry email across without losing one message, the right moment to repoint DNS, and the two mistakes behind nearly every hour of downtime people ring us about.
Run client accounts you can hand over.
cPanel per client, WHM for you, daily backups per account and restores you run without a ticket.
See Secure Hosting plans