Everything is local until COMMIT.Read the paper ↗

How Aurora DSQL transactions work.

Choose a scenario below, and then step through how the transactions flow and conflicts are detected.

Aurora DSQL transaction flow Two regions use local query processors and storage. Each sharded adjudicator has its own durable, ordered Journal; the crossbar merges those Journal streams and distributes committed post-images. Region A Commit coordination Region B Application A Application B Query ProcessorFirecracker MicroVM Query ProcessorFirecracker MicroVM Precisiontime Adjudicatorkeys a–m Adjudicatorkeys n–z Journal Aordered stream · keys a–m Journal Bordered stream · keys n–z Crossbarmerge ordered streams MVCC storagenearest replicadogs/5 · treats=7 MVCC storagenearest replicadogs/5 · treats=7 tentative: 8 tentative: 8 Wₐ = {dogs/5} Wᵦ = {dogs/5} YES votes + promises dogs/5 → 8 Wᵦ ∩ Wconflict ≠ ∅ wait until caught up COORDINATION BEGINS
Step 1

Two regions, no writer

Choose Play or step forward to race two transactions.

Before JournalTentative
In JournalAtomic + durable
After JournalOrdered distribution
Locks held
0
Remote coordination
None
Visible value
7
Outcome
Pending
Snapshot and conflict windowstime →
A
B
Space: play/pause · arrows: step 1 / 10

Conceptual animation based on the transaction protocol in Aurora DSQL: Scalable, Multi-Region OLTP. Timing and topology are illustrative.