Business Critical tier - Azure SQL Database and Azure SQL Managed Instance

Applies to: Azure SQL Database Azure SQL Managed Instance

Azure SQL Database and Azure SQL Managed Instance are both based on the SQL Server database engine architecture adjusted for the cloud environment in order to ensure default SLA availability even in cases of infrastructure failures.

This article describes and compares the Business Critical service tier used by Azure SQL Database and Azure SQL Managed instance. The Business Critical service tier is best used for applications requiring high transaction rate, low IO latency, and high IO throughput. This service tier offers the highest resilience to failures and fast failovers using multiple synchronously updated replicas.

Overview

The Business Critical service tier model is based on a cluster of database engine processes. This architectural model relies on a fact that there's always a quorum of available database engine nodes and has minimal performance impact on your workload even during maintenance activities.

Azure upgrades and patches underlying operating system, drivers, and SQL Server database engine transparently with the minimal down-time for end users.

In the Business Critical model, compute and storage is integrated on each node. High availability is achieved by replication of data between database engine processes on each node of a four node cluster, with each node using locally attached SSD as data storage. This technology is similar to SQL Server Always On availability groups.

Cluster of database engine nodes

Both the SQL Server database engine process and underlying .mdf/.ldf files are placed on the same node with locally attached SSD storage providing low latency to your workload. High availability is implemented using technology similar to SQL Server Always On availability groups. Every database is a cluster of database nodes with one primary database that is accessible for customer workloads, and a three secondary processes containing copies of data. The primary node constantly pushes changes to the secondary nodes in order to ensure that the data is available on secondary replicas if the primary node fails for any reason. Failover is handled by the SQL Server database engine – one secondary replica becomes the primary node and a new secondary replica is created to ensure there are enough nodes in the cluster. The workload is automatically redirected to the new primary node.

In addition, the Business Critical cluster has built-in Read Scale-Out capability that provides free-of charge built-in read-only replica that can be used to run read-only queries (for example reports) that shouldn't affect performance of your primary workload.

When to choose this service tier

The Business Critical service tier is designed for applications that require low-latency responses from the underlying SSD storage (1-2 ms in average), fast recovery if the underlying infrastructure fails, or need to off-load reports, analytics, and read-only queries to the free of charge readable secondary replica of the primary database.

The key reasons why you should choose Business Critical service tier instead of General Purpose tier are:

  • Low I/O latency requirements – workloads that need a fast response from the storage layer (1-2 milliseconds in average) should use Business Critical tier.
  • Workload with reporting and analytic queries that can be redirected to the free-of-charge secondary read-only replica.
  • Higher resiliency and faster recovery from failures. In a case of system failure, the database on primary instance will be disabled and one of the secondary replicas will be immediately became new read-write primary database that is ready to process queries. The database engine doesn't need to analyze and redo transactions from the log file and load all data in the memory buffer.
  • Advanced data corruption protection. The Business Critical tier leverages database replicas behind-the-scenes for business continuity purposes, and so the service also then leverages automatic page repair, which is the same technology used for SQL Server database mirroring and availability groups. In the event that a replica can't read a page due to a data integrity issue, a fresh copy of the page will be retrieved from another replica, replacing the unreadable page without data loss or customer downtime. This functionality is applicable in General Purpose tier if the database has geo-secondary replica.
  • Higher availability - The Business Critical tier in Multi-AZ configuration provides resiliency to zonal failures and a higher availability SLA.
  • Fast geo-recovery - When active geo-replication is configured, the Business Critical tier has a guaranteed Recovery Point Objective (RPO) of 5 seconds and Recovery Time Objective (RTO) of 30 seconds for 100% of deployed hours.

Compare Business Critical resource limits

Review the table in this section for a brief overview comparison of the resource limits for Azure SQL Database and Azure SQL managed Instance in the Business Critical service tier.

For comprehensive details about resource limits, review:

To compare features between SQL Database and SQL Managed Instance, see the database engine features.

The following table shows resource limits for both Azure SQL Database and Azure SQL Managed Instance in the Business Critical service tier.

Category Azure SQL Database Azure SQL Managed Instance
Compute size 1 to 128 vCores 4, 8, 16, 24, 32, 40, 64, 80 vCores
Storage type Local SSD storage Local SSD storage
Storage size 1 GB – 4 TB 32 GB – 16 TB
Tempdb size 32 GB per vCore Up to 4 TB - limited by storage size
Log write throughput Single databases: 12 MB/s per vCore (max 96 MB/s)
Elastic pools: 15 MB/s per vCore (max 120 MB/s)
4 MB/s per vCore (max 48 MB/s)
Availability Default SLA
99.995% SLA with zone redundancy
Default SLA
Backups RA-GRS, 1-35 days (7 days by default) RA-GRS, 1-35 days (7 days by default)
Read-only replicas 1 built-in high availability replica is readable
0 - 4 geo-replicas
1 built-in high availability replica is readable
0 - 1 geo-replicas using auto-failover groups
Pricing/Billing vCore, reserved storage, backup storage, and geo-replicas are charged.
High availability replicas aren't charged.
IOPS isn't charged.
vCore, reserved storage, backup storage, and geo-replicas are charged.
High availability replicas aren't charged.
IOPS isn't charged.
Discount models Reserved instances
Azure Hybrid Benefit (not available on dev/test subscriptions)
Enterprise and Pay-As-You-Go Dev/Test subscriptions
Reserved instances
Azure Hybrid Benefit (not available on dev/test subscriptions)
Enterprise and Pay-As-You-Go Dev/Test subscriptions

Next steps