Azure SQL Managed Instance General Purpose vs Business Critical

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!

Online Resources & Official Documentation:

Disclaimer: The Questions and Answers provided on https://www.gigxp.com are for general information purposes only. We make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability or availability with respect to the website or the information, products, services, or related graphics contained on the website for any purpose.