SQL MI vs SQL Database
| Feature | SQL Database | SQL Managed Instance |
|---|---|---|
| SQL Server Agent | ❌ No | ✅ Yes |
| Linked Servers | ❌ No | ✅ Yes |
| CLR Integration | Limited | ✅ Yes |
| Database Mail | ❌ No | ✅ Yes |
| Cross-database queries | ❌ No | ✅ Yes |
| Service Broker | ❌ No | ✅ Yes |
| VNet deployment | Optional (Private Endpoint) | Required — always in VNet |
| Max database size | 4 TB (GP), 4 TB (BC) | Up to 16 TB (GP), 4 TB (BC) |
| Instance-level features | No — database only | Yes — instance-level access |
Features Exclusive to SQL MI
- SQL Server Agent — Schedule and automate SQL jobs (ETL, maintenance, alerts)
- Linked Servers — Query remote databases from SQL Server
- CLR Integration — Run .NET code inside SQL Server
- Database Mail — Send emails from SQL Server
- Cross-database queries — Query across multiple databases on the same instance
- Service Broker — Asynchronous messaging between databases
- Distributed transactions — MSDTC support
- Native backup/restore — Restore .bak files from Azure Blob Storage
Migration Decision Rule If your on-premises SQL Server app uses SQL Agent, linked servers, CLR, or cross-database queries → use SQL Managed Instance. If it's a simple database without these features → SQL Database is sufficient and cheaper.
VNet Deployment
Unlike SQL Database (which has a public endpoint by default), SQL Managed Instance is always deployed inside a VNet — it has no public endpoint. This is both a security feature and a requirement. The MI is deployed into a dedicated subnet within your VNet.
Dedicated Subnet Required SQL Managed Instance requires its own dedicated subnet — no other resources can be in that subnet. The subnet must be large enough for the number of instances and must have service delegation configured for Microsoft.Sql/managedInstances.
Service Tiers
| Tier | Storage | IOPS | Best For |
|---|---|---|---|
| General Purpose | Up to 16 TB | Up to 7,500 | Most production workloads |
| Business Critical | Up to 4 TB | Up to 120,000 | High IOPS, built-in read replica, in-memory OLTP |
Migration to SQL MI
Azure Database Migration Service (DMS) supports online migration (minimal downtime) to SQL MI:
- Assess source SQL Server compatibility with Azure Database Migration Service
- Configure DMS with source (on-premises) and target (SQL MI) connections
- Run initial full migration (while source is running)
- Apply ongoing log backups to keep MI in sync
- Cutover — stop new writes on source, final sync, switch connection strings
Native backup/restore is also supported — backup databases to Azure Blob Storage and restore directly to SQL MI.
Business Continuity
- Automated backups — Full/differential/log backups with PITR (1–35 days)
- Auto-failover groups — Geo-replication with automatic failover to secondary region
- Business Critical tier — Built-in Always On availability group with one readable secondary (no extra cost)
- Zone redundancy — Deploy across Availability Zones for 99.99% SLA
SQL MI vs SQL on VM
| Factor | SQL Managed Instance | SQL Server on VM |
|---|---|---|
| Management | Microsoft manages OS, SQL patches, HA | You manage OS, patches, HA |
| Feature compatibility | Near-full SQL Server | Full SQL Server — every version/feature |
| Specific SQL version | No — Microsoft controls version | Yes — run SQL 2012, 2016, etc. |
| Legacy/unsupported features | Some not supported | All supported |
| Choose when | Want managed service, near-full compatibility | Need specific version or unsupported feature |
AZ-104 Exam Tip Know that SQL MI is always deployed in a VNet (no public endpoint). Know it supports SQL Agent, linked servers, CLR, cross-database queries. Know that Auto-Failover Groups enable automatic geo-failover. Know that the Business Critical tier includes a free built-in readable secondary.