Azure SQL Database vs Managed Instance vs SQL on a VM: which to choose.
Azure gives you three ways to run SQL Server, and they mostly differ in one thing: how much of the machinery Microsoft runs for you versus how much you run yourself. Pick by how much control you actually need, not by which sounds most powerful.
New to cloud? CAMPUX is a free, build-first course. Start here →
The short rule: reach for Azure SQL Database (PaaS) when you're building a new cloud application, SQL Managed Instance when you're lifting and shifting an existing SQL Server that needs near-full compatibility, and SQL Server on an Azure VM (IaaS) only when you need OS-level control or a feature the PaaS options don't offer. You're trading control for how much Azure manages — and here's the part the other guides skip: most teams should default to PaaS and only drop down when something forces them.
All three run the same SQL Server database engine, so your T-SQL, your tools, and your skills carry across. What changes is where the line sits between your job and Microsoft's. On a VM you own the operating system, patching, backups, and high availability. On the two PaaS options Azure owns all of that, and you're left to do the parts that were always yours anyway — schema, queries, indexes, security. That single dividing line explains almost every trade-off below.
The three options in one table
All three options sit side by side below. Capabilities and limits are current on Microsoft Learn as of August 2026, so read the specific numbers as a snapshot even while the overall direction holds. Azure moves the ceilings up over time, so verify the exact figures before you architect against them.
| Option | Management model | Best for | Main trade-off |
|---|---|---|---|
| Azure SQL Database | PaaS (database-as-a-service). Azure runs the hardware, OS, and engine; patching, backups, HA all automated. You manage a single database or an elastic pool. | New cloud-native apps and SaaS; teams that want the lowest operational overhead. Serverless and Hyperscale (up to 128 TB) available. | Database-level features only. No SQL Agent, cross-database queries, or instance-scoped machinery — migrating an existing app can mean rework. |
| SQL Managed Instance | PaaS (instance-as-a-service). Same automated patching, backups, and HA, but you get a whole SQL Server instance with a private IP in your VNet. | Lift-and-shift migrations that need near-full SQL Server parity. Microsoft's stated pick for most cloud migrations. | Higher entry cost than a single database and a longer provisioning time; storage ceiling (16 TB) below a VM's. Still not 100% parity. |
| SQL Server on Azure VM | IaaS. Azure runs the physical host; you own the OS, the SQL Server install, patching, backups, and your own HA (e.g. Always On availability groups). | Workloads needing OS-level access, 100% compatibility, a specific SQL Server version/feature, or databases beyond the PaaS ceilings. | You do the operational work — patching, backups, HA, tuning the box. Most control, most responsibility, usually most total effort. |
Azure SQL Database: the default you should argue against, not for
Azure SQL Database is a fully managed relational database-as-a-service. You create a single database (or an elastic pool that shares resources across many), and Microsoft handles the engine, the operating system, the hardware, patching, backups, and high availability. It carries the most commonly used SQL Server features and the latest stable engine, and it scales compute up and down — including serverless, which can pause when idle so you stop paying for a database nobody's using.
The reason to treat it as the default is boring and correct: it removes the largest, most error-prone chunk of database operations from your plate. Nobody gets promoted for patching a database server on a Tuesday. What it gives up is instance-level machinery — SQL Server Agent jobs, cross-database queries, CLR, Service Broker, linked servers. For a new application you design around those constraints and never feel them. For an old application that leans on them, this is where a migration gets painful, which is exactly the gap the next option fills.
The question isn't which option is most powerful. It's how much of the operating system you're willing to be responsible for.
Managed Instance: the lift-and-shift sweet spot
SQL Managed Instance is the option people underrate. It's still PaaS, since Azure patches it, backs it up, and keeps it highly available, but instead of a lone database it gives you a near-complete SQL Server instance with almost 100% feature parity, plus a private IP address inside your own virtual network. That combination is the point. It's the same operational relief as Azure SQL Database, minus the compatibility cliff.
Microsoft names it the best target for most migrations to the cloud, and in practice that's right. If you have an existing SQL Server with Agent jobs, cross-database queries, CLR assemblies, or Service Broker, Managed Instance usually takes it with minimal to no changes — the things that would break on Azure SQL Database keep working here. You pay for that with a higher floor cost and a slower first deployment, and the storage ceiling sits below what a VM can reach. But if your goal is "get this off the on-prem box without rewriting the application," this is the lane to look at first, before you assume you need a VM.
Start at the top of the table and only move down when something forces you. New app? Azure SQL Database. Existing SQL Server you want to move with minimal changes? Managed Instance. Only when you hit a hard wall (OS-level access, a feature or version the managed services don't carry, a database bigger than the PaaS ceiling) do you drop to a VM and take on the operating system. Most teams reach for the VM out of habit or a false sense of control, then spend the next year patching it. Choosing IaaS should feel like a concession, not a default.
SQL Server on a VM: full control, and the bill that comes with it
SQL Server on an Azure VM is IaaS. Azure runs the physical host and the virtualization; everything above that, the operating system, the SQL Server install, patching, backups, high availability, is yours. You pick the SQL Server version and licence tier, the OS, and the storage layout, and you get 100% compatibility with the matching on-prem SQL Server. Databases can run far larger than the PaaS options allow, up to hundreds of terabytes on a single instance.
That control is real and sometimes necessary. If a third-party agent has to run on the database host, if you need a feature or a specific version the managed services don't offer, or if you want to decide exactly when maintenance happens, the VM is the answer and the only answer. The catch is that everything Azure was doing for you in the PaaS options is now a task on your team's calendar. High availability isn't automatic — you build it, typically with Always On availability groups across availability zones. Backups, patching, tuning the box: yours. A VM often looks cheapest on the per-hour compute line and stops looking cheap once you price the DBA hours, which is why the cost question is never just the sticker.
How this fits the rest of your Azure data choices
This comparison is only about the three ways to run SQL Server — a relational engine. A different and earlier question is whether you want relational at all, or a NoSQL store for flexible schemas and global scale. That's a separate fork, and I walk through it in Azure SQL vs Cosmos DB; decide relational-versus-NoSQL first, then come back here to pick how you host the SQL side. If your workload does land on a VM, the box you choose matters as much as the database, so the sizing logic in Azure VM sizes and series applies directly — SQL is memory- and IO-hungry, and the wrong series will bottleneck you no matter how the database is configured.
One more framing that keeps people out of trouble: the choice isn't permanent in the way it feels. You can start on Azure SQL Database for a new service and only move to Managed Instance if you outgrow the feature set; you can migrate a VM workload down to Managed Instance later once you've retired whatever tied you to the OS. Pick the most-managed option the workload can tolerate today, and let a real constraint, not a hunch, be the thing that pushes you toward more control.
Questions people also ask
What is the difference between Azure SQL Database and Managed Instance?
Both are fully managed PaaS services that run the SQL Server engine, but they expose it at different levels. Azure SQL Database gives you a single database (or an elastic pool) with the most-used SQL Server features and no access to instance-level machinery. Managed Instance gives you a whole SQL Server instance with almost 100% feature parity — SQL Server Agent, cross-database queries, CLR, Service Broker, and a private IP in your virtual network. Database is built for new cloud apps; Managed Instance is built for migrating existing SQL Server workloads with minimal changes.
When should I use SQL Server on an Azure VM?
Use a VM when the two PaaS options can't do what you need. That means OS-level access for third-party agents or custom software on the database host, a SQL Server feature or version the managed services don't offer, full control over patching and maintenance windows, or a database larger than the Managed Instance ceiling. On a VM you get 100% SQL Server compatibility and total control, and in exchange you own the operating system, high availability, backups, and patching yourself.
Is Azure SQL Database PaaS or IaaS?
Azure SQL Database is Platform-as-a-Service (PaaS) — specifically a database-as-a-service. Microsoft owns and runs the hardware, operating system, and database engine, and handles patching, backups, high availability, and recovery for you. SQL Managed Instance is also PaaS. Only SQL Server on an Azure VM is Infrastructure-as-a-Service (IaaS), where Azure manages the physical host but you manage the OS and SQL Server yourself.
Which Azure SQL option is cheapest?
For most small and mid-size workloads Azure SQL Database is the cheapest to run, because there's no VM or OS to pay for or maintain and it starts at a low Basic tier; serverless can pause compute when idle to cut the bill further. But the sticker price isn't the whole cost — a VM often looks cheaper per hour and then costs more once you count the DBA time spent patching, backing up, and building high availability. Price the total cost of ownership, not just the compute line, and treat any single number you read online with suspicion.
Can I migrate my on-prem SQL Server to Azure SQL Database?
Sometimes, but it's the hardest of the three targets. Azure SQL Database supports database-level features only, so any workload that depends on SQL Server Agent jobs, cross-database queries, CLR, linked servers, or other instance-level features needs rework before it fits. For a lift-and-shift with minimal changes, Managed Instance is the usual sweet spot because of its near-full compatibility; a VM is the fallback when you need 100% parity. Use the Azure SQL Migration extension and Data Migration Assistant to check compatibility before you commit.