Azure SQL Naming Conventions: Servers, Databases, and Managed Instances

An Azure SQL server name becomes a public DNS name (yourserver.database.windows.net), so it must be globally unique, 1 to 63 characters, lowercase letters, numbers, and hyphens only: sql-payments-prod-eus-001. Databases live inside the server and are far more relaxed (up to 128 characters), so keep them short and purpose-named, like sqldb-orders.

Azure SQL naming is really two different problems. The server is a globally visible DNS endpoint with strict rules. Everything inside it (databases, elastic pools) is privately scoped with generous rules. Treating both the same way leads to either rejected server names or bloated database names.

The pieces and their rules

Resource	CAF prefix	Max length	Characters	Unique within
SQL server	sql	63	Lowercase letters, numbers, hyphens	All of Azure (global)
SQL database	sqldb	128	Almost anything except <>*%&:\/?	Its server
Elastic pool	sqlep	128	Almost anything except <>*%&:\/?	Its server
SQL Managed Instance	sqlmi	63	Lowercase letters, numbers, hyphens	All of Azure (global)
Failover group	commonly fog	63	Lowercase letters, numbers, hyphens	All of Azure (global)

The pattern behind the strict rows: anything that becomes a DNS hostname (.database.windows.net) inherits DNS rules, lowercase, no underscores, globally unique, and it can’t start or end with a hyphen.

Naming the server

Use the full CAF pattern, exactly like a resource group or Key Vault:

sql-{workload}-{environment}-{region}-{instance}

Scenario	Server name
Payments, production, East US	sql-payments-prod-eus-001
Payments, dev	sql-payments-dev-eus-001
HR portal, staging, West Europe	sql-hrportal-stage-weu-001

Because the name is globally unique, a generic name like sql-app-prod-001 may already be taken by another company. The region abbreviation and instance number add entropy; adding a short company prefix (sql-cnts-payments-prod-eus-001) adds more.

Naming databases inside the server

The server name already carries workload, environment, and region. Repeating all of that in every database name doubles the length and adds nothing, sql-payments-prod-eus-001/sqldb-payments-prod-eus-001 tells you nothing twice.

Instead, name databases after their logical purpose:

sql-payments-prod-eus-001
├── sqldb-orders
├── sqldb-billing
└── sqldb-reporting

This keeps connection strings readable and makes the database list self-explanatory in the portal. The same logic applies to elastic pools: sqlep-standard or sqlep-workloads inside a server beats a full CAF chain.

One exception: if your team routinely moves databases between servers (export/import, cross-server copies), include the workload (sqldb-payments-orders) so a database name stays meaningful outside its server.

Managed instances

SQL Managed Instance follows the same DNS-driven rules as the server, 1 to 63 characters, lowercase, hyphens allowed:

sqlmi-payments-prod-eus-001

Managed instance names are painful to change (the DNS zone is derived from them), and provisioning takes hours, so getting the name right the first time matters even more than usual here.

Failover groups and multi-region

A failover group name also becomes a DNS name: fog-payments-prod.database.windows.net is what your applications connect to, and it follows the group to whichever region is primary. That makes it the one name in the SQL family that should NOT contain a region:

Servers:  sql-payments-prod-eus-001   (primary, East US)
          sql-payments-prod-wus2-001  (secondary, West US 2)
Group:    fog-payments-prod           (region-neutral, follows the failover)

Put the region in the server names, never in the failover group name. See the multi-region naming guide for the wider pattern.

MySQL and PostgreSQL flexible servers

Same DNS logic, slightly different bounds: 3 to 63 characters, lowercase letters, numbers, and hyphens, globally unique.

Service	CAF prefix	Example
Azure Database for MySQL	mysql	mysql-payments-prod-eus-001
Azure Database for PostgreSQL	psql	psql-payments-prod-eus-001
Cosmos DB for PostgreSQL	cospos	cospos-payments-prod-eus-001

Terraform example

resource "azurerm_mssql_server" "main" {
  name                         = "sql-${var.workload}-${var.environment}-${var.region}-001"
  resource_group_name          = azurerm_resource_group.main.name
  location                     = azurerm_resource_group.main.location
  version                      = "12.0"
  administrator_login          = "sqladmin"
  administrator_login_password = var.sql_admin_password
}

resource "azurerm_mssql_database" "orders" {
  name      = "sqldb-orders"
  server_id = azurerm_mssql_server.main.id
  sku_name  = "S1"
}

The server name is built from variables so every environment derives it the same way; the database name stays short and logical.

Common mistakes

Uppercase in server names. SQL-Payments-Prod is rejected at deployment. Lowercase is not a style preference here, it’s a hard rule inherited from DNS.

Region in the failover group name. The group spans regions by design; naming it fog-payments-prod-eus becomes a lie the moment you fail over.

Full CAF chains on databases. A database named sqldb-payments-prod-eus-001 inside sql-payments-prod-eus-001 repeats four components for zero information gain.

No entropy in global names. Short generic server names collide with other tenants. Keep the region and instance number even when they feel redundant.

Summary

• Server and managed instance names are DNS names: 63 characters, lowercase, hyphens, globally unique
• Databases and elastic pools are server-scoped: keep them short and purpose-named
• Failover group names are region-neutral by design
• Build server names from variables in IaC, and add entropy for global uniqueness

Full rules per resource: SQL server, SQL database, managed instance. AzureNamer generates all of them with the right constraints applied.