Azure SQL Database vs SQL Managed Instance
Verdict: Instance-scoped features decide: cross-database queries, SQL Server Agent, Service Broker or CLR force Managed Instance - no Azure SQL Database tier supplies them. Minimal-downtime migrations to MI go online via DMS; SQL Database only migrates offline.
| Criterion | Azure SQL Database | Managed Instance |
|---|---|---|
| Compatibility | Database-scoped engine surface | Close to 100% SQL Server compatibility - Agent, cross-database queries, Service Broker, CLR |
| Network | Public endpoint, optional Private Endpoint | Native VNet presence in a delegated subnet |
| DMS migration | Offline only | Online supported - source stays available until cutover |
| SQL vulnerability assessment | Express configuration GA | Express still preview - Classic with customer-managed storage |
| Choose when | New cloud-native apps | Lift-and-shift of instance-feature-dependent estates with minimal rewrite |
Rules
- Choose Managed Instance when the estate uses cross-database queries, SQL Server Agent, Service Broker or CLR - Business Critical and Hyperscale tiers of SQL Database omit all four.
- Choose DMS online migration to Managed Instance for multi-terabyte production cutovers - SQL Database only supports offline via DMS.
- Enable SQL vulnerability assessment Express on SQL Database (GA); on Managed Instance it is still preview, so Classic with a customer-managed storage account applies.
Traps
- Hyperscale is still Azure SQL Database - tier upgrades never add Agent, Service Broker or cross-database queries.
- Data Migration Assistant assesses; it does not migrate multi-terabyte workloads - that is DMS's job.