| title | description | services | ms.service | ms.subservice | ms.custom | ms.devlang | ms.topic | author | ms.author | ms.reviewer | manager | ms.date |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
Azure SQL Database resource limits - managed instance | Microsoft Docs |
This article provides an overview of the Azure SQL Database resource limits for managed instances. |
sql-database |
sql-database |
managed-instance |
conceptual |
bonova |
bonova |
carlrab, jovanpop, sachinp |
craigg |
12/03/2018 |
This article provides an overview of the Azure SQL Database Managed Instance resource limits and provides information how to create request to increase default regional subscription limits.
Note
For other Managed Instance limitations, see vCore-based purchasing model and Managed Instance service tiers. For differences in supported features and T-SQL statements see Feature differences and T-SQL statement support.
Managed Instance has characteristics and resource limits that depends on the underlying infrastructure and architecture. Limits depend on hardware generation and service tier.
Azure SQL Database Managed Instance can be deployed on two hardware generation (Gen4 and Gen5). Hardware generations have different characteristics that are described in the following table:
| Gen 4 | Gen 5 | |
|---|---|---|
| Hardware | Intel E5-2673 v3 (Haswell) 2.4-GHz processors, attached SSD vCore = 1 PP (physical core) | Intel E5-2673 v4 (Broadwell) 2.3-GHz processors, fast eNVM SSD, vCore=1 LP (hyper-thread) |
| Compute | 8, 16, 24 vCores | 8, 16, 24, 32, 40, 64, 80 vCores |
| Memory | 7 GB per vCore | 5.1 GB per vCore |
| Max storage (Business Critical) | 1 TB | 1 TB, 2 TB, or 4 TB depending on the number of cores |
Managed Instance has two service tiers - General Purpose and Business Critical. These tiers provide different capabilities, as described in the table below:
| Feature | General Purpose | Business Critical |
|---|---|---|
| Number of vCores* | Gen4: 8, 16, 24 Gen5: 8, 16, 24, 32, 40, 64, 80 |
Gen4: 8, 16, 24, 32 Gen5: 8, 16, 24, 32, 40, 64, 80 |
| Memory | Gen4: 56GB-156GB Gen5: 44GB-440GB *Proportional to the number of vCores |
Gen4: 56GB-156GB Gen5: 44GB-440GB *Proportional to the number of vCores |
| Max storage size | 8 TB | Gen 4: 1 TB Gen 5: - 1 TB for 8, 16 vCores - 2 TB for 24 vCores - 4 TB for 32, 40, 64, 80 vCores |
| Max storage per database | Determined by the max storage size per instance | Determined by the max storage size per instance |
| Max number of databases per instance | 100 | 100 |
| Max database files per instance | Up to 280 | 32,767 files per database |
| IOPS (approximate) | 500-7500 per file *Depends on the file size |
11K - 110K (1375 per vCore) |
| IO latency (approximate) | 5-10 ms | 1-2 ms |
| Max tempDB size | 192-1920 GB (24 GB per vCore) | Determined by the max storage size per instance |
- Both user and system databases are included in the instance storage size that is compared with the Max storage size limit. Use sys.master_files system view to determine the total used space by databases. Error logs are not persisted and not included in the size. Backups are not included in storage size.
Managed Instanced can be created only in supported regions. If you want to create a Managed Instance in the region that is currently not supported, you can send support request via Azure portal.
Managed Instance currently supports deployment only on the following types of subscriptions:
Note
This limitation is temporary. New subscription types will be enabled in the future.
Supported subscription types can contain a limited number of resources per region. Managed Instance has two default limits per Azure region depending on a type of subscription type:
- Subnet limit: The maximum number of subnets where managed instances are deployed in a single region.
- Instance number limit: The maximum number of instances that can be deployed in a single region.
In the following table are shown default regional limits for supported subscriptions:
| Subscription type | Max number of Managed Instance subnets | Max number of instances | Max number of GP managed instances* | Max number of BC managed instances* |
|---|---|---|---|---|
| Pay-as-you-go | 1* | 4* | 4* | 1* |
| CSP | 1* | 4* | 4* | 1* |
| EA | 3** | 12** | 12** | 3** |
* You can either deploy 1 BC or 4 GP instances in one subnet, so that total number of “instance units” in the subnet never exceeds 4.
** Maximum number of instances in one service tier applies if there are no instances in another service tier. In case you plan to mix GP and BC instances within same subnet, use the following section as a reference for allowed combinations. As a simple rule, the total number of subnets cannot exceed 3, and the total number of instance units cannot exceed 12.
These limits can be increased by creating special support request in the Azure portal if you need more Managed Instances in the current region. As an alternative, you can create new Managed Instances in another Azure region without sending support requests.
Important
When planning your deployments, consider that a Business Critical (BC) instance (due to added redundancy) generally consumes 4x more capacity than a General Purpose (GP) instance. So, for your calculations, 1 GP instance = 1 instance unit and 1 BC instance = 4 instance units. To simplify your consumption analysis against the default limits, summarize the instance units across all subnets in the region where Managed Instances are deployed and compare the results with the instance unit limits for your subscription type.
Enterprise Agreement (EA) subscriptions can have combinations of GP and BC instances. However, there are some constraints regarding the placement of the instances in the subnets.
Note
Pay-as-you-go and Cloud Service Provider (CSP) subscription types can have either one Business Critical or up to 4 General Purpose instances.
The following examples cover deployment cases with non-empty subnets and mixed GP and BC service tiers.
| Number of subnets | Subnet 1 | Subnet 2 | Subnet 3 |
|---|---|---|---|
| 1 | 1 BC and up to 8 GP 2 BC and up to 4 GP |
N/A | N/A |
| 2 | 0 BC, up to 4 GP | 1 BC, up to 4 GP 2 BC, 0 GP |
N/A |
| 2 | 1 BC, 0 GP | 0 BC, up to 8 GP 1 BC, up to 4 GP |
N/A |
| 2 | 2 BC, 0 GP | 0 BC, up to 4 GP | N/A |
| 3 | 1 BC, 0 GP | 1 BC, 0 GP | 0 BC, up to 4 GP |
| 3 | 1 BC, 0 GP | 0 BC, up to 4 GP | 0 BC, up to 4 GP |
If you need more Managed Instances in your current regions, you can send the support request to extend the quota using Azure portal. To initiate the process of obtaining a larger quota:
-
Open Help + support, and click New support request.
-
On the Basics tab for the new support request:
-
For Issue type, select Service and subscription limits (quotas).
-
For Subscription, select your subscription.
-
For Quota type, select SQL Database Managed Instance.
-
For Support plan, select your support plan.
-
-
Click Next.
-
On the Problem tab for the new support request:
-
For Severity, select the severity level of the problem.
-
For Details, provide additional information about your issue, including error messages.
-
For File upload, attach a file with more information (up to 4 MB).
[!IMPORTANT] A valid request should include:
- Region in which subscription limit needs to be increased
- Required number of instances, per service tier in existing subnets after the quota increase (if any of the existing subnets needs to be expanded
- Required number of new subnets and total number of instances per service tier within the new subnets (if you need to deploy managed instances in new subnets).
-
-
Click Next.
-
On the Contact Information tab for the new support request, enter preferred contact method (email or phone) and the contact details.
-
Click Create.
- For more information about Managed Instance, see What is a Managed Instance?.
- For pricing information, see SQL Database Managed Instance pricing.
- To learn how to create your first Managed Instance, see Quick-start guide.