Azure SQL Database scale and continuity — Hyperscale, elastic pools, failover groups and geo-replication
Choosing how an Azure SQL database scales and survives a region outage — Hyperscale (up to 128 TB, 0–4 HA replicas, up to 30 named replicas, snapshot backups, 45-day reverse migration, what it doesn't support), elastic pools (when they save money, billing, sizing, same-server rule), and failover groups on top of active geo-replication (listeners, customer- vs Microsoft-managed failover, grace period, forced failover data loss, read-only intent, security on the secondary).
markdownreferencev1V97G-S7A3stage: designtrust: officialservice: sqlinterface: cliinterface: iacAzure SQL HyperscaleHyperscale 128 TBnamed replicas 30high-availability replicas 0 to 4Hyperscale reverse migration 45 daysHyperscale DBCC CHECKDB not supportedHyperscale In-Memory OLTP not supportedHyperscale serverless Gen5elastic pooleDTUelastic pool sizingelastic pool billingaz sql elastic-pool createfailover group<fog-name>.database.windows.net<fog-name>.secondary.database.windows.netApplicationIntent=ReadOnlycustomer managed failover manualMicrosoft managed failover automaticGracePeriodWithDataLossHoursforced failover data lossactive geo-replicationaz sql failover-group createaz sql db replica createbackup storage redundancy LRS ZRS GRS
Azure SQL Database: scale and continuity
Hyperscale
- Storage grows automatically from 10 GB to 128 TB (100 TB per Hyperscale elastic pool). Backups are file snapshots, so backup and restore are near-instant; retention 1–35 days (7 by default) on LRS, ZRS or GRS, long-term up to 10 years.
- Replicas: 0–4 high-availability secondaries; up to 30 named replicas for read scale-out (each with its own compute and name); geo-replicas in other regions.
- One-way door, mostly: a database migrated to Hyperscale can go back to General Purpose within 45 days; you can't restore a Hyperscale backup as another tier or the reverse.
- Not supported:
DBCC CHECKDB/CHECKFILEGROUP(useDBCC CHECKTABLE … WITH TABLOCK), In-Memory OLTP tables, shrink with TDE off, use as an elastic jobs database or Data Sync hub. Serverless works on standard-series (Gen5) hardware only.
Elastic pools
- Fit many databases with low average use and occasional, non-overlapping peaks; don't pool databases that stay busy.
- Size: compute =
MAX(databases × average use, concurrently peaking databases × peak use)in eDTUs or vCores, then compare storage needs and the price of single databases. eDTUs cost 1.5× DTUs; vCores cost the same pooled or single. - Billed hourly at the pool's size whatever the use; no per-database charge. All databases must be on the pool's server. Moving a database in or out drops connections for seconds.
az sql elastic-pool create -g <rg> -s <server> -n <pool> --edition GeneralPurpose --family Gen5 --capacity 4, thenaz sql db create … --elastic-pool <pool>.
Failover groups and geo-replication
A failover group is a named set of databases on one server that fails over together to a secondary server in another region, built on active geo-replication (which you can also use per database: az sql db replica create).
| Item | Behaviour |
|---|---|
| Read-write listener | <fog-name>.database.windows.net, a CNAME that follows the primary |
| Read-only listener | <fog-name>.secondary.database.windows.net; use ApplicationIntent=ReadOnly. Read-only failover is off by default, so read-only sessions wait while the secondary is down |
| Policy | Customer-managed (manual, recommended): you decide. Microsoft-managed (automatic): Microsoft fails over all affected groups in a wide outage, after the grace period (GracePeriodWithDataLossHours, at least 1 hour) |
| Planned failover | Synchronises first, no data loss, needs the primary reachable |
| Forced failover | Switches at once, may lose recent writes |
| Secondaries | Up to four per group is preview; chaining isn't supported |
Apps connect to the listener, never to the server names, so DNS does the switch. Make the secondary usable before you need it: Entra admin, identity permissions, firewall or private endpoints, and (for SQL logins) matching logins. Contained Entra users travel with the database.
az sql failover-group create -g <rg> -s <primary> -n <fog-name> --partner-server <secondary> --add-db appdb --failover-policy Manual.