Inside Azure SQL Hyperscale: how the Socrates paper split the database

A walkthrough of the 2019 Socrates paper behind Azure SQL Database Hyperscale. The design splits compute, transaction log, page servers and storage into separate tiers, which is why backups, restores and adding replicas no longer scale with database size. Developers running or evaluating Hyperscale get a clear view of the architecture behind it.

Key points

• Socrates is the codename of Azure SQL Database Hyperscale, described in a 2019 SIGMOD paper.
• Compute nodes do not keep a full copy; the RBPEX local SSD cache extends the buffer pool.
• The XLOG service owns the transaction log and distributes log blocks to page servers and replicas.
• GetPage@LSN requests a page as of a specific log position, so replicas never read a stale page.
• The paper reports maximum size rising from 4 TB to 100 TB and scale operations moving from O(data) to O(1).
• The author says Hyperscale now reaches 150 MB/s log throughput and grows storage automatically up to 128 TB.

The Azure SQL team has begun a blog series revisiting research papers, starting with the 2019 SIGMOD paper on Socrates, the codename for Azure SQL Database Hyperscale. In the traditional Business Critical design, every replica holds a full data copy, so storage, backups and new replicas grow with database size. Socrates splits the work across compute nodes, a log service, page servers and Azure Storage.

Compute nodes keep only hot pages in memory and on local SSD, fetching the rest from page servers with GetPage@LSN so replicas never read stale pages. The paper reports maximum size rising from 4 TB to 100 TB and constant-time scale operations. For Hyperscale users, this explains snapshot backups and fast read replicas, though the 2019 figures are not current limits.

Real-world use

• Teams with multi-terabyte OLTP databases that need restore and backup times to stay manageable.
• Spinning up a named read replica to move reporting or analytics queries away from transactional traffic.
• A SaaS product that starts small and may grow large, choosing Hyperscale to avoid a later migration.

Why it matters

Understanding why backups, restores and replica creation do not scale with data size helps you judge Hyperscale for large databases. Your T-SQL code and tooling stay the same while the storage architecture underneath changes.

Related stories

• Collection Return Types in C#: Interfaces, Views, and SnapshotsDLNick Cosentino (Dev Leader)2 d ago
• Idempotent NebulaGraph bulk ingestion from .NET using deterministic VIDsDVDEV Community: #csharp3 d ago
• Events and Delegates in C#: Contracts, Subscriptions and NotificationDLNick Cosentino (Dev Leader)3 d ago