Azure SQL Database vs SQL Server on VMs

The three deployment models, and what each one actually is

Azure gives you three distinct ways to run SQL Server workloads, and they sit at different points on the management-responsibility spectrum, not just different price points.

Azure SQL Database is fully managed platform-as-a-service scoped to a single database (or a group of databases sharing resources in an elastic pool). There is no instance-level access: no SQL Agent, no xp_cmdshell, no file system, no RDP or SSH into anything. Microsoft handles patching, backups, and the underlying OS entirely. You connect to a logical server endpoint, but that "server" is a connection and security boundary, not a physical or virtual machine you can inspect. This model was built for application databases that don't need cross-database joins or instance-level features, and it scales down to very small, cheap tiers as easily as it scales up to business-critical workloads with read replicas.

Azure SQL Managed Instance is also PaaS — Microsoft still owns patching, backups, and infrastructure — but it exposes something much closer to a real SQL Server instance. You get a native instance boundary, cross-database queries within the instance, SQL Server Agent, Database Mail, Service Broker, CLR integration, and support for the linked-server catalog. It's designed specifically to make lift-and-shift migrations from on-premises or VM-based SQL Server as close to a connection-string change as possible. The tradeoff is a heavier resource footprint: Managed Instance requires a dedicated subnet inside a virtual network, has a higher compute floor, and provisioning/scaling operations take longer (often tens of minutes) than the near-instant scaling of Azure SQL Database.

SQL Server on an Azure VM is infrastructure-as-a-service. You pick a VM size and disk configuration, install (or use a pre-built Azure Marketplace image of) SQL Server, and from that point on you are the DBA and the sysadmin. You control the OS patch cadence, the exact SQL Server build and cumulative update, instance-level configuration, third-party agents (backup software, monitoring, security tooling), and every feature SQL Server ships — including ones Azure PaaS doesn't support, like Replication publishers in some topologies, certain FILESTREAM configurations, or specific third-party CLR assemblies. You're also fully responsible for configuring HA/DR (Always On Availability Groups, clustering), backup retention, and disaster recovery testing.

DTU vs vCore purchasing models

Azure SQL Database (and historically, only Azure SQL Database) offers a choice between two purchasing models; Managed Instance is vCore-only, and VMs are priced as ordinary compute plus a separate SQL Server license or pay-as-you-go SQL Server meter.

The DTU (Database Transaction Unit) model bundles CPU, memory, and I/O into a single blended metric, packaged into Basic, Standard, and Premium tiers. It's simple to reason about for small, predictable workloads — you pick a tier and a DTU count and you're done — but it gives you no way to scale compute and storage independently, and no visibility into which resource (CPU, memory, or I/O) is actually the bottleneck when you hit a ceiling.

The vCore model separates compute and storage into independent, transparent settings: you choose a number of virtual cores, an amount of memory (tied to the compute tier — General Purpose vs Business Critical vs Hyperscale), and storage size and type separately. This maps directly onto familiar SQL Server sizing conversations ("this workload needs 8 cores and 400 GB") and, critically, is the only model that supports Azure Hybrid Benefit — applying existing SQL Server licenses with active Software Assurance to reduce the compute rate by roughly 30-55%. If your organization already owns SQL Server Enterprise or Standard licenses, vCore with Hybrid Benefit is very often cheaper than DTU for equivalent capacity, which is why Microsoft has been steering new deployments toward vCore and gradually de-emphasizing DTU pricing in documentation and defaults. DTU remains supported and is still reasonable for small, single-database workloads where the simplicity outweighs the licensing optimization.

What you give up moving from IaaS to PaaS

The biggest planning risk in this decision isn't compute sizing, it's assuming PaaS gives you everything a VM does. It doesn't, and the gap differs meaningfully between the two PaaS tiers.

Azure SQL Database has the largest gap. There is no SQL Server Agent (use Elastic Database Jobs or Azure Automation/Logic Apps instead), no native cross-database queries (you must use elastic query, external tables, or application-side joins), no linked servers, no SQL Server Analysis Services, Reporting Services, or Integration Services hosted alongside it, no CLR in most tiers (Hyperscale and some tiers added limited trusted assembly support later, but it's not the full CLR you get on-box), and no direct file system or OS access at all. Applications built assuming any of these are common migration blockers.

Azure SQL Managed Instance closes most of this list: SQL Agent, cross-database queries and transactions within the same instance, Service Broker, Database Mail, and CLR are all present. What it still doesn't give you is cross-instance distributed transactions using MSDTC in the classic sense, filestream/filetable in the general-purpose tier historically had limitations, some replication topologies are restricted, and you still can't RDP into the box or install arbitrary third-party software that needs OS-level hooks (agent-based backup tools, certain monitoring agents, custom CLR requiring native DLLs outside the sandboxed model). Instance-level features that require true OS control remain a VM-only story.

SQL Server on a VM gives up nothing feature-wise relative to on-premises SQL Server — same binaries, same support matrix — but you give up the managed-service guarantees: no built-in automatic patching unless you configure Automated Patching, no built-in high availability unless you build an Availability Group or FCI yourself, and you own the operational toil of backup verification, corruption checks, and capacity monitoring that Azure absorbs for you in both PaaS tiers.

Availability, backup, and recovery differences

Azure SQL Database's higher service tiers (Business Critical) use built-in Always On technology under the hood with automatic failover and up to three synchronous replicas, with zero application configuration required. General Purpose tier uses remote storage-based redundancy with a shorter failover but lower cost. Point-in-time restore is automatic and included, typically covering 7-35 days depending on tier, with no backup jobs to schedule or maintain.

Managed Instance offers the same automated backup and point-in-time restore model, plus built-in support for Always On-style automatic failover groups for cross-region DR, again without you managing the underlying cluster. It also uniquely supports native RESTORE and BACKUP compatibility with on-premises .bak files for both migration and ongoing hybrid backup scenarios, which Azure SQL Database does not support directly.

On a VM, high availability is entirely your build: Always On Availability Groups across multiple VMs (with your own listener, quorum, and network configuration), Failover Cluster Instances with shared storage, or log shipping. Azure provides the SQL Server IaaS Agent extension to automate some of this (automated backup, automated patching, and simplified AG deployment through the Azure portal), but the underlying cluster is still yours to design, test, and troubleshoot when it fails at 2 a.m.

A practical decision framework

For a greenfield, cloud-native application where you control the schema and data access patterns from day one, default to Azure SQL Database. Use a single database for simple apps, or an elastic pool when you have many similarly-sized databases (common in multi-tenant SaaS) that can share a resource budget economically. Only reach for Business Critical or Hyperscale tiers if you have a specific latency or scale requirement — General Purpose is the right starting point for most workloads.

For migrating an existing SQL Server application where the goal is minimal code and operational change — it uses SQL Agent jobs, cross-database joins, linked servers, or relies on instance-level configuration you don't want to re-architect — Azure SQL Managed Instance is the target. Budget for its higher entry cost (the smallest General Purpose instance starts at 4 vCores) and plan the VNet/subnet requirements early, since retrofitting networking after deployment is disruptive.

For workloads that need full OS-level control, a SQL Server feature or version not supported in either PaaS tier, third-party software installed alongside the database engine, or very specific compliance/audit requirements that mandate direct control over the host, SQL Server on an Azure VM is the right (and sometimes only) option. This is also the fallback when you're running an older SQL Server version PaaS doesn't support, or when a vendor-supplied application explicitly certifies only against a specific on-box SQL Server configuration.

A common mistake is picking based on cost alone. Run the sizing exercise for all three options against your real workload, including Hybrid Benefit eligibility, before deciding — a Managed Instance with Hybrid Benefit can land close to VM pricing while eliminating patching and backup overhead, which often changes the calculus more than the sticker price does.

Migration path considerations

Moving from an existing SQL Server environment, the Data Migration Assistant and Azure Migrate can assess compatibility and flag blocking issues (unsupported features, deprecated syntax) before you commit to a target. If the assessment shows no Managed Instance blockers, that path minimizes downstream application changes. If it surfaces hard blockers — certain replication topologies, specific CLR dependencies, or Analysis Services co-located on the same box — a VM keeps the migration a true lift-and-shift, and you can revisit PaaS later once those dependencies are removed or re-architected. Whichever target you choose, test the actual cutover (backup/restore or continuous replication via Azure Database Migration Service) against a non-production copy first; the assessment tools catch most but not all compatibility issues, and connection string, authentication mode, and collation mismatches are the most common last-mile surprises.