When creating a new database, one of the first decisions you’ll make is what to name it. The database name may not seem like a big deal, but following naming conventions and best practices from the start will save you headaches down the road. In this post, I’ll walk through guidelines on crafting clean, consistent database names that clearly communicate purpose and adhere to organizational standards.

Use Descriptive Names That Are Easy to Understand

Database names should be descriptive enough that another developer could reasonably guess the content and purpose of that database based on the name alone. Vague, ambiguous names like “DB1” or “TestDatabase” tell the user nothing. Instead, opt for names like “CustomerAccounts” or “ProductInventory” that immediately give cues as to the data contained. Resist the urge to shorten names too extremely—a few extra characters are worth it for the boost in clarity.

Good	Bad
CustomersUSA, InventoryManagement, FinancialReports	DB1, TestDB, MyDatabase

Reflect Structure, Domain and Content

By incorporating some aspect of structure, domain, or content into the name, you can differentiate similar databases at a glance. For example, “Customers_NoSQL” and “Customers_SQL” signals that two customer databases exist, one in NoSQL and one in SQL format. Names indicating regionality (NorthAmericanSales, EuropeUsers) or environment (ProductionDB, TestInstance) prevent confusion of similar databases used for different contexts.

Good	Bad
Products_MySQL, Customers_NoSQL, EuropeSalesData	PrimaryDB, NewDB, SQLDatabase

Follow Conventions and Patterns

Most organizations will have existing naming conventions for databases—learn these early on! Databases at a medical company may follow patterns like “AppName_Entity_Environment” while a tech company uses “Service-Purpose-Number”. Consistently naming databases according to prevailing company conventions makes them easily identifiable. When no conventions exist, establish a logical pattern early so schemas stay consistent as new databases are added.

Good	Bad
APPNAME_Table_Dev, Service-Purpose-01, PatientRecords_Prod	My_Database_1, DB_Test1, DataTables

Use Separators Effectively

In multi-word database names, choose separators carefully. Hyphens, underscores, and camelCase are common separators—pick one style and use it consistently across databases. Spaces in names should generally be avoided, as these can cause issues when a database name is used in scripts or code. Aim to strike a balance—you want readability but also need names that are usable in technical contexts.

Good	Bad
App-Users-Table, inventory_db, customerDatabase	App Users Table, inventorydb, customerDataBase

Avoid Abbreviations When Unclear

Resist abbreviating words in the database name unless the abbreviation is widely known across the organization. For example, “ProdDB” is likely short for Production Database while “UATDB” may leave some scratching their heads. Spell out words instead of using obscure or niche abbreviations and acronyms to keep names intuitive.

Good	Bad
ProductSupportDatabase	ProdSuppDB

Steer Clear of Special Characters

Stray from special characters like @, #, &, *, $, ! in database names. These characters can sometimes cause unexpected errors or problems in SQL statements if not properly escaped. To minimize this possibility, restrict database names to only alphanumeric characters, hyphens and underscores.

Good	Bad
AppData2021, query_processor	#userdata@2021, $query&processor

Keep Overall Length Reasonable

Database management systems often set a maximum character length for database names—for example, 64 characters in MySQL and 128 characters in SQL Server.Aim to keep names comfortably under the limit, providing ample buffer if the business requires database name changes down the road. Also avoid overly long names that stretch the character limit, negatively impacting readability.

Good	Bad
authentication_token_db	userauthenticationencryptedtokenstorage

Avoid Hardcoding the Database Name

Hardcoding the database name into application code comes back to bite engineers again and again. This requires updating code every time the database name changes—and it will change! Use configuration files or environment variables instead to avoid this headache. Promote these best practices across teams to minimize hardcoding database names.

Good	Bad
Configure database connection in separate file	sql_database = “CustomerDB”

Consider Future Expansion

Will this database only be used by internal employees or will external partners eventually access it too? Will analytics teams want to pull data into a data warehouse? Think 5 years ahead—if the database scope or user base expands, will the name still make sense? Pick names that allow room to grow rather than becoming obsolete.

Good	Bad
NorthAmericaSales, RegionalEnergyUse	MyCompanySales, ElectricalConsumption

Plan a Standard Prefix for Groups

As the number of databases grows, identifying groups and relationships becomes key. Using consistent prefixes is an easy way to spot databases in the same application, domain or environment. For example, databases prefixed with HR_ inherently indicate they belong to the HR application suite. Standard prefixes make organizing and searching databases much easier.

Good	Bad
ACCT_payable, ACCT_receivable, HR_payroll	payroll_db, accounting123, accounts999

Document Naming Conventions

Catalog any naming conventions, prefixes or standards used in a central spot for easy reference. Update documentation if standards change. This helps onboard new team members faster while serving as an ongoing reference for veteran employees. Including database naming guidelines in the developer handbook or wiki helps cement conventions.

Good	Bad
Store naming rules on wiki/central repository	Fail to document naming standards

Set Permissions Thoughtfully (Additional Thought)

While this is a security concern rather than naming convention, it is important to emphasize that Database admins should proactively grant the minimum permissions needed rather than opening up full access from the start. As an application developer, explicitly state the permissions groups required for database access during the planning process. Provide as narrow access as possible while still meeting business needs.

Good	Bad
Assign select/insert roles to groups that need access	Grant all privileges to all users

Naming databases effectively involves balancing brevity and clarity, considering technical limitations, and standardizing across the organization. Following these best practices will set you on the right path to naming databases cleanly. Have any other database naming tips? Let me know in the comments!