Azure SQL: Database, Managed Instance, or Virtual Machine
Azure SQL isn't one product. It's three deployment options on a spectrum from fully managed to fully controlled, and choosing between them is mostly a question of what you're migrating from and how much of SQL Server's surface area you actually need. The wrong choice is recoverable, but rarely cheaply — so it's worth understanding what each one gives up.
Azure SQL Database
Azure SQL Database is the PaaS option that abstracts away both the operating system and the SQL Server instance. It's fully managed: no configuring high availability, tuning, or backups by hand, and it upgrades itself to the current SQL Server version, so new capabilities arrive without manual updates.
- Highly scalable, intelligent, and relational, with the industry's highest availability.
- The only deployment option supporting serverless compute for unpredictable workloads.
- Storage limits differ sharply by service tier: General Purpose and Business Critical support 1 GB to 4 TB, while Hyperscale supports 10 GB to 128 TB, fixed at that ceiling and not configurable.
Course material frequently gives 100 TB as the Azure SQL Database maximum, and sometimes contradicts itself by quoting 128 TB elsewhere in the same document. The current figure is 128 TB, and it applies to Hyperscale specifically — not to General Purpose or Business Critical, which top out at 4 TB.
Best for: modern cloud applications, hyperscale workloads, and anything that benefits from serverless.
Two operational constraints worth knowing early:
- Azure SQL auditing requires the storage account to be in the same region as the SQL server hosting the database.
- Azure supports up to five diagnostic settings on a single resource, each routing logs to a different destination, provided the destination is in the same region as the monitored resource.
Azure SQL Managed Instance
Managed Instance is the PaaS option that bridges on-premises and cloud — near-100% compatibility with the SQL Server engine while remaining a managed service. It gives you an instance of SQL Server without the overhead of running a VM. You can deploy a single managed instance, or an instance pool that shares resources between multiple instances to optimise price and can host smaller instances from 2 vCores.
Best for: lift-and-shift migrations of entire SQL Server instances that need instance-scoped features — SQL Server Agent, cross-database queries, linked servers, CLR, Database Mail, distributed transactions, Machine Learning Services. If your application depends on any of those, this is the line that rules out Azure SQL Database.
Several behaviours are specific to it:
- Managed instances deploy into their own virtual network.
- It uses vCore mode only — no DTU option. You define maximum CPU cores and storage for the instance, and all databases within it share those resources.
- It isn't optimised for many small or variable-load databases. Fifty separate databases on managed instances is more complex and more expensive than an elastic pool. That's a real anti-pattern, not a preference.
High availability on Managed Instance
This is where Managed Instance diverges from Azure SQL Database in a way that catches people out:
- Auto-failover groups provide high availability. This is the supported mechanism.
- Active geo-replication isn't supported for Managed Instance.
- SQL Data Sync can't control failover — it synchronises data, which is a different problem.
- An Always On failover cluster instance requires shared storage, needs significant administrative effort, and can't control replication or failover to another Azure region.
Where the requirement is specifically a SQL Server-based high availability method, Always On availability groups is the answer.
Available tiers: General Purpose (budget-friendly, remote storage), Next-gen General Purpose (up to 32 TB storage and better latency at the same baseline cost), and Business Critical (highest performance and redundancy, four replicas).
SQL Server on Azure Virtual Machines
The IaaS option: a full SQL Server installation on an Azure VM, available in many sizes and regions, and configurable to meet specific version and operating system requirements.
Best for: legacy applications needing OS-level access, third-party software installed alongside SQL Server, or SQL Server versions not offered in PaaS.
- You get the full capabilities of SQL Server, including CLR integration.
- Performance is determined by the VM SKU rather than a service tier — there's no tier to choose.
- You're responsible for version updates to both the operating system and SQL Server. This is the highest ongoing administrative overhead of the three, and it doesn't go away.
- A VM can be deployed into a specific availability zone, though it can also be deployed regionally without zone pinning — it's a choice rather than a property.
- High availability requires manually configuring Always On availability groups for replication and failover.
Bring Your Own Licence (BYOL) lets you apply existing SQL Server licences here to reduce cost.
Comparing the three
Administrative overhead is the axis that separates them: Azure SQL Database minimises it, Managed Instance sits in the middle, and SQL Server on a VM carries the most. All three support SQL Server spatial capabilities.
| SQL Database | SQL Managed Instance | SQL Server on Azure VMs | |
|---|---|---|---|
| Scenario | Modern cloud applications, hyperscale, or serverless | Most lift-and-shift migrations, instance-scoped features | Fast migrations, and applications requiring OS-level access |
| Single deployment | Single database: Hyperscale storage, serverless compute, fully managed | Single instance: the vast majority of SQL Server surface area, native virtual networks, fully managed | SQL Server access, OS-level server access, expansive SQL Server and OS version support |
| Pooled deployment | Elastic pool: resource sharing across databases for price optimisation, simplified performance management | Instance pool: pre-provisioned compute for migration, cost-efficient, hosts smaller instances from 2 vCores | Not applicable |
| Notable features | — | — | FileStream, Microsoft Distributed Transaction Coordinator, Simple Recovery model, SSIS, SSRS, SSAS |
| OS-level access | No | No | Yes |
| You patch it | No | No | Yes |
Elastic pools
An elastic pool buys a set of compute and storage resources shared by all databases in it. Each database uses what it needs within limits you set, which suits many databases with varying, uncorrelated load — the classic multi-tenant SaaS shape, where no single tenant is busy all the time but some tenant usually is.
The architectural detail that decides whether a pool fits:
Autoscaling operates at the pool level, not per database. Resources are shared across the pool and scaling decisions are made collectively for all of it. If you need databases to scale independently of one another, a pool is the wrong shape.
Choosing
The decision usually resolves on three questions, in order:
- Do you need OS-level access, or third-party software on the same server? If yes, SQL Server on a VM. Nothing else offers it.
- Do you depend on instance-scoped features — SQL Agent, cross-database queries, linked servers, CLR? If yes, Managed Instance.
- Otherwise, Azure SQL Database — and if you have many small databases with uncorrelated load, an elastic pool rather than individual databases.
The purchasing model and service tier are the next decisions, and they're independent of this one — covered in the posts on Azure SQL purchasing models and high availability.