Azure SQL Managed Instance

About Azure SQL Managed Instance

Azure SQL Managed Instance is a fully managed platform as a service database for organizations that want broad SQL Server compatibility without operating the underlying virtual machines and operating system. Microsoft manages core platform work such as patching, version updates, automated backups and high availability, while database teams retain familiar SQL Server capabilities including SQL Server Agent, native backup and restore, Query Store and many instance-scoped features. It is designed mainly for existing SQL Server applications that need a low-change path into Azure and for teams that want to consolidate multiple databases on a managed SQL instance.

What workloads fit Azure SQL Managed Instance best?

Azure SQL Managed Instance is strongest when an application depends on SQL Server instance-level behavior that is not a natural fit for Azure SQL Database. Microsoft positions it for lift-and-shift and modernization projects where teams want close compatibility with the SQL Server Database Engine while reducing responsibility for operating system and database-engine maintenance. Common scenarios include moving line-of-business systems from on-premises SQL Server, consolidating databases that share instance resources, retaining SQL Server Agent jobs, and modernizing applications that would require too many changes for a database-only PaaS model.

It can also suit organizations that need virtual network deployment and private connectivity as part of the database design. The service does not provide operating-system access. Workloads that require host agents, custom drivers, file-system control or unsupported SQL Server capabilities can be better suited to SQL Server on Azure Virtual Machines.

How compatible is it with SQL Server?

Microsoft describes Azure SQL Managed Instance as offering close to 100 percent surface-area compatibility with the latest SQL Server Database Engine. It supports many familiar capabilities such as SQL Server Agent, native backup and restore, multiple data files, Query Store, dynamic management views, Extended Events, auditing, encryption and instance-scoped configuration that many migrated applications expect.

Compatibility is broad but not absolute. Microsoft recommends an assessment before migration because some SQL Server features remain unsupported or behave differently in the managed environment. Managed Instance is also an evergreen service rather than a way to pin an arbitrary legacy SQL Server build indefinitely. Applications that require exact operating-system control or strict dependency on an older SQL Server version should evaluate SQL Server on Azure Virtual Machines.

What changed in Azure SQL Managed Instance during 2026?

Microsoft's current What's New documentation lists several important 2026 changes. Automatic backup immutability became generally available in August 2026 and protects up to the most recent seven days of point-in-time restore backups. Internal connectivity testing became generally available in May 2026. Those automatic tests run every 10 seconds from internal IP addresses in the managed instance subnet and can create expected failed-login entries using the AzureSQLConnectivityChecker identity in logs and auditing data.

In March 2026 Microsoft made the SQL Server 2025 update policy generally available. That policy aligns a managed instance database format with the SQL Server 2025 database engine and adds compatibility for SQL Server 2025-oriented capabilities such as restore to SQL Server 2025 and bidirectional Managed Instance link scenarios with SQL Server 2025. Microsoft also made the ability to block T-SQL CRUD commands generally available in March 2026, allowing Azure administrators to prevent T-SQL commands from creating or modifying Azure SQL resources at the subscription level.

General Purpose, Next-gen General Purpose and Business Critical

Azure SQL Managed Instance uses a vCore purchasing model. General Purpose is the usual starting point for many business workloads and uses remote storage. Business Critical is designed for workloads that need lower storage latency and higher availability characteristics, including local SSD-based architecture and read scale-out capabilities.

Next-gen General Purpose expands the General Purpose option with higher storage limits and newer performance characteristics. Microsoft's current comparison documentation lists up to 32 TB for supported Next-gen General Purpose configurations, compared with up to 16 TB in the standard documented General Purpose range.

As of August 2026, Microsoft lists zone redundancy for Next-gen General Purpose as preview. That preview status matters for production architecture reviews. Buyers that require a generally available zone-redundant configuration should verify the current supported tier and region before deployment rather than assuming every Managed Instance tier has the same availability options.

How does pricing work?

Pricing was checked on August 31, 2026. Microsoft prices Azure SQL Managed Instance around provisioned compute, storage and backup consumption. Compute is measured in vCores, while storage and qualifying backup usage are billed separately. Microsoft offers license-included pricing and a lower base-rate option for eligible customers applying Azure Hybrid Benefit with qualifying SQL Server licenses and Software Assurance.

Microsoft also offers pay-as-you-go, savings plan for databases, and one-year or three-year reservations for supported configurations. Regional rates, hardware generation, service tier, vCore count, storage, backup retention, redundancy and licensing choices all affect the bill, so there is no one universal monthly price.

For disaster recovery, Microsoft documents licensing benefits for qualifying passive secondary instances. Compute and storage can still be billed even when SQL Server licensing charges are reduced or removed under the applicable benefit. Buyers should confirm current eligibility and terms before budgeting around this option.

What should buyers know about backups and recovery?

Managed Instance includes automated full, differential and transaction log backups for point-in-time recovery. Microsoft's current business-continuity documentation states that seven days is the default point-in-time retention period and that it can be configured up to 35 days. Long-term retention can preserve selected full backups for up to 10 years for compliance or business requirements.

Automatic backup immutability became generally available in August 2026. Microsoft states that it protects up to the most recent seven days of point-in-time restore backups. This adds protection against backup deletion or tampering during that protected window and should be evaluated alongside retention, recovery and compliance requirements.

Business continuity still needs architecture beyond backups. Zone redundancy protects against supported zonal failures, failover groups can continuously synchronize a secondary instance in another region, and geo-restore can create a database from geo-replicated backups after a regional outage. These approaches have different recovery objectives, cost and operational tradeoffs.

How do migration and networking work?

Microsoft supports several migration paths depending on source environment and downtime requirements, including native backup and restore, Azure Database Migration Service, Managed Instance link and Log Replay Service. Managed Instance link is useful for supported low-downtime scenarios because it uses Always On technology to replicate changes from SQL Server to Managed Instance before cutover.

Networking needs more planning than a simple public database endpoint. Azure SQL Managed Instance uses a virtual-network-based architecture and requires a properly configured delegated subnet. Teams should plan address space, DNS, routing, private connectivity, firewall rules and application access before migration, especially when the application remains on-premises or in another network.

Microsoft changed quota request handling in August 2026. Subnet quotas no longer apply, and vCore quotas are now scoped by hardware generation. Capacity planning should therefore use the current Managed Instance quota model rather than older subnet-quota assumptions.

Security and identity considerations

Azure SQL Managed Instance supports Microsoft Entra authentication, SQL authentication, managed identities, auditing and encryption capabilities in the Azure SQL family. Microsoft documents encryption for data in transit with TLS and supports Transparent Data Encryption and Always Encrypted for supported scenarios. Managed identities can reduce the need to place reusable credentials in application configuration when Azure resources authenticate to the database service.

Security still depends on customer configuration. Database permissions, Entra roles, network exposure, private endpoints, auditing destinations, encryption keys, backup policies and administrative access need explicit governance. A managed service removes operating-system administration, but it does not remove responsibility for least privilege, data classification, access review or application-level security.

Azure SQL Managed Instance vs Azure SQL Database

Azure SQL Database is usually the better fit for cloud-native applications that mainly need database-level capabilities and want fine-grained scaling at the individual database or elastic-pool level. Azure SQL Managed Instance provides broader instance-level compatibility, shared instance resources and a migration experience that is closer to traditional SQL Server.

The tradeoff is that Managed Instance is a larger infrastructure unit with more networking and capacity planning than a single Azure SQL Database. Teams building a new application from scratch should not assume that higher SQL Server compatibility is automatically better. If the application only needs standard relational database functions, Azure SQL Database can be simpler and more granular.

What are the main limitations?

Managed Instance does not provide customer access to the underlying operating system or file system. Microsoft also documents SQL Server scenarios that can make SQL Server on Azure Virtual Machines a better target, including workloads that require host-level agents, exact control over SQL Server versions or unsupported engine features.

Resource limits also apply. Microsoft's current Azure SQL comparison lists Managed Instance at up to 128 vCores and up to 16 TB of storage in the standard documented range, with up to 32 TB for supported Next-gen General Purpose configurations. Actual storage limits vary by tier, hardware family, vCore count and region. Buyers should use the current resource-limit table rather than treating the maximum number as available for every configuration.

Several newer features remain in preview, including zone redundancy for Next-gen General Purpose, change event streaming, automatic index compaction and some flexible-memory scenarios. Production architecture should distinguish preview features from generally available capabilities.

Who should choose something else?

Choose Azure SQL Database when you are building a cloud-native application that does not need broad instance-level SQL Server compatibility and you want simpler per-database scaling. Choose SQL Server on Azure Virtual Machines when you need operating-system access, custom agents, exact control over SQL Server versions, unsupported instance features or the closest match to a traditional self-managed SQL Server environment.

Organizations with PostgreSQL or MySQL applications should evaluate Azure Database for PostgreSQL or Azure Database for MySQL rather than moving to SQL Server solely to use Managed Instance. Teams with very small workloads should also compare the minimum practical Managed Instance footprint with simpler database services, because consolidation and SQL Server compatibility are core reasons to choose this service.