In this article, I will try to compare the Azure SQL Managed Instance General Purpose vs Business Critical service tiers based on the information available online. While comparing might be easy, actual real-world performance might differ. After all, it is based on your application needs.
For starters, the managed instance offering is for enterprises which are looking to replace their on-premises SQL deployments. It is especially true for a customer who is merely seeking to “lift & shift” to the cloud quickly, without any hindrances.
For enterprises with large SQL Server deployments, the managed instance offering enables them to free up limited IT resources and drive cloud transformation. Companies can plan to migrate their existing on-premises business critical apps or move their SQL servers running on Azure VMs.
Some of the features that I like on the Azure SQL Databases are as follows:
- AAD or Azure Active Directory Integration with multi-factor authentication support
- Advanced threat detection and protection
- Adaptive Query Processing for automatic query plan tuning
- Easy scaling of Database resources
Azure SQL Database offerings
Microsoft’s PAAS (Platform as a Service) offerings have evolved and offer multiple choices. They are as follows:
- Azure SQL Database in Single Mode: best for database scoped deployment
- Elastic Pool Databases: best for companies building multi-tenant applications
- Managed Instance: near full compatibility with SQL Server with PAAS self advantages. Instance level scope.
Azure SQL Database Managed Instance provides total workload isolation of your workloads through native VNET (Virtual Network) support. Microsoft uses virtual data clusters to define the degree of separation that customer workloads will experience with SQL Database Managed Instance. During managed instance service provisioning (on Azure Portal or through REST API), you can choose the virtual network (VNET) and the network subnet to achieve full networking isolation for your SQL Managed Instances. Once created, instances in the VNET can be reached using Azure networking mechanisms like IP VPN (over the Internet) or Express Route gateways (Dedicated).
Two levels of Physical Isolation Levels are provided:
Cluster (tenant ring) level: Managed Instances for a tenant are fully isolated from other tenants. No connectivity or resource sharing is possible across different tenants.
Networking level: joining instances to a private subnet in a VNET and restricting access to private IP address range provides full isolation from the outside public Internet.
To elaborate, for customers looking to migrate a large number of apps from on-premise or IaaS (Infrastructure as a Service), self-built or ISVs, with as low migration effort as possible & low cost of ownership. Now that is clear; let’s dig a bit deeper into the managed instance offerings.
Azure SQL Managed Instance General Purpose vs Business Critical
Both the service tiers come with Gen 4 and Gen 5 selectable hardware options. So, the storage size and vCore multiples differ based on which generation you select. Here is some high-level size by side comparison of the managed instance service tiers:
Service Tier | General Purpose | Business Critical |
Audience | For applications with typically loads. Mixed of Reads/Writes | For applications that require the highest throughput and lowest IO latency. |
CPU & Virtual Cores (vCores) | Gen 4 CPU: Intel Xeon E5-2673 v3 (Haswell) @ 2.4 GHz
Gen 5: Intel Xeon E5-2673 v4 (Broadwell) @ 2.3 GHz processors 8, 15, 24, 32, 40, 64, 80 |
Gen 4 CPU: Intel Xeon E5-2673 v3 (Haswell) @ 2.4 GHz
Gen 5: Intel Xeon E5-2673 v4 (Broadwell) @ 2.3 GHz processors 8, 16, 32, 40, 64, 80 |
High Availability & RTO | Remote Storage (Service Fabric)
RTO = Good |
Always on Availability Group Cluster
RTO = Best |
Storage Type &
Max Storage Size Support |
Premium Disks
8 TB of Data Storage (Remote) 32 GB minimum Storage Max Storage per DB: Based on total Instance level storage space available Datafiles (MDF) – Multiple LDF (Log): Single |
Low-Latency NVMe based local SSD
Max size = 4 TB 32 GB minimum Storage Gen 4: 1 TB (all vCore sizes) Gen 5: 1 TB for 8, 16 vCores 2 TB for 24 vCores 4 TB for 32, 40, 64, 80 vCores Max Storage per DB: Based on total Instance level storage space available Datafiles (MDF) – Multiple LDF (Log): 1 per Datafile |
Read Scale (Read Only Replica) | No | Yes, Read Intent Query support |
In-Memory OLTP | No | Yes, supported – Durable & Non-Durable Tables |
Drivers & Tool Compatibility | 4.6.1 (or .NET Core)
ODBC: v17 PHP driver : 5.2.0 JDBC: 6.4.0 Node: 2.1.1 OLEDB: 18.0.2.0 SSMS (Management Studio): 17.8.1 |
4.6.1 (or .NET Core)
ODBC: v17 PHP driver : 5.2.0 JDBC: 6.4.0 Node: 2.1.1 OLEDB: 18.0.2.0 SSMS (Management Studio): 17.8.1 |
Backup system | Automated Managed Backups | Automated Managed Backups |
As you can see, there are quite a few combinations available for you to choose. You can easily move across service tiers on the fly with minimum downtime. This ensures that you can always meet the demand of your front-end apps based on growing needs.
Conclusion
We hope our article helped to understand the service tiers better. Your questions and suggestions are welcome in the comments section below. Thanks for visiting!