The first decision for any SQL Server workload is how much of the platform you want Azure to manage. Azure SQL Database is scoped to a single database, Managed Instance gives you a near-complete SQL Server instance as PaaS, and SQL Server on a VM leaves the operating system and SQL Server in your hands.
Figure 6.1 walks through the choice.
| Requirement | Azure SQL Database | Azure SQL Managed Instance | SQL Server on Azure VM |
|---|---|---|---|
| Model | PaaS, database-scoped | PaaS, instance-scoped | IaaS, full OS/SQL management |
| Cross-database queries, three-part names, same-instance transactions | No (elastic queries/elastic database transactions, code changes) | Yes | Yes |
| SQL Agent, CLR | No (no SQL Agent – use elastic jobs; no CLR) | Yes | Yes |
| Windows/AD authentication | No (Microsoft Entra ID (Azure AD) only) | Entra ID, including Windows authentication via Kerberos | Yes |
| User-initiated COPY_ONLY backups | No | Yes | Yes |
| Max size | 4 TB (Hyperscale 128 TB) | 16 TB (32 TB on Next-gen General Purpose) | VM disks |
Matching workloads to options
- If several databases on one SQL Server instance rely on instance-level features (cross-database queries, SQL Agent, CLR, Windows authentication), move them together to Managed Instance, which offers near-100% compatibility with on-premises SQL Server.
- Managed Instance supports distributed transactions across instances that belong to a server trust group.
- For a single application moving to PaaS while reusing existing licences, a single vCore database is the fit: an elastic pool is unnecessary for one database, and a VM would be IaaS rather than PaaS.
- SQL Server Stretch Database (discontinued in July 2024) only moved cold rows of a table to Azure; it was never a migration or deployment option for a whole database.