What makes a good database name?
A database name is infrastructure glue: it appears in connection strings, backup filenames, monitoring dashboards and 2 a.m. incident threads. The right name saves you typing and confusion for years; the wrong one taxes every single query. Here is what actually matters.
1. Short and lowercase
Keep names short enough to type without thinking — under 32 characters is a good ceiling, and single digits are ideal. Lowercase is not just style: PostgreSQL folds unquoted identifiers to lowercase, so MyDatabase becomes mydatabase unless you quote it everywhere. Mixed case is a permanent quoting tax. Use lowercase everywhere and skip the problem entirely. See our database naming conventions page for the per-engine details.
2. Descriptive of what is inside
For production databases, the name should answer "what lives here?" at a glance. billing, shop_orders and analytics all pass. db1, test and newdb fail — six months later nobody remembers what db1 holds, and renaming a live database is one of the most annoying migrations you will ever run. The description does not need to be exhaustive: the domain or bounded context is enough.
3. Consistent with your other databases
One naming scheme per organization. If your first database is atlas_billing, the next one should be atlas_catalog, not BillingDB2. Consistency makes automation trivial: scripts that provision backups, rotate credentials or spin up read replicas can assume a pattern instead of carrying a lookup table. Write the pattern down — even a five-line conventions doc beats tribal knowledge.
4. Environment-aware, not environment-confused
When the same logical database exists in several environments, mark the environment with a suffix: shop_dev, shop_staging, shop_prod. What you should not do is encode the environment twice (prod_shop_production) or hide it in the server hostname alone, because connection strings get copied between environments and mistakes follow. If you only ever run one database per server, skip the suffix and keep the name clean.
5. Free of reserved words and special characters
Avoid SQL reserved words — select, table, order, user — as database names. Some engines accept them with quoting, all of them punish you later. Stick to letters, digits and underscores. Never start with a digit, and never use spaces or hyphens unless you enjoy quoting identifiers for the rest of the project's life.
Good vs bad database names
| Good | Why it works |
|---|---|
atlas_billing | Short, lowercase, says what it holds, groups under a project prefix. |
shop_staging | Environment is explicit in the name. |
harbor_analytics | Descriptive but generic enough to survive scope creep. |
| Bad | What goes wrong |
|---|---|
MyProductionDB | Mixed case forces quoting in PostgreSQL. |
order | Reserved word — quoting required everywhere. |
final-db-v2-real | Hyphens need quoting; version history in a name rots fast. |
When a random name is the right name
Not every database deserves a descriptive name. Sandboxes, workshop demos, tutorial databases and throwaway test fixtures are used for hours or days — for those, a memorable random name like crimson_fox is perfect: unique enough to never collide, meaningless enough to never mislead. Our free database name generator produces exactly these, in snake_case, PascalCase, camelCase or kebab-case, with optional dev/staging/prod trios.
For the full rulebook across engines, continue to database naming conventions, or browse database name examples to see the patterns applied.