Skip to content
Home › SQL Comparisons › Azure SQL Database vs Managed Instance
Comparison · Cloud Databases

Azure SQL Database vs Managed Instance

Azure SQL Database and Azure SQL Managed Instance are both fully managed (PaaS) SQL Server engines in Azure. Azure SQL Database is scoped to individual databases and suits new cloud applications; Managed Instance gives you a whole SQL Server instance inside your own virtual network, with SQL Server Agent, cross-database queries, CLR, linked servers and native backup to URL, and suits lift-and-shift migrations.

Last verified October 2026. Licensing and features change; check the official sources for the latest details.

Quick verdict

Short answer

Choose Azure SQL Database for new cloud applications that live within one database (or a pool of independent databases), especially if you want serverless auto-pause, Hyperscale up to 128 TB or the lowest entry cost. Choose Azure SQL Managed Instance when you are moving an existing SQL Server instance to Azure and depend on instance-level features: SQL Server Agent jobs, three-part-name cross-database queries, CLR, linked servers, Service Broker or Database Mail. Managed Instance also lives inside your Azure virtual network by design and supports near real-time migration and hybrid disaster recovery with the Managed Instance link.

How we know: This comparison is research-based: features, service tiers, limits, the free offers and migration options were checked against Microsoft Learn (including the Azure SQL feature comparison page dated 30 September 2026) in October 2026. We have not deployed either service or run performance tests, so nothing here is a measured result.

Azure SQL Database is Microsoft's database-scoped PaaS offering. You create single databases or elastic pools on a logical server; Microsoft runs the engine on the latest stable version, patches it, backs it up and provides high availability. There is no instance to manage, no SQL Server Agent and no operating system access. It offers both the vCore and DTU purchasing models, serverless compute and the Hyperscale tier. See Azure SQL Database vs SQL Server for how it compares with SQL Server you run yourself.

Azure SQL Managed Instance is also PaaS, but what you get is a full SQL Server instance. Microsoft describes it as having "near 100% compatibility with the latest Enterprise Edition SQL Server Database Engine", deployed into a subnet of your own Azure virtual network, and positions it for customers who want to lift and shift many applications with as little change as possible. Microsoft still handles patching, backups and high availability, but you keep instance-level features such as SQL Server Agent, cross-database queries, CLR and user-initiated copy-only backups to Azure Blob storage.

Both run the SQL Server engine. T-SQL, drivers and tools are largely the same, and both connect from SSMS and VS Code with the MSSQL extension. The difference is scope (database versus instance), networking, purchasing options and which SQL Server features are available. The third Azure SQL option, SQL Server on Azure VMs, gives full operating system control but leaves patching and HA to you.

Side by side

AspectAzure SQL DatabaseSQL Managed Instance
Scope Single databases or elastic pools on a logical server A whole SQL Server instance with system databases; up to 100 databases (500 in Next-gen General Purpose)
SQL Server Agent No; Elastic jobs instead Yes, with documented differences
Cross-database queries and transactions No three-part names; Elastic query (preview) and elastic transactions Yes, within the instance; DTC across managed instances
CLR, Service Broker, Database Mail Not supported Supported (CLR without file system access; Database Mail via external SMTP)
Linked servers Not supported Yes, to SQL Server, Managed Instance, Azure SQL Database and Azure Synapse SQL targets only; not to other database engines or files
Native backup and restore Automatic backups only; no BACKUP or RESTORE statements Automatic backups plus user-initiated copy-only backups and RESTORE FROM URL (Azure Blob storage)
Networking Public endpoint with firewall rules; VNet service endpoints and Private Link available Injected into a dedicated subnet of your VNet; private IP by default, optional public endpoint
Compute options vCore (provisioned or serverless) and DTU; elastic pools; up to 192 vCores vCore provisioned only; instance pools; stop and start; up to 128 vCores
Maximum storage 4 TB in General Purpose and Business Critical; 128 TB in Hyperscale 16 TB per instance; 32 TB in Next-gen General Purpose
Free offer Up to 10 serverless databases per subscription, renewing monthly with no end date One instance per subscription for 12 months, 720 vCore hours a month
Main trade-off Lowest administration and entry cost, but database-scoped features only Near-complete SQL Server compatibility, but larger minimum footprint and VNet setup

Key differences

Compatibility: what Managed Instance adds

Microsoft's feature comparison page is the reference. The instance-level features below are the usual reasons a migration lands on Managed Instance rather than Azure SQL Database:

  • SQL Server Agent: available in Managed Instance, always running, with T-SQL and SSIS job steps; Microsoft lists alerts, proxies and command shell job steps as not supported. Azure SQL Database has none and points to Elastic jobs. Managed Instance does not support Elastic jobs; Microsoft points it to SQL Agent or Azure Automation.
  • Cross-database queries and transactions: three-part names work within a managed instance; Azure SQL Database needs Elastic query (preview) or elastic transactions.
  • CLR: supported in Managed Instance, but CREATE ASSEMBLY cannot read from the file system.
  • Linked servers: Managed Instance supports linked servers whose targets are SQL Server, other managed instances, Azure SQL Database and Azure Synapse SQL pools; other database engines and Analysis Services are not supported, and the feature comparison notes no distributed transactions over them. Linked servers that read files such as CSV or Excel are not supported in either service.
  • Service Broker and Database Mail (through an external SMTP server): supported in Managed Instance, not in Azure SQL Database. Cross-instance Service Broker messaging works only between managed instances.
  • Distributed transactions: Managed Instance supports DTC between managed instances; Azure SQL Database uses elastic transactions.
  • Trace flags (a limited set of global ones) and Windows authentication for Microsoft Entra principals: Managed Instance only.
  • Machine Learning Services: Managed Instance, with the SQL Server 2022 update policy.

Some gaps apply to both: FILESTREAM and FileTable are not supported, only the full recovery model is available (so no minimal logging in bulk import), and SSRS is not part of either service (Microsoft points to Power BI paginated reports or SSRS on a VM). SSIS runs in both cases on an Azure-SSIS Integration Runtime in Azure Data Factory, with the SSISDB catalog hosted in the database service. Managed Instance also allows only one log file per database and supports TCP connections only.

-- T-SQL (SQL Managed Instance): works; fails in Azure SQL Database
SELECT o.id, c.name
FROM SalesDb.dbo.orders AS o
JOIN CrmDb.dbo.customers AS c ON c.id = o.customer_id;

-- T-SQL (SQL Managed Instance): user backups must be copy-only and go to Azure Blob storage
BACKUP DATABASE SalesDb
TO URL = N'https://myaccount.blob.core.windows.net/backups/SalesDb.bak'
WITH COPY_ONLY;

The backup example assumes a credential for the storage container already exists. Azure SQL Database accepts neither statement.

Networking: VNet injection versus public endpoint

A managed instance is deployed into a dedicated subnet of an Azure virtual network you own. Microsoft states that in a default deployment the SQL endpoint is exposed only through a private IP address, so applications in Azure or on premises (through VPN Gateway or ExpressRoute) reach it privately; a public endpoint can be enabled when needed. Microsoft also notes that deploying the first managed instance in a subnet takes considerably longer than adding more instances to the same subnet, so plan subnet design and provisioning time up front.

Azure SQL Database is reached through its logical server's endpoint, protected by server and database firewall rules. You can restrict access with VNet service endpoints, or make it private with Private Link. The feature comparison page describes its VNet support as partial, because it is reached through endpoints rather than living inside your network.

Purchasing models and service tiers

Azure SQL Database offers the vCore model (General Purpose, Business Critical, Hyperscale) and the older DTU model (Basic, Standard, Premium). Within vCore you can choose provisioned compute or serverless compute, which autoscales and can auto-pause in General Purpose and Hyperscale. Elastic pools share resources across many databases.

Managed Instance uses only the vCore model, with provisioned compute billed per hour. Its service tiers are General Purpose (up to 80 vCores, 16 TB, 100 databases), Next-gen General Purpose (an upgrade of General Purpose on Azure Elastic SAN storage: up to 128 vCores, 32 TB and 500 databases, flexible memory, and 3 free IOPS per GB of reserved storage with extra IOPS billed) and Business Critical (up to 128 vCores and 16 TB, local SSD storage, three HA replicas of which one is a free readable replica). Hardware choices are standard-series (Gen5), premium-series and memory optimized premium-series. There is no serverless option; instead you can stop and start a General Purpose instance and pay only for storage while it is stopped, or use instance pools to share resources between smaller instances.

Engine versions and the update policy

Azure SQL Database always runs the latest stable engine; you control behaviour through database compatibility levels. Managed Instance adds an instance-level update policy: SQL Server 2025 or SQL Server 2022 keeps the internal database format aligned with that SQL Server release, while Always-up-to-date gives every new engine feature as soon as it ships in Azure. Microsoft documents SQL Server 2025 as the default for new instances created in the Azure portal (SQL Server 2022 remains the default from PowerShell, CLI and older REST API versions). Moving to a newer policy is permanent.

The policy matters for exits and hybrid setups: only an instance on the SQL Server 2022 or 2025 policy can restore its backups to that SQL Server version or fail back to it over the Managed Instance link. Backups from Azure SQL Database cannot be restored to SQL Server at all; Microsoft points to BACPAC or BCP.

Migration paths

Microsoft documents more migration routes into Managed Instance than into Azure SQL Database, because Managed Instance accepts native SQL Server backups and log streams:

  • Managed Instance link: replicates databases in near real time using distributed availability groups. One-way replication works from SQL Server 2016, 2017 and 2019; SQL Server 2022 and 2025 also support failover and failback (two-way disaster recovery) with a matching update policy. Microsoft calls it the minimal-downtime option and the only way to do a true online migration to Business Critical. It needs Enterprise, Standard or Developer edition and private network connectivity (VPN, ExpressRoute or VNet peering), and it does not copy logins, Agent jobs or other server-level objects.
  • Log Replay Service (LRS): a free service based on log shipping. You upload full, differential and log backups to Azure Blob storage and LRS restores them, in autocomplete or continuous mode, with a manual cutover. A single LRS job can run for at most 30 days. Microsoft notes extra limitations for Business Critical targets.
  • Azure Database Migration Service: a managed service, driven from the Azure portal, PowerShell or Azure CLI, that supports online and offline migration to Managed Instance and offline migration to Azure SQL Database.
  • SQL Server enabled by Azure Arc: an assessment and portal-driven migration to Managed Instance that uses either the link or LRS under the hood.
  • Native RESTORE FROM URL: restore a full backup from Azure Blob storage.

For Azure SQL Database, Microsoft lists transactional replication for online migration and BACPAC import or BCP for offline migration, plus Database Migration Service offline. The Azure SQL migration extension for Azure Data Studio is no longer an option: Azure Data Studio was retired on 28 February 2026, and Microsoft directs migrations to these dedicated tools.

High availability, read scale and backups

Both include built-in HA, automatic full, differential and log backups, point-in-time restore for 1 to 35 days (7 by default) and long-term retention for up to 10 years. Azure SQL Database scales reads further: Business Critical and Premium provide read scale-out, and Hyperscale adds up to 4 HA replicas and up to 30 named replicas, with up to four geo-replicas. Managed Instance offers one readable built-in replica in Business Critical and one geo-secondary through failover groups. With failover groups configured, Microsoft documents a guaranteed RPO of 5 seconds and RTO of 30 seconds for Business Critical. Managed Instance can also act as a disaster recovery target for SQL Server through the link, and a DR-only secondary can use the license-free passive replica benefit.

Pricing and licensing

Pricing model. Both are billed by Azure with prices that vary by region, tier and hardware, so use the Azure pricing pages or the pricing calculator for a real figure; we do not quote a sample price here. Azure SQL Database bills per database or elastic pool: provisioned compute per hour or serverless compute per second used, plus data storage and backup storage beyond the included amount, or a fixed DTU bundle. Managed Instance bills per instance: provisioned vCores per hour, reserved storage for the maximum size you configure (set in multiples of 32 GB), backup storage beyond an amount equal to the configured data size, and, in Next-gen General Purpose, IOPS above the free quota of 3 per GB. Microsoft Learn states that Business Critical compute costs roughly 2.7 times General Purpose because of its extra replicas, for both services.

Discounts. Both support Azure Hybrid Benefit for existing SQL Server licences with Software Assurance (in Azure SQL Database, vCore General Purpose and Business Critical only, not new Hyperscale databases) and reserved capacity. Managed Instance adds instance pools, stopping a General Purpose instance so that only storage is billed, and a license-free passive DR replica.

Azure SQL Database free offer (Microsoft Learn, October 2026): up to 10 General Purpose serverless databases per subscription, each with 100,000 vCore seconds of compute, 32 GB of data and 32 GB of backup storage every month for the life of the subscription.

Managed Instance free offer (Microsoft Learn, October 2026): one General Purpose instance per subscription for 12 months, with 4 or 8 vCores, 720 vCore hours each month, 64 GB of storage (system files can use up to 32 GB of it), up to 100 databases (500 with Next-gen General Purpose), backups kept for up to 7 days and the SQL licence included. It has no SLA and does not support zone redundancy, failover groups or long-term backup retention. The instance runs 9 a.m. to 5 p.m. on weekdays by default and stops when the monthly vCore hours run out. After 12 months it stops, and unless you upgrade to a paid offer within 30 days, the instance and its databases are deleted.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

Azure SQL Database strengths

  • Serverless compute that autoscales and auto-pauses, plus elastic pools for many small databases
  • Hyperscale tier for databases up to 128 TB with up to 30 named read replicas
  • Lowest administration: no subnet, no instance and no Agent to look after
  • Free offer of up to 10 small databases per subscription with no end date
  • DTU model available for teams that want fixed, bundled sizes

SQL Managed Instance strengths

  • Near-complete SQL Server compatibility: Agent, cross-database queries, CLR, linked servers, Service Broker, Database Mail
  • Native copy-only backups and RESTORE FROM URL, and restore back to SQL Server 2022 or 2025 with the matching update policy
  • Runs inside your VNet with a private IP by default
  • Managed Instance link for near real-time migration and two-way DR with SQL Server 2022 and 2025
  • Stop and start (General Purpose) and instance pools to control cost

Limitations

Azure SQL Database limitations

  • No SQL Server Agent, three-part-name cross-database queries, CLR, linked servers, Service Broker or Database Mail
  • No BACKUP or RESTORE statements, and no native restore of its backups to SQL Server
  • Fewer online migration routes from SQL Server (transactional replication; Database Migration Service is offline only)
  • Instance-level settings, trace flags and Windows authentication are unavailable

SQL Managed Instance limitations

  • Provisioned compute only, with no serverless auto-pause; you pay for configured vCores and storage while it runs
  • Needs a dedicated VNet subnet, and Microsoft notes the first instance in a subnet takes considerably longer to provision
  • Maximum 16 TB per instance (32 TB in Next-gen General Purpose), against 128 TB for Hyperscale databases
  • Still not 100% SQL Server: no FILESTREAM, only the full recovery model, one log file per database, linked servers limited to SQL Server and Azure SQL targets, no SQL Agent alerts or proxies
  • Moving to a newer update policy is permanent, and Always-up-to-date removes restore and failback to SQL Server

When to choose each

Choose Azure SQL Database if

  • You are building a new cloud application that fits in one database or a pool of independent tenant databases
  • Your workload is intermittent and suits serverless auto-pause
  • You need very large databases or many read replicas (Hyperscale)
  • You want the smallest entry cost and the least networking setup

Choose SQL Managed Instance if

  • You are migrating an existing SQL Server instance and rely on Agent jobs, cross-database queries, CLR, linked servers or Service Broker
  • You need a minimal-downtime migration or hybrid DR with on-premises SQL Server via the Managed Instance link
  • Your security policy requires the database to sit inside your virtual network with a private IP
  • You want to keep the option to restore databases back to SQL Server 2022 or 2025

When neither is right

Final recommendation

Bottom line

Start from what the application already uses. If it is a new, cloud-designed application that lives in one database, Azure SQL Database is simpler and usually cheaper to start, and serverless or Hyperscale cover a wide range of sizes. If you are moving an existing SQL Server instance and the assessment turns up SQL Server Agent jobs, cross-database queries, CLR, linked servers or Service Broker, Azure SQL Managed Instance is Microsoft's intended target: it keeps those features, sits inside your network and has the strongest migration tooling (Managed Instance link and Log Replay Service). Check Microsoft's feature comparison page for every feature you depend on before committing, because both services change regularly. For tooling, use SSMS for administration of either service and VS Code with the MSSQL extension for cross-platform development.

Frequently asked questions

What is the main difference between Azure SQL Database and Azure SQL Managed Instance?

Scope. Azure SQL Database is a managed database (or pool of databases); Managed Instance is a managed SQL Server instance inside your virtual network. Managed Instance therefore supports instance-level features such as SQL Server Agent, cross-database queries, CLR, linked servers, Service Broker, Database Mail and native copy-only backups to URL, which Azure SQL Database does not.

Does Azure SQL Managed Instance support SQL Server Agent?

Yes, with some differences that Microsoft documents on its T-SQL differences page. Azure SQL Database has no SQL Server Agent; Microsoft points to Elastic jobs instead.

Is there a free tier for Azure SQL Managed Instance?

Yes. Microsoft offers one free General Purpose instance per subscription for 12 months, with 720 vCore hours a month, 4 or 8 vCores and 64 GB of storage, and no SLA. After 12 months the instance stops and is deleted after 30 days unless you upgrade. Azure SQL Database has its own free offer of up to 10 serverless databases per subscription.

Does Managed Instance have a serverless option?

No. Managed Instance uses provisioned vCores. To save cost you can stop and start a General Purpose instance (paying only for storage while stopped), use instance pools, reservations or Azure Hybrid Benefit. Serverless is an Azure SQL Database feature.

What is the Next-gen General Purpose tier?

An upgrade of the Managed Instance General Purpose tier that stores data on Azure Elastic SAN. Microsoft lists up to 128 vCores, 32 TB of storage and 500 databases per instance, flexible memory and 3 free IOPS per GB of reserved storage, at the same baseline cost as General Purpose; extra IOPS and memory are billed. Invoices still show it as General Purpose.

How do I migrate SQL Server to Managed Instance with minimal downtime?

Microsoft recommends the Managed Instance link (near real-time replication over distributed availability groups, SQL Server 2016 and later) for the least downtime. Log Replay Service (continuous restore of backups from Azure Blob storage) and Azure Database Migration Service are the other online options. Azure Data Studio's migration extension is retired along with Azure Data Studio.

Sources

Checked October 2026.

How we research comparisons: our editorial method.

More comparisons

Browse all SQL comparisons or the tools directory.