Applies toAzure SQL Database, Azure SQL Managed Instance, SQL Server on Azure VMs, Azure Database for PostgreSQL and MySQL flexible servers, Azure Cosmos DB
Two separate decisions
- Engine: SQL Server, PostgreSQL, MySQL, or a NoSQL model? Usually set by the application, vendor support or team skills.
- Hosting: fully managed PaaS, near-full compatibility PaaS, or IaaS VM? Set by compatibility needs and how much you want to operate.
SQL Server workloads
Uses instance-level features (SQL Agent jobs, cross-database queries, CLR, Service Broker, linked servers, DB Mail)?
├─ no → Azure SQL Database (single or elastic pool)
└─ yes → Supported in Managed Instance?
├─ yes → Azure SQL Managed Instance
└─ no (OS access, SSRS/SSAS on same box, unsupported features, vendor requires VM) → SQL Server on Azure VM
| SQL Database | Managed Instance | SQL on VM | |
|---|---|---|---|
| Patching, backups, HA | Platform | Platform | You (with helpers like SQL IaaS extension) |
| Compatibility with on-prem SQL Server | Database-scoped | Near-full instance | Full |
| Network | Public or private endpoint | Inside your VNet (dedicated subnet) | Your VNet |
| Scale model | vCore/DTU, serverless, Hyperscale | vCore instance | VM size + disks |
| Typical use | New apps, SaaS, modernised apps | Lift-and-shift with instance features | Vendor apps, full control |
Run the Data Migration Assistant / Azure Migrate assessment for blockers before deciding.
Open-source engines
| Need | Option |
|---|---|
| PostgreSQL app, managed | Azure Database for PostgreSQL flexible server |
| MySQL app, managed | Azure Database for MySQL flexible server |
| Extensions not available on the managed service | PostgreSQL on VM / AKS operator (you operate it) |
| Distributed PostgreSQL for very large multi-tenant | Check the current distributed options (e.g. elastic clusters) |
Check the supported extensions list early (pgvector, PostGIS, TimescaleDB-type needs). It's the most common blocker.
Cosmos DB: when it fits
- Global distribution with multi-region writes, single-digit-ms reads at scale.
- Document/key-value access patterns with a good partition key.
- Variable or huge scale where autoscale RU/s or serverless suits the traffic.
It's a poor fit for relational reporting, ad-hoc joins, or teams expecting SQL Server behaviour. Design the partition key and access patterns first. Fixing them later means migrating data.
Things to decide with the database, not after
| Topic | Decide |
|---|---|
| HA | Zone redundancy / HA option and its cost |
| DR | Geo-replication, failover groups, geo-restore. Target RPO/RTO |
| Network | Private endpoint or VNet injection; DNS |
| Identity | Entra ID authentication, managed identities for apps |
| Backups | Retention, long-term retention, restore testing |
| Cost | Tier, reserved capacity, licence benefits |
Design review questions
- What's the RPO/RTO, and does the chosen tier meet it without custom work?
- What does the app do during a failover (retry logic, connection strings)?
- How big will it be in three years, and does the tier's maximum size cover it?
- Who tunes queries and indexes?
Tip
"Managed" doesn't mean "no DBA work". Query tuning, index design, capacity and access reviews still need an owner on every option.
Checklist
- Engine chosen by application and support needs
- Hosting chosen after compatibility assessment
- Extensions/features verified on the managed option
- HA, DR, network, identity and backup designed with it
- Ownership of tuning and capacity assigned