Aurora DSQL: Scalable, Multi-Region OLTP

Source: arXiv — 2026-07-14

Summary

AWS engineers (Marc Brooker, Marc Bowes, Mike Hershey, Zak van der Merwe, James Morle, and Matthys Strydom) describe the system design behind Aurora DSQL, a serverless SQL database built for active-active, multi-region OLTP at cloud scale. The paper's central move is disaggregation: compute (PostgreSQL-compatible query processors running statelessly in Firecracker microVMs), storage, and transaction coordination are split into independently, horizontally scalable services. Concurrency control combines multiversion concurrency control (MVCC) with precision timestamps for coordination-free reads, and optimistic concurrency control (OCC) for writes, pushing all coordination to commit time via distributed adjudicators and a Journal replication layer. The result is a database that elastically scales from zero to millions of transactions per second while keeping ACID guarantees and staying available through AZ or region failures.

Key Takeaways

• Disaggregated architecture: stateless PostgreSQL-compatible query processors (Firecracker microVMs) are decoupled from storage and from transaction coordination, so each layer scales independently.
• Reads are coordination-free: MVCC with precision timestamps lets any replica serve consistent snapshot reads without talking to a coordinator.
• Writes use OCC, deferring all coordination to commit time — transactions execute optimistically and are only checked for conflicts when they try to commit.
• Commit-time coordination runs through distributed adjudicators and a Journal replication system, minimizing the latency cost of cross-region coordination since it happens once per transaction, not per statement.
• The design targets true active-active multi-region operation: every region can accept reads and writes, with continuous availability during AZ or regional failures.
• Elastic scaling claim spans from zero to millions of TPS, positioning DSQL as a serverless alternative to manually sharded or single-leader distributed SQL systems.

Reel Script

Hook Multi-region databases usually force a trade-off: either every write waits on a round trip to a leader region, or you give up strong consistency. AWS just published how Aurora DSQL claims to dodge that trade-off entirely — and the trick is deciding what needs coordination and what doesn't.

Core Concept Aurora DSQL splits the database into three independently scalable pieces: stateless query processors (running PostgreSQL compatibility in Firecracker microVMs), storage, and transaction coordination. That disaggregation is what lets each layer scale on its own instead of dragging the whole system along.

The concurrency model is the real trick. Reads use MVCC with "precision timestamps" — think of it as every read getting a consistent snapshot of the database at an exact point in time, without needing to ask a coordinator "is this safe?" first. That makes reads coordination-free, so they're fast no matter which region you're in.

Writes work differently: optimistic concurrency control. Instead of locking rows up front, a transaction runs assuming there's no conflict, and only at commit time does the system check whether it actually collided with another transaction. That check happens through distributed "adjudicators" and a replicated Journal. The key insight: coordination is deferred to once per transaction (at commit), not once per statement — which is what keeps cross-region latency from stacking up.

Hands-On Picture a transaction touching rows in a table replicated across three regions. Under a traditional single-leader design, every statement in that transaction has to round-trip to the leader region before it can proceed — three regions means real added latency per statement, and a regional outage can stall writes entirely.

Aurora DSQL's approach: the query processor executes the whole transaction locally and optimistically, using its MVCC snapshot to read data as of a precision timestamp with zero coordination. Only when the client asks to commit does the transaction get handed to the adjudicator layer, which checks — using the Journal's replicated, ordered log — whether any conflicting transaction committed first. If not, the write is journaled and durably committed across regions. If there's a conflict, the transaction aborts and can retry. So the "cost" of multi-region consistency is paid exactly once, at commit, rather than being smeared across every read and write in the transaction. That's what lets DSQL claim elastic scaling from zero to millions of transactions per second while surviving AZ or region failures without downtime.

Takeaway This is a legitimate architectural answer to the "coordination tax" that has historically made multi-region SQL either slow or eventually-consistent — DSQL bets that most of the cost can be pushed to commit time and away from reads entirely. Worth studying if you're evaluating distributed SQL for a global product, or just want to understand where systems like Spanner and CockroachDB are being pushed next. Read the full paper on arXiv if you're designing anything that needs strong consistency across regions.

Discussion

(No questions yet — ask follow-ups via a Claude Code chat session on this repo; answers get appended here.)