Within a region, the service tier decides how your database survives node and zone failures; across regions, you add geo-replication or failover groups. Getting the tier right matters because cost savings never override a hard latency or zone-resilience requirement.
High availability by tier
Figure 6.2 compares how each tier is built for availability.
| Tier | Storage / replicas | Latency | No-data-loss failover | Zone-redundant |
|---|---|---|---|---|
| General Purpose (and serverless) | Single compute node, remote premium storage | Higher | No replica | Yes |
| Business Critical (vCore) / Premium (DTU) | Always On replicas on local SSD, synchronous commit | Lowest | Yes, automatic | Yes, across three zones |
- “Minimise cost” never overrides hard latency or zone requirements. The cheapest single database with synchronous zone-redundant replicas is Premium (DTU).
- Read scale-out on Business Critical/Premium gives you one readable secondary, with no load balancing.
Common trap: General Purpose for a workload that needs both zone resilience and the lowest latency — its remote storage is slower. Business Critical (or Premium) is needed.
Common trap: General Purpose for no-data-loss failover — it has no synchronous replica. Choose Business Critical or Premium.
Regional resilience: failover groups and geo-replication
- Auto-failover group (failover group): geo-replicates a whole Managed Instance (or a group of databases) with automatic failover and stable listener endpoints. It is the only regional-outage protection for Managed Instance, and the geo-secondary is readable through the read-only listener on either tier.
- Active geo-replication: configured per SQL database, manual failover, not available on Managed Instance; secondaries are read-only.
Common trap: A single database with active geo-replication when the workload needs user-initiated backups and automatic regional failover — Managed Instance with a failover group is right.
Managed Instance storage and tier choices
- Managed Instance storage: General Purpose up to 16 TB (Next-gen General Purpose up to 32 TB). Business Critical: up to 4 TB on standard-series hardware and 5.5 TB on premium-series (16 TB in some regions); up to 16 TB on memory optimized premium-series. Historically, 16 TB on Business Critical required memory optimized premium-series; today premium-series also reaches 16 TB in some regions. Either way it is the most expensive configuration, and you pay for it twice when you add a failover group secondary.
- Hyperscale is an Azure SQL Database tier; Managed Instance has only General Purpose and Business Critical.
Common trap: Managed Instance Business Critical for regional resilience plus 16 TB — General Purpose with a failover group meets both needs more cheaply.
Common trap: Managed Instance “Premium” for load-balanced read replicas — Managed Instance has no Premium tier and only one read replica. Hyperscale, which load-balances ReadOnly connections across its HA replicas, is right.
SQL Server on Azure VMs
- For SQL Server on Azure VMs, an Always On availability group avoids the shared storage that a failover cluster instance (FCI) needs.
- A distributed network name (DNN) listener can replace the VNN listener, needs no Azure Load Balancer and fails over faster.
- An FCI built on a premium file share costs more; a standard file share is unsupported.