Home / Databases / SQL Server

DatabasesHow-toIntermediate

Azure SQL Database to Hyperscale: when, how and what changes

Move a growing Azure SQL Database from General Purpose or Business Critical to Hyperscale for up to 128 TB, fast backups and restores, and read scale-out. Covers fit checks, the online conversion, reverse migration window, replicas, and cost.

Deepak Bhardwaj2 min read

Applies toAzure SQL Database (vCore and DTU tiers) to the Hyperscale service tier

1. Why Hyperscale

Problem on GP/BC Hyperscale behaviour
Database near the 4 TB limit Up to 128 TB
Long backup/restore of large databases Snapshot-based backups; restores largely independent of size
Log write throughput limits Higher log throughput (check the current limit per size)
Read load hurting the primary Up to 4 HA replicas (readable) plus named replicas for isolated read workloads
Scale-up takes long on big DBs Compute scaling largely independent of data size

Hyperscale also has serverless compute for variable workloads.

2. Fit checks

  • Pricing: Hyperscale compute is priced without a separate storage-IO model; storage per GB. Model it — for many workloads it's now cost-competitive with GP.
  • Features: most Azure SQL DB features are supported; check the current list (for example some geo-replication and LTR specifics).
  • Latency: page servers add a remote IO path for cold data; hot data is served from the compute's local RBPEX cache. Test IO-heavy queries.

3. Convert (online)

az sql db update -g rg-sql -s sqlsrv-prod -n Sales --edition Hyperscale --service-objective HS_Gen5_8
  • The conversion copies data in the background while the database stays online; a short cutover (seconds to minutes) happens at the end. You can choose a manual cutover to control when that happens.
  • Large databases take hours; plan for it and watch progress with sys.dm_operation_status in master.

4. Reverse migration

You can move back from Hyperscale to General Purpose within 45 days of the migration (this window applies only if the database was converted from another tier). After that, the way back is export/import.

5. Read scale-out

Server=tcp:sqlsrv-prod.database.windows.net;Database=Sales;ApplicationIntent=ReadOnly;Authentication=Active Directory Default;
  • ApplicationIntent=ReadOnly routes to an HA replica.
  • Named replicas have their own endpoint and size — good for reporting teams that need different compute.
az sql db replica create -g rg-sql -s sqlsrv-prod -n Sales --secondary-type Named \
  --partner-database Sales_reporting --service-objective HS_Gen5_4

6. After the move

  • Re-baseline performance; watch for IO waits on cold data (PAGEIOLATCH with remote reads).
  • Backups: PITR settings carry over; confirm long-term retention policy.
  • DR: geo-replication / failover groups for Hyperscale are supported; reconfigure if you had them.

Tip

If the only reason for Hyperscale is a few large, rarely used tables, check whether archiving old data (to Blob Storage/Parquet) solves the size problem at a lower cost first.

Related fixes