Azure SQL, PostgreSQL, and MySQL: Choosing and Operating Relational Databases

Azure offers managed relational engines for SQL Server-compatible, PostgreSQL, and MySQL workloads. Choose the engine for application compatibility, team skill, extension/features, licensing, migration path, and ecosystem. Then choose a service tier by measured CPU, memory, I/O, storage, connections, availability, backup, and recovery needs.

Lab: 45–60 minutes · Cost: database compute, storage, backups, network, replicas, and logs can charge continuously · Safety: choose the smallest learning tier and delete it promptly.

Which relational service should you choose?

Do not choose only from benchmark headlines. Run the real query mix with realistic data and concurrency.

How can you deploy an Azure SQL database securely?

Ways to build

Choose the Azure tool you want to use. The underlying resource stays the same.

Azure portalAzure CLI

Azure portal

Search for the chosen database service → Create. Set subscription/group, server and database names, region, workload tier, authentication, networking, backups, redundancy, maintenance, encryption, and tags.

For production:

• Prefer Entra authentication and managed identity.
• Use private access and correct private DNS.
• Disable broad public firewall rules.
• Configure zone redundancy where available and justified.
• Set backup retention and geo-recovery from RPO/RTO.
• Enable auditing, threat detection, metrics, and query-performance tools.

Azure CLI

Use this Azure SQL learning skeleton, replacing the Entra administrator placeholders with an authorized identity:

bash

WrapCopy

SQL_SERVER="sql-northstar-REPLACE_UNIQUE" SQL_DATABASE="sqldb-northstar-dev" az sql server create \ --resource-group "$AZURE_RG" \ --name "$SQL_SERVER" \ --location "$AZURE_LOCATION" \ --enable-ad-only-auth true \ --external-admin-principal-type User \ --external-admin-name "REPLACE_ENTRA_NAME" \ --external-admin-sid "REPLACE_OBJECT_ID" az sql db create \ --resource-group "$AZURE_RG" \ --server "$SQL_SERVER" \ --name "$SQL_DATABASE" \ --service-objective Basic \ --backup-storage-redundancy Local

Flags and tier availability change. Use the current service quickstart and never pass an administrator password on the command line.

PostgreSQL and MySQL have separate az postgres flexible-server and az mysql flexible-server command groups. Their engine parameters, extensions, high availability, replicas, and connection behavior differ; do not treat them as renamed SQL Database.

How should applications connect?

Use managed identity/Entra token authentication where supported. If a password remains necessary, store it in Key Vault and rotate it. Configure connection pooling below database limits, set command/connect timeouts, retry only transient errors, and use parameterized queries.

Serverless application scaling can create a connection storm. Put a connection budget into the architecture: maximum app replicas × pool size must fit the database with headroom for operations.

How do schema changes reach production safely?

Use versioned migrations and the expand/migrate/contract pattern:

1. Add backward-compatible schema.
2. Deploy code that can use old and new forms.
3. Backfill data with observable batches.
4. Switch reads/writes.
5. Remove the old schema only after rollback is no longer required.

Never make a deployment slot swap responsible for reversing a destructive database migration.

What do Bicep and Terraform declare?

Server, database, identity administrator, private endpoint and DNS, security settings, diagnostic settings, alerts, backup/retention, and optional replicas/failover groups. Keep database schema in a migration system, not ARM/Bicep. Protect Terraform state and avoid plaintext credentials.

How do you design backup and recovery?

Managed backups support point-in-time restore within retention. Long-term retention and geo-restore vary by engine/tier. A backup is not validated until a restore drill proves the data, permissions, connection changes, DNS, and application startup path.

Measure:

• Query latency percentiles and error rate.
• CPU, memory where exposed, I/O, storage, sessions/connections.
• Deadlocks, lock waits, slow queries, replica lag.
• Backup/restore readiness and capacity trend.

Cleanup

Delete the isolated resource group and confirm retained backups or long-term retention do not remain under a separate lifecycle. Remove Entra app identities only if the lab created them and they are unused.

Official references

• Azure SQL documentation
• Azure Database for PostgreSQL
• Azure Database for MySQL
• Azure database migration guides