--- cuppy_hub: azure cuppy_path: reference/sql/scale-and-continuity.md cuppy_section: docs cuppy_doc: V97G-S7A3 cuppy_doc_uuid: b1dc6994-7812-4590-b1fd-4e39f32f5472 cuppy_permalink: https://cuppy.io/azure/d/V97G-S7A3 cuppy_version: 1 cuppy_updated: 2026-10-23T16:16:52.575Z cuppy_canonical: https://cuppy.io/azure/docs/reference/sql/scale-and-continuity cuppy_mcp: https://cuppy.io/mcp cuppy_body_sha256: 6a414bab81733c3a91e719ae940ec852dfd37aef96846b5db2dc7f98774c9d66 # cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks. --- # 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` (use `DBCC 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 -s -n --edition GeneralPurpose --family Gen5 --capacity 4`, then `az sql db create … --elastic-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 | `.database.windows.net`, a CNAME that follows the primary | | Read-only listener | `.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 -s -n --partner-server --add-db appdb --failover-policy Manual`. --- You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 107 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/azure/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.