What is Azure SQL Managed Instance?

APPLIES TO: yesAzure SQL Managed Instance

Part of the Azure SQL product family, Azure SQL Managed Instance is the intelligent, scalable, cloud database service that combines the broadest SQL Server database engine compatibility with all the benefits of a fully managed and evergreen platform as a service. SQL Managed Instance boasts near 100% compatibility with the latest SQL Server (Enterprise Edition) database engine, providing a native virtual network (VNet) implementation that addresses common security concerns, and a business model favorable for existing SQL Server customers. SQL Managed Instance allows existing SQL Server customers to lift and shift their on-premises applications to the cloud with minimal application and database changes. At the same time, the SQL Managed Instance preserves all PaaS capabilities (automatic patching and version updates, automated backups, high-availability ), that drastically reduce management overhead and TCO.


For a list of regions where SQL Managed Instance is currently available, see supported regions.

The following diagram outlines key features of SQL Managed Instances:

key features

Azure SQL Managed Instance is designed for customers looking to migrate a large number of apps from on-premises or IaaS, self-built, or ISV provided environment to fully managed PaaS cloud environment, with as low migration effort as possible. Using the fully automated Data Migration Service (DMS) in Azure, customers can lift and shift their existing SQL Server instances to a SQL Managed Instance that offers compatibility with SQL Server and complete isolation of customer instances with native VNet support. With Software Assurance, you can exchange your existing licenses for discounted rates on a SQL Managed Instance using the Azure Hybrid Benefit for SQL Server. A SQL Managed Instance is the best migration destination in the cloud for SQL Server instances that require high security and a rich programmability surface.

Key features and capabilities

SQL Managed Instance combines the best features that are available both in Azure SQL Database and SQL Server database engine.


SQL Managed Instance runs with all of the features of the most recent version of SQL Server, including online operations, automatic plan corrections, and other enterprise performance enhancements. A comparison of the features available is explained in Feature comparison: Azure SQL Managed Instance versus SQL Server.

PaaS benefits Business continuity
No hardware purchasing and management
No management overhead for managing underlying infrastructure
Quick provisioning and service scaling
Automated patching and version upgrade
Integration with other PaaS data services
99.99% uptime SLA
Built in high-availability
Data protected with automated backups
Customer configurable backup retention period
User-initiated backups
Point in time database restore capability
Security and compliance Management
Isolated environment (VNet integration, single tenant service, dedicated compute and storage)
Transparent data encryption (TDE)
Azure AD authentication, single sign-on support
Azure AD server principals (logins)
Adheres to compliance standards same as Azure SQL Database
SQL auditing
Advanced Threat Protection
Azure Resource Manager API for automating service provisioning and scaling
Azure portal functionality for manual service provisioning and scaling
Data Migration Service


Azure SQL Managed Instance has been certified against a number of compliance standards. For more information, see the Microsoft Azure Compliance Offerings where you can find the most current list of SQL Managed Instance compliance certifications, listed under SQL Database.

The key features of SQL Managed Instance are shown in the following table:

Feature Description
SQL Server version / build SQL Server database engine (latest stable)
Managed automated backups Yes
Built-in instance and database monitoring and metrics Yes
Automatic software patching Yes
The latest Database Engine features Yes
Number of data files (ROWS) per the database Multiple
Number of log files (LOG) per database 1
VNet - Azure Resource Manager deployment Yes
VNet - Classic deployment model No
Portal support Yes
Built-in Integration Service (SSIS) No - SSIS is a part of Azure Data Factory PaaS
Built-in Analysis Service (SSAS) No - SSAS is separate PaaS
Built-in Reporting Service (SSRS) No - use Power BI paginated reports instead or host SSRS on Azure VM. While Managed Instance cannot run SSRS as a service, it can host SSRS 2019 catalog databases for an external reporting server using SQL Server authentication.

vCore-based purchasing model

The vCore-based purchasing model for SQL Managed Instance gives you flexibility, control, transparency, and a straightforward way to translate on-premises workload requirements to the cloud. This model allows you to change compute, memory, and storage based upon your workload needs. The vCore model is also eligible for up to 55 percent savings with the Azure Hybrid Benefit for SQL Server.

In vCore model, you can choose between generations of hardware.

  • Gen4 Logical CPUs are based on Intel E5-2673 v3 (Haswell) 2.4-GHz processors, attached SSD, physical cores, 7-GB RAM per core, and compute sizes between 8 and 24 vCores.
  • Gen5 Logical CPUs are based on Intel E5-2673 v4 (Broadwell) 2.3-GHz and Intel SP-8160 (Skylake) processors, fast NVMe SSD, hyper-threaded logical core, and compute sizes between 4 and 80 cores.

Find more information about the difference between hardware generations in SQL Managed Instance resource limits.

Service tiers

SQL Managed Instance is available in two service tiers:

  • General purpose: Designed for applications with typical performance and IO latency requirements.
  • Business critical: Designed for applications with low IO latency requirements and minimal impact of underlying maintenance operations on the workload.

Both service tiers guarantee 99.99% availability and enable you to independently select storage size and compute capacity. For more information on the high availability architecture of Azure SQL Managed Instance, see High availability and Azure SQL Managed Instance.

General purpose service tier

The following list describes key characteristic of the General Purpose service tier:

  • Design for the majority of business applications with typical performance requirements
  • High-performance Azure Blob storage (8 TB)
  • Built-in high-availability based on reliable Azure Blob storage and Azure Service Fabric

For more information, see storage layer in general purpose tier and storage performance best practices and considerations for SQL Managed Instance (general purpose).

Find more information about the difference between service tiers in SQL Managed Instance resource limits.

Business Critical service tier

Business Critical service tier is built for applications with high IO requirements. It offers highest resilience to failures using several isolated replicas.

The following list outlines the key characteristics of the Business Critical service tier:

Find more information about the difference between service tiers in SQL Managed Instance resource limits.

Management operations

Azure SQL Managed Instance provides management operations that you can use to automatically deploy new managed instances, update instance properties, and delete instances when no longer needed. This section provides information about management operations and their typical durations.

To support deployments within Azure Virtual Networks (VNets) and provide isolation and security for customers, SQL Managed Instance relies on virtual clusters, which represent a dedicated set of isolated virtual machines deployed inside the customer's virtual network subnet. Essentially, every managed instance deployment in an empty subnet results in a new virtual cluster buildout.

Subsequent operations on deployed managed instances might also have effects on its underlying virtual cluster. This affects the duration of management operations, as deploying additional virtual machines comes with an overhead that needs to be considered when you plan new deployments or updates to existing managed instances.

All management operations can be categorized as follows:

  • Instance deployment (new instance creation).
  • Instance update (changing instance properties, such as vCores or reserved storage.
  • Instance deletion.

Typically, operations on virtual clusters take the longest. Duration of the operations on virtual clusters vary – below are the values that you can typically expect, based on existing service telemetry data:

  • Virtual cluster creation: This is a synchronous step in instance management operations. 90% of operations finish in 4 hours.
  • Virtual cluster resizing (expansion or shrinking): Expansion is a synchronous step, while shrinking is performed asynchronously (without impact on the duration of instance management operations). 90% of cluster expansions finish in less than 2.5 hours.
  • Virtual cluster deletion: Deletion is an asynchronous step, but it can also be initiated manually on an empty virtual cluster, in which case it executes synchronously. 90% of virtual cluster deletions finish in 1.5 hours.

Additionally, management of instances may also include one of the operations on hosted databases, which results in longer durations:

  • Attaching database files from Azure Storage: This is a synchronous step, such as compute (vCore), or storage scaling up or down in the General Purpose service tier. 90% of these operations finish in 5 minutes.
  • Always On availability group seeding: This is a synchronous step, such as compute (vCore), or storage scaling in the Business Critical service tier as well as in changing the service tier from General Purpose to Business Critical (or vice versa). Duration of this operation is proportional to the total database size as well as current database activity (number of active transactions). Database activity when updating an instance can introduce significant variance to the total duration. 90% of these operations execute at 220 GB / hour or higher.

The following table summarizes operations and typical overall durations:

Category Operation Long-running segment Estimated duration
Deployment First instance in an empty subnet Virtual cluster creation 90% of operations finish in 4 hours
Deployment First instance of another hardware generation in a non-empty subnet (for example, first Gen 5 instance in a subnet with Gen 4 instances) Virtual cluster creation* 90% of operations finish in 4 hours
Deployment First instance creation of 4 vCores, in an empty or non-empty subnet Virtual cluster creation** 90% of operations finish in 4 hours
Deployment Subsequent instance creation within the non-empty subnet (2nd, 3rd, etc. instance) Virtual cluster resizing 90% of operations finish in 2.5 hours
Update Instance property change (admin password, Azure AD login, Azure Hybrid Benefit flag) N/A Up to 1 minute
Update Instance storage scaling up/down (General Purpose service tier) Attaching database files 90% of operations finish in 5 minutes
Update Instance storage scaling up/down (Business Critical service tier) - Virtual cluster resizing
- Always On availability group seeding
90% of operations finish in 2.5 hours + time to seed all databases (220 GB / hour)
Update Instance compute (vCores) scaling up and down (General Purpose) - Virtual cluster resizing
- Attaching database files
90% of operations finish in 2.5 hours
Update Instance compute (vCores) scaling up and down (Business Critical) - Virtual cluster resizing
- Always On availability group seeding
90% of operations finish in 2.5 hours + time to seed all databases (220 GB / hour)
Update Instance scale down to 4 vCores (General Purpose) - Virtual cluster resizing (if done for the first time, it may require virtual cluster creation**)
- Attaching database files
90% of operations finish in 4 h 5 min**
Update Instance scale down to 4 vCores (Business Critical) - Virtual cluster resizing (if done for the first time, it may require virtual cluster creation**)
- Always On availability group seeding
90% of operations finish in 4 hours + time to seed all databases (220 GB / hour)
Update Instance service tier change (General Purpose to Business Critical and vice versa) - Virtual cluster resizing
- Always On availability group seeding
90% of operations finish in 2.5 hours + time to seed all databases (220 GB / hour)
Deletion Instance deletion Log tail backup for all databases 90% operations finish in up to 1 minute.
Note: if last instance in the subnet is deleted, this operation will schedule virtual cluster deletion after 12 hours***
Deletion Virtual cluster deletion (as user-initiated operation) Virtual cluster deletion 90% of operations finish in up to 1.5 hours

* Virtual cluster is built per hardware generation.

** The 4 vCores option was released in June 2019 and requires a new virtual cluster version. If you had instances in the target subnet that were all created before June 12, a new virtual cluster will be deployed automatically to host 4 vCore instances.

*** 12 hours is the current configuration but that might change in the future, so don't take a hard dependency on it. If you need to delete a virtual cluster earlier (to release the subnet for example), see Delete a subnet after deleting an Azure SQL Managed Instance.

Instance availability during management operations

SQL Managed Instance is not available to client applications during deployment and deletion operations.

SQL Managed Instance is available during update operations except a short downtime caused by the failover that happens at the end of update. It typically lasts up to 10 seconds even in case of interrupted long-running transactions, thanks to the Accelerated database recovery.


It's not recommended to scale compute or storage of Azure SQL Managed Instance or to change service tier at the same time with the long-running transactions (data import, data processing jobs, index rebuild, etc.). Database failover that will be performed at the end of the operation will cancel all ongoing transactions.

Management operations cross-impact

SQL Managed Instance management operations can affect other management operations of the instances placed inside the same virtual cluster. This includes following:

  • Long running restore operations in a virtual cluster will put on hold other instance creation or scaling operation in the same subnet.
    Example: if there is long running restore operation and there is create or scale request in the same subnet, this request will take longer to complete as it will wait for restore operation to complete before it continues.

  • Subsequent instance creation or scaling operation is put on hold by previously initiated instance creation or instance scale that initiated virtual cluster resize.
    Example: if there are multiple create and/or scale requests in the same subnet under the same virtual cluster, and one of them initiates virtual cluster resize, all requests that were submitted 5+ minutes after the one that required virtual cluster resize will last longer than expected as these requests will have to wait for the resize to complete before resuming.

  • Create/scale operations submitted in 5 minute window will be batched and executed in parallel.
    Example: Only one virtual cluster resize will be performed for all operations submitted in 5 minute window (measuring from the moment of executing the first operation request). In case that another request is submitted more than 5 minutes after submitting the first one, it will wait for virtual cluster resize to complete before execution starts.


Management operations that are put on hold because of another operation that is in progress will be automatically resumed once conditions to proceed are met. There is no user action needed to resume temporarily paused management operation.

Canceling management operations

The following table summarizes ability to cancel specific management operations and typical overall durations:

Category Operation Cancelable Estimated cancel duration
Deployment Instance creation No
Update Instance storage scaling up/down (General Purpose) No
Update Instance storage scaling up/down (Business Critical) Yes 90% of operations finish in 5 minutes
Update Instance compute (vCores) scaling up and down (General Purpose) Yes 90% of operations finish in 5 minutes
Update Instance compute (vCores) scaling up and down (Business Critical) Yes 90% of operations finish in 5 minutes
Update Instance service tier change (General Purpose to Business Critical and vice versa) Yes 90% of operations finish in 5 minutes
Delete Instance deletion No
Delete Virtual cluster deletion (as user-initiated operation) No

In order to cancel the management operation, go to the overview blade and click on notification box of ongoing operation. From the right side, a screen with ongoing operation will appear and there will be button for canceling operation. After first click, you will be asked to click again and confirm that you want to cancel the operation.

Cancel operation

After cancel request has been submitted and processed, you will get notification if cancel submission has been successful or not.

In case of cancel success, management operation will be canceled in couple of minutes resulting with a failure.

canceling operation result

If cancel request fails or cancel button is not active, that means that management operation has entered non-cancelable state and that it will finish in couple of minutes. Management operation will continue its execution until it is completed.


Canceling operation is currently supported only in Portal.

Advanced security and compliance

SQL Managed Instance comes with advanced security features provided by the Azure cloud and the SQL Server database engine.

Security isolation

SQL Managed Instance provides additional security isolation from other tenants in the Azure cloud. Security isolation includes:

  • Native virtual network implementation and connectivity to your on-premises environment using Azure Express Route or VPN Gateway.
  • In a default deployment, the SQL endpoint is exposed only through a private IP address, allowing safe connectivity from private Azure or hybrid networks.
  • Single-tenant with dedicated underlying infrastructure (compute, storage).

The following diagram outlines various connectivity options for your applications:

high availability

To learn more details about VNet integration and networking policy enforcement at the subnet level, see VNet architecture for managed instances and Connect your application to a managed instance.


Place multiple managed instance in the same subnet, wherever that is allowed by your security requirements, as that will bring you additional benefits. Collocating instances in the same subnet will significantly simplify networking infrastructure maintenance and reduce instance provisioning time, since long provisioning duration is associated with the cost of deploying the first managed instance in a subnet.

Security Features

Azure SQL Managed Instance provides a set of advanced security features that can be used to protect your data.

  • SQL Managed Instance auditing tracks database events and writes them to an audit log file placed in your Azure storage account. Auditing can help maintain regulatory compliance, understand database activity, and gain insight into discrepancies and anomalies that could indicate business concerns or suspected security violations.
  • Data encryption in motion - a SQL Managed Instance secures your data by providing encryption for data in motion using Transport Layer Security. In addition to transport layer security, SQL Managed Instance offers protection of sensitive data in-flight, at-rest and during query processing with Always Encrypted. Always Encrypted is an industry-first that offers unparalleled data security against breaches involving the theft of critical data. For example, with Always Encrypted, credit card numbers are stored encrypted in the database always, even during query processing, allowing decryption at the point of use by authorized staff or applications that need to process that data.
  • Advanced Threat Protection complements auditing by providing an additional layer of security intelligence built into the service that detects unusual and potentially harmful attempts to access or exploit databases. You are alerted about suspicious activities, potential vulnerabilities, and SQL injection attacks, as well as anomalous database access patterns. Advanced Threat Protection alerts can be viewed from Azure Security Center and provide details of suspicious activity and recommend action on how to investigate and mitigate the threat.
  • Dynamic data masking limits sensitive data exposure by masking it to non-privileged users. Dynamic data masking helps prevent unauthorized access to sensitive data by enabling you to designate how much of the sensitive data to reveal with minimal impact on the application layer. It's a policy-based security feature that hides the sensitive data in the result set of a query over designated database fields, while the data in the database is not changed.
  • Row-level security enables you to control access to rows in a database table based on the characteristics of the user executing a query (such as by group membership or execution context). Row-level security (RLS) simplifies the design and coding of security in your application. RLS enables you to implement restrictions on data row access. For example, ensuring that workers can access only the data rows that are pertinent to their department, or restricting a data access to only the relevant data.
  • Transparent data encryption (TDE) encrypts SQL Managed Instance data files, known as encrypting data at rest. TDE performs real-time I/O encryption and decryption of the data and log files. The encryption uses a database encryption key (DEK), which is stored in the database boot record for availability during recovery. You can protect all your databases in a managed instance with transparent data encryption. TDE is SQL Server's proven encryption-at-rest technology that is required by many compliance standards to protect against theft of storage media.

Migration of an encrypted database to a SQL Managed Instance is supported via the Azure Database Migration Service (DMS) or native restore. If you plan to migrate an encrypted database using native restore, migration of the existing TDE certificate from the SQL Server instance to a SQL Managed Instance is a required step. For more information about migration options, see SQL Server migration to SQL Managed Instance.

Azure Active Directory Integration

SQL Managed Instance supports traditional SQL Server database engine logins and logins integrated with Azure Active Directory (Azure AD). Azure AD server principals (logins) (public preview) are Azure cloud version of on-premises database logins that you are using in your on-premises environment. Azure AD server principals (logins) enable you to specify users and groups from your Azure Active Directory tenant as true instance-scoped principals, capable of performing any instance-level operation, including cross-database queries within the same managed instance.

A new syntax is introduced to create Azure AD server principals (logins), FROM EXTERNAL PROVIDER. For more information on the syntax, see CREATE LOGIN, and review the Provision an Azure Active Directory administrator for your SQL Managed Instance article.

Azure Active Directory integration and multi-factor authentication

SQL Managed Instance enables you to centrally manage identities of database user and other Microsoft services with Azure Active Directory integration. This capability simplified permission management and enhances security. Azure Active Directory supports multi-factor authentication (MFA) to increase data and application security while supporting a single sign-on process.


SQL Managed Instance authentication refers to how users prove their identity when connecting to the database. SQL Managed Instance supports two types of authentication:

  • SQL Authentication:

    This authentication method uses a username and password.

  • Azure Active Directory Authentication:

    This authentication method uses identities managed by Azure Active Directory and is supported for managed and integrated domains. Use Active Directory authentication (integrated security) whenever possible.


Authorization refers to what a user can do within a database in Azure SQL Managed Instance, and is controlled by your user account's database role memberships and object-level permissions. A SQL Managed Instance has same authorization capabilities as SQL Server 2017.

Database migration

SQL Managed Instance targets user scenarios with mass database migration from on-premises or IaaS database implementations. SQL Managed Instance supports several database migration options:

Backup and restore

The migration approach leverages SQL backups to Azure Blob storage. Backups stored in Azure storage blob can be directly restored into a SQL Managed Instance using the T-SQL RESTORE command.

  • For a quickstart showing how to restore the Wide World Importers - Standard database backup file, see Restore a backup file to a managed instance. This quickstart shows you have to upload a backup file to Azure blob storage and secure it using a Shared access signature (SAS) key.
  • For information about restore from URL, see Native RESTORE from URL.


Backups from a SQL Managed Instance can only be restored to another SQL Managed Instance. They cannot be restored to a SQL Server instance or to Azure SQL Database.

Data Migration Service

The Azure Database Migration Service is a fully managed service designed to enable seamless migrations from multiple database sources to Azure Data platforms with minimal downtime. This service streamlines the tasks required to move existing third party and SQL Server databases to Azure SQL Database, Azure SQL Managed Instance, and SQL Server in Azure VM. See How to migrate your on-premises database to SQL Managed Instance using DMS.

SQL features supported

SQL Managed Instance aims to deliver close to 100% surface area compatibility with the latest SQL Server version through a staged release plan. For a features and comparison list, see SQL Managed Instance feature comparison, and for a list of T-SQL differences in SQL Managed Instance versus SQL Server, see SQL Managed Instance T-SQL differences from SQL Server.

SQL Managed Instance supports backward compatibility to SQL 2008 databases. Direct migration from SQL 2005 database servers is supported, compatibility level for migrated SQL 2005 databases are updated to SQL 2008.

The following diagram outlines surface area compatibility in SQL Managed Instance:


Key differences on-premises and SQL Managed Instance

SQL Managed Instance benefits from being always-up-to-date in the cloud, which means that some features in SQL Server may be either obsolete, retired, or have alternatives. There are specific cases when tools need to recognize that a particular feature works in a slightly different way or that the service is running in an environment you do not fully control.

Some key differences:

  • High-availability is built in and pre-configured using technology similar to Always On availability groups.
  • There are only automated backups and point in time restore. Customer can initiate copy-only backups that do not interfere with automatic backup chain.
  • Specifying full physical paths is unsupported so all corresponding scenarios have to be supported differently: RESTORE DB does not support WITH MOVE, CREATE DB doesn't allow physical paths, BULK INSERT works with Azure Blobs only, etc.
  • SQL Managed Instance supports Azure AD authentication as cloud alternative to Windows authentication.
  • SQL Managed Instance automatically manages XTP filegroup and files for databases containing In-Memory OLTP objects
  • SQL Managed Instance supports SQL Server Integration Services (SSIS) and can host SSIS catalog (SSISDB) that stores SSIS packages, but they are executed on a managed Azure-SSIS Integration Runtime (IR) in Azure Data Factory (ADF), see Create Azure-SSIS IR in ADF. To compare the SSIS features, see Compare SQL Database to SQL Managed Instance.

Administration features

SQL Managed Instance enables system administrator to spend less time on administrative tasks because the SQL Managed Instance service either performs them for you or greatly simplifies those tasks. For example, OS / RDBMS installation and patching, dynamic instance resizing and configuration, backups, database replication (including system databases), high availability configuration, and configuration of health and performance monitoring data streams.

For more information see a list of supported and unsupported SQL Managed Instance features, and T-SQL differences between SQL Managed Instance and SQL Server

Programmatically identify a managed instance

The following table shows several properties, accessible through Transact-SQL, that you can use to detect that your application is working with SQL Managed Instance and retrieve important properties.

Property Value Comment
@@VERSION Microsoft SQL Azure (RTM) - 12.0.2000.8 2018-03-07 Copyright (C) 2018 Microsoft Corporation. This value is same as in SQL Database. This does not indicate SQL engine version 12 (SQL Server 2014). SQL Managed Instance always runs the latest stable SQL engine version, which is equal to or higher than latest available RTM version of SQL Server.
SERVERPROPERTY ('Edition') SQL Azure This value is same as in SQL Database.
SERVERPROPERTY('EngineEdition') 8 This value uniquely identifies a managed instance.
@@SERVERNAME, SERVERPROPERTY ('ServerName') Full instance DNS name in the following format:<instanceName>.<dnsPrefix>.database.windows.net, where <instanceName> is name provided by the customer, while <dnsPrefix> is autogenerated part of the name guaranteeing global DNS name uniqueness ("wcus17662feb9ce98", for example) Example: my-managed-instance.wcus17662feb9ce98.database.windows.net

Next steps