Is Azure SQL Database Hyperscale “distributed SQL”?

In my last post, I broke down the Socrates paper, the research that became Azure SQL Database Hyperscale. Writing it made me want to tackle a question I think trips a lot of people up when they’re choosing a database: is Azure SQL Database Hyperscale “distributed SQL”? 

It’s a fair question. “Distributed SQL” has become shorthand for “the relational database that scales in the cloud,” and anything outside that bucket tends to get filed under “the relational one my company already has.” I’d rather not leave that to assumption, so here’s how I think about it. 

What people usually mean by “distributed” 

When architects say they want distributed SQL, they’re usually asking for a bundle of things: 

• Real transactions, not “eventually.” 

• Consistency you can reason about, even when something fails. 

• Full SQL, not a subset of it. 

• Enterprise-grade operations: high availability, backup and restore, security, compliance. 

• Scale that doesn’t force a rearchitecture at 10 TB. 

• For some workloads, more than one node accepting writes. 

That last one is where definitions start to split, so I’ll come back to it. 

What Hyperscale distributes 

Hyperscale takes the four jobs a single SQL Server machine used to do and gives each one its own tier (my Socrates post goes deep on this). Compute replicas run the query processor. A log service owns durability and fans the log out. Page servers each own a slice of the data. Azure Storage holds the long-term copy and takes backups as snapshots. 

The result is that the things that used to scale with data size don’t anymore: 

• Storage grows automatically, up to 128 TB. 

• Backups are near-instant snapshots that don’t touch your compute, and restore time is largely independent of database size. 

• Adding a replica doesn’t copy data (and it never reads a stale page). You get up to four high-availability replicas, plus up to 30 named replicas, each with its own compute size, for isolating reporting, analytics, or AI workloads. 

• The log runs at up to 150 MB/s, and compute goes up to 192 vCores on Premium-series hardware. 

What Hyperscale keeps in one place (on purpose) 

Hyperscale has one primary that accepts writes. That’s a design choice, not an oversight. 

A single writer means there’s no distributed commit protocol in your write path, no conflict resolution to design your app around, and no surprises when two regions try to update the same row. You get the SQL Server engine’s transaction semantics and the T-SQL surface your app already uses: temporal tables, JSON, graph, vectors, columnstore, stored procedures, etc. Your existing application and tools keep working without a rewrite. 

My answer, then: Hyperscale is a distributed architecture with a single-writer SQL engine on top. That distinction matters more than the label. If your definition of distributed SQL requires multiple writers, Hyperscale is a different trade-off. If your priorities are transactions, consistency, SQL compatibility, enterprise operations, and storage and read scale, evaluate Hyperscale against those requirements, and evaluate write capacity separately. 

OK, but how does it perform? 

Architecture diagrams are nice. Numbers are nicer. 

AWS took a similar architectural path with Aurora, separating compute from a distributed storage layer, which makes it the natural head-to-head. Principled Technologies recently ran exactly that comparison (commissioned by Microsoft, and I want to be upfront about that). They tested Hyperscale Premium-series against Amazon Aurora PostgreSQL I/O-Optimized using the HammerDB TPROC-C workload on a 2.3 TB database. 

At 16 vCores, Hyperscale delivered up to 52% higher performance and up to 51% better performance per dollar than Aurora, and it came out ahead at every concurrency level they tested. Your workload is not a benchmark, so test it yourself! The full methodology is public, and it’s worth a read. 

One price and you can start here, stay here 

Performance is only half the story. Hyperscale is one all-inclusive price: there’s no separate software to buy and no separate charge for I/O. It also starts at 10 GB, so this isn’t just a “big database” tier. As Bob Ward says, you can “start here, stay here.” And with serverless auto-pause and resume now in preview, a dev/test database’s compute can scale to zero when nobody’s using it. 

Learn more

• Read the benchmark report: https://aka.ms/hyperscalebenchmark  

• Go deeper on the architecture: The paper that split the database in four 

• Watch the Azure SQL Database Foundations series that highlights Hyperscale: https://aka.ms/azuresqlfoundationseries  

–Anna