Azure SQL Database vs Managed Instance vs SQL on VM: Complete Platform Selection Guide

Azure SQL Database (SQL DB): single-database PaaS, the most SaaS-like option, minimal operational overhead, with feature constraints around SQL Agent and Cross-DB Query. Deploys as a Single Database or Elastic Pool. Azure SQL Managed Instance (SQL MI): instance-level PaaS, nearly 100% compatible with on-premises SQL Server, supporting SQL Agent, SSIS, Cross-DB Query, and Linked Server — the first-choice migration target. SQL Server on Azure VM (IaaS): full-feature SQL Server with OS-level access, your choice of SQL Server version, and Windows/Linux authentication, but you manage OS patches and SQL upgrades yourself. Decision: new SaaS web apps go to SQL DB, full lift-and-shift from on-premises SQL Server goes to SQL MI, and full control or SSAS-class features go to SQL on VM.

Compatibility with on-premises SQL Server ranks SQL on VM (100%) > SQL MI (95%) > SQL DB (80%). SQL on VM is fully compatible, including OS-level control. SQL MI offers instance-level compatibility and supports most SQL Server engine features (SQL Agent, SSIS Runtime, Cross-database Query, Linked Server, CLR, Service Broker; Filestream is limited), but OS-level operations are blocked and SSAS/SSRS are unsupported (you build those separately). SQL DB is single-database compatible, with many legacy features (SQL Agent, Cross-database Query) constrained. For migrations from on-premises SQL Server, MI is the default choice — code changes are minimal. For greenfield builds that can live within the feature constraints, SQL DB wins on cost and operational simplicity.

Service tiers shared by SQL DB and MI. General Purpose (GP): Premium SSD backed, general-purpose workloads, cheapest, 99.99% SLA. Business Critical (BC): Local SSD plus Always On AG, low latency and high availability, supports Zone Redundancy, 99.995% SLA, roughly 2x the cost of GP. Hyperscale (HS): handles 100 TB+ databases, uses a different architecture (Log Service + Compute + Page Server), up to 4 read replicas, 99.99% SLA, fast snapshot-based backups. Decision: standard web apps go to GP, low-latency mission-critical production goes to BC, and very large databases (10 TB+) go to HS. SQL MI supports GP and BC; SQL DB supports all three (GP / BC / HS).

Azure SQL DB billing units. DTU (Database Transaction Unit) model: an abstract unit bundling CPU, memory, and I/O — you pick a tier (Basic / Standard / Premium) and a DTU level (S0 to S12, P1 to P15). It's simple and budget-friendly, but the resource breakdown is opaque. vCore model (recommended): you specify CPU cores directly and tune memory, storage, and I/O independently — far more flexible, with Reserved Capacity and Hybrid Benefit support, and Hyperscale is vCore-only. As of 2026, Microsoft recommends the vCore model and new projects should use vCore. The DTU model survives only for legacy maintenance, and is rarely the right choice for new deployments.

HADR features shared by SQL DB and MI: 1) Active Geo-replication (DB-level, up to 4 read secondaries, RPO 5 seconds); 2) Auto-failover Group (cross-region failover, RPO 5 seconds, RTO 1 hour, bulk failover of multiple databases — the recommended pattern); 3) Zone Redundant configuration (AZ redundancy for BC / Premium, no extra cost); 4) Long-term Retention (LTR, up to 10 years of backup retention); 5) Continuous Backup with Point-in-time Restore (PITR, 7-35 days). SQL on VM adds Always On Availability Groups (AG) and Failover Cluster Instance (FCI). The standard production mission-critical recipe is Auto-failover Group + Zone Redundant + LTR + PITR. Auto-failover Group is required to guarantee service continuity during a regional outage.

Approximate monthly cost for a typical mid-size production setup (4 vCores, 100 GB storage, GP tier, Tokyo region, pay-as-you-go, no Hybrid Benefit): SQL Database (vCore, GP, 4 vCore) around 70,000 JPY; Managed Instance (GP, 4 vCore) around 90,000 JPY (more than SQL DB because of the operational simplicity premium); SQL Server on Azure VM (D4s_v5 + Enterprise Edition + Premium SSD) around 220,000 JPY (VM + Windows + SQL Server licenses). Applying Hybrid Benefit drops SQL on VM to roughly 120,000 JPY. Reserved Capacity (1-3 years) gives 15-55% off across all services. The cost ranking is SQL DB <= SQL MI << SQL on VM (you pay extra for full features). Adding Auto-failover Group or Zone Redundant configurations pushes costs higher still, so right-sizing to actual requirements matters.

Key controls: 1) Microsoft Entra ID authentication (phase out SQL authentication); 2) Managed Identity for app authentication (never put passwords in connection strings); 3) Transparent Data Encryption (TDE) on by default, with Customer-Managed Keys (CMK) via Key Vault; 4) Always Encrypted for sensitive columns (data stays opaque even on the Azure side); 5) Dynamic Data Masking to mask sensitive data; 6) Row-level Security for row-scoped access control; 7) Microsoft Defender for SQL (threat detection and Vulnerability Assessment); 8) Auditing enabled and shipped to Log Analytics, Storage, or Event Hubs; 9) Network isolation via Private Endpoint or Service Endpoint, with Public Access disabled; 10) Azure SQL Auditing retention of 365+ days for compliance. Production deployments need all of these controls in combination.

DP-300 (Database Administrator Associate) is the headline exam — it covers SQL DB, MI, and SQL on VM in depth. AZ-104 (Administrator) Domain 3 covers SQL on VM basics, AZ-305 (Solutions Architect Expert) covers platform selection from an architect's lens, AZ-204 (Developer Associate, retiring 2026-07) covers Azure SQL DB from the application developer's perspective, DP-700 (Fabric Data Engineer) covers analytical data integration, SC-300 (Identity Admin) covers Entra ID authentication integration, and SC-100 (Cybersecurity Architect Expert) covers data protection architecture. See the Azure Data Engineer / Architect career roadmaps for the full path.