AWS Database Blog

Marc Brooker

Metadata

<p>Amazon Aurora DSQL is a distributed, PostgreSQL-compatible OLTP database built for multi-region workloads. AWS recently published a full architecture paper on Arxiv, and one former team member has written a detailed breakdown of the design decisions behind it. Here’s what the system actually does, why it was built this way, and what you need to know to use it well.</p>
<h2>How the architecture works</h2>
<p>The core idea is “exploding the monolith” — splitting a traditional database into independent, horizontally scalable services:</p>
<ul>
<li><strong>Query Processors</strong> handle SQL parsing and execution</li>
<li><strong>Storage Nodes</strong> store data close to local SSDs and handle scan pushdown</li>
<li><strong>Adjudicators</strong> manage conflict detection</li>
<li><strong>Journals</strong> handle replication (reusing existing AWS infrastructure)</li>
<li><strong>Crossbars</strong> route data between components</li>
</ul>
<p>Each layer scales independently. You can add compute without touching storage, or scale the commit layer without affecting query processing. That separation is the whole point.</p>
<h2>The key architectural bets</h2>
<p><strong>Synchronized physical clocks.</strong> DSQL relies on AWS TimeSync for coordination-free reads. Because clocks are tightly synchronized across the fleet, reads can proceed without any cross-node coordination — 0 round trips. This is a meaningful departure from systems that use logical clocks or hybrid approaches.</p>
<p><strong>Optimistic Concurrency Control with Snapshot Isolation.</strong> Rather than acquiring pessimistic locks, transactions proceed optimistically and conflicts are detected at commit time. The payoff is no lock contention and no metastable failure modes where one slow transaction blocks others. The tradeoff is that write-write conflicts on hot keys cause transaction aborts, which your application has to handle.</p>
<p><strong>Strong linearizable consistency.</strong> The paper argues that advances in time distribution, datacenter networking, and distributed protocols have made strong consistency the right default for cloud-scale systems — overturning the earlier assumption that eventual consistency was necessary for availability and latency. DSQL commits in 1 RTT for single-region and uses a Warp-inspired single-leader 2PC optimization to keep multi-region commits as fast as possible.</p>
<p><strong>Hard transaction size caps.</strong> Transactions are capped at 3,000 rows and 10MiB. This is a real constraint, not a soft guideline.</p>
<h2>Tradeoffs worth knowing</h2>
<p>OCC is great until you have hot keys. If multiple transactions frequently update the same rows, conflict rates go up and you’ll see more aborts. Schema design matters a lot here.</p>
<p>In multi-region scenarios, WAN latency hits before conflict detection — meaning you can do a lot of work across regions only to find out at commit time that there was a conflict. This isn’t unique to DSQL, but it’s worth designing around.</p>
<p>Foreign key constraints and high-locality sequences (like auto-increment IDs) create friction. Sequences serialize commits; foreign keys require cross-node coordination. Both work against the distributed model.</p>
<h2>Building applications on DSQL</h2>
<h3>Retry logic is not optional</h3>
<p>Because OCC detects conflicts at commit time rather than preventing them upfront, your application will see transaction aborts. You need retry logic. Classify errors before retrying:</p>
<ul>
<li><strong>Retryable:</strong> serialization failures, transient network issues</li>
<li><strong>Non-retryable:</strong> constraint violations, syntax errors, exceeded size caps</li>
</ul>
<p>Retry with exponential backoff and jitter. Don’t retry blindly.</p>
<h3>Primary key strategy</h3>
<p>Auto-increment identity columns are a problem. They create a sequential hotspot that serializes inserts across the distributed system. Use UUIDs (<code>gen_random_uuid()</code>) instead, or a hybrid pattern where you generate a UUID but expose a human-readable sequence number separately for display purposes.</p>
<p>The UUID approach distributes inserts across storage nodes evenly. It’s less ergonomic but it’s the right call for write-heavy tables.</p>
<h3>Schema design to reduce contention</h3>
<p>Hot rows kill OCC performance. A few patterns help:</p>
<ul>
<li>Avoid a single “counter” row that many transactions update. Use sharded counters or approximate counts instead.</li>
<li>Keep transactions short. The longer a transaction runs, the higher the chance something else conflicts with it.</li>
<li>Don’t hold transactions open across user interactions or network calls.</li>
</ul>
<h3>Idempotency</h3>
<p>Because you’ll be retrying transactions, operations need to be idempotent. Use idempotency keys — a unique identifier per logical operation that lets you detect and skip duplicate retries safely.</p>
<h3>Schema migrations</h3>
<p>Use the expand-contract pattern:</p>
<ol>
<li><strong>Expand:</strong> add new columns or tables without removing old ones</li>
<li><strong>Migrate:</strong> backfill data, update application code to write to both old and new</li>
<li><strong>Contract:</strong> remove old columns once all reads and writes use the new schema</li>
</ol>
<p>This avoids locking issues and lets you migrate without downtime.</p>
<h3>Observability</h3>
<p>Track conflict rates per table, transaction retry counts, and commit latency. A rising conflict rate on a specific table is a signal that you have a hot-row problem, not a capacity problem — and the fix is schema or application changes, not more hardware.</p>
<h2>What made it buildable</h2>
<p>One thing the former team member notes: building a novel global database was more tractable than it sounds because DSQL reused existing AWS infrastructure (Journals for replication, the PostgreSQL engine for query processing) and invested heavily in upfront design. The novel parts — Adjudicators, the OCC protocol, the clock-based read path — are real engineering, but they’re layered on top of proven components rather than built from scratch.</p>
<p>The result is a system with genuine architectural coherence: the consistency model, the clock assumptions, the OCC design, and the scalability story all fit together. Whether the tradeoffs work for your workload depends on your write patterns, your tolerance for retry complexity, and whether your transactions fit within the size caps.</p>


Collections

AWS published a research paper on Aurora DSQL, their multi-region OLTP database. The architecture disaggregates compute, storage, and coordination into independently scalable components: Query Processors, Storage Nodes, Adjudicators, Journals, and Crossbars. Key design choices include relying on AWS TimeSync for synchronized physical clocks enabling 0-RTT consistent reads, Optimistic Concurrency Control with Snapshot Isolation to avoid lock contention, strong linearizable consistency as the default, a single-leader two-phase commit protocol for low-latency commits, and scan pushdown to storage nodes. Tradeoffs include hard transaction size limits (3,000 rows, 10MiB), retry overhead from write-write conflicts on hot keys, WAN latency before conflict detection in multi-region deployments, and friction with foreign keys and high-locality sequences.

Aurora DSQL architecture: how AWS built a multi-region OLTP database