How to pick a good database name
Your database name shows up in connection strings, dashboards, backups and incident threads, so a small amount of care pays off. A good name is short, lowercase and descriptive: atlas_billing beats db1 and it beats MyProductionBillingDatabase2024. Lowercase with underscores is the safest choice across PostgreSQL, MySQL and SQLite — it avoids quoting issues and case-sensitivity surprises.
Separate environments with a suffix rather than a whole new scheme: atlas_shop_dev, atlas_shop_staging, atlas_shop_prod. When you only run one database per server, skip the environment suffix entirely and keep it clean. Our generator above can produce dev/staging/prod trios from one base word so your environments stay consistent. For the full breakdown, see our guide to good database names and the database naming conventions reference.
Popular naming patterns
Domain + purpose
billing_prod, shop_analytics — pairs what the database holds with where it runs.
Memorable word pairs
crimson_fox, harbor_lantern — great for side projects and sandbox databases.
Environment trios
atlas_dev / atlas_staging / atlas_prod — one base, three consistent variants.
Database naming FAQ (quick reference)
| Question | Short answer |
|---|---|
| snake_case or camelCase? | snake_case, lowercase. PostgreSQL folds unquoted identifiers to lowercase; mixed case forces quoting everywhere. |
| How long can a database name be? | PostgreSQL allows 63 bytes, MySQL 64 characters, SQL Server 128. Keep names under 32 characters for readability. |
| Can I use hyphens? | Only if you always quote the name. Hyphens need quoting in every query, so underscores are safer. |
| Should the name say what is inside? | Yes for production databases (billing, shop). For throwaway sandboxes, memorable random names are fine. |