Is Azure SQL Database Hyperscale really distributed SQL?
Azure SQL Database Hyperscale splits a single-writer SQL engine across separate compute, log, page server and storage tiers, so it is distributed in architecture but not in write capacity. The author explains where that line falls against the usual meaning of distributed SQL, and cites a commissioned benchmark against Aurora PostgreSQL. Useful when you choose a database for a growing workload.
Key points
- Hyperscale accepts writes on one primary; if you need multi-writer distributed commits, it is a different trade-off.
- Storage grows automatically up to 128 TB, and backups are near-instant snapshots that do not use compute.
- Up to four high-availability replicas and 30 named replicas let reporting and analytics run apart from the primary.
- Log throughput reaches 150 MB/s and compute reaches 192 vCores on Premium-series hardware.
- The Aurora comparison was commissioned by Microsoft, so validate performance against your own workload.
- Serverless auto-pause and resume is in preview, which matters for dev/test databases.
Anna Hoffman of Microsoft's Azure SQL team asks whether Azure SQL Database Hyperscale counts as distributed SQL. Her answer is that Hyperscale distributes its architecture across compute replicas, a log service, page servers and Azure Storage, but keeps a single primary that accepts writes. That choice avoids a distributed commit protocol and conflict resolution in the write path, while keeping the SQL Server engine semantics and T-SQL surface that applications already use.
The post lists the scale limits behind the argument: storage up to 128 TB, up to 30 named replicas beside four high-availability replicas, a log rate of up to 150 MB/s, and up to 192 vCores on Premium-series hardware. A Principled Technologies study, commissioned by Microsoft, compared it with Aurora PostgreSQL I/O-Optimized and reported gains of up to 52% at 16 vCores. The author recommends testing against your own workload rather than relying on that benchmark.
Real-world use
- A growing SaaS OLTP database that may pass 10 TB while keeping a single writer and existing T-SQL code.
- An analytics team that moves reporting and AI queries onto named replicas, away from the primary.
- A team migrating an existing SQL Server application to the cloud without rewriting its T-SQL.
Why it matters
When you choose a database, judge write capacity, storage, read scale and operations separately rather than relying on the distributed label. Because Hyperscale routes all writes through one primary, multi-region write needs point to a different architecture.