On July 31, 2026, AWS announced that Amazon Aurora DSQL now supports multi-Region clusters in Europe (Stockholm), Europe (Spain), Asia Pacific (Mumbai), and Asia Pacific (Singapore) — bringing the total to 16 Regions with multi-Region cluster support. For teams operating financial systems with zero-RPO and seconds-level RTO requirements, this is not a footnote on availability: it is a primitive change. This retro examines what happens when teams adopt distributed strong consistency without revising their resilience contracts, and how to rebuild those contracts correctly.
What Happened: The Illusion of Strong Consistency Without Cost
When Aurora DSQL launched, the promise was straightforward: a serverless SQL database with strong consistency across multiple regions, without managing read replicas, without manual failover, without the classical CAP theorem trade-offs that forced teams to choose between availability and consistency. The narrative was seductive, especially for teams coming from Aurora Global Database architectures, where regional failover took between 1 and 2 minutes and replica promotion was a semi-manual process with real data-loss risk during high-write windows.
The problem was not with the technology itself. Aurora DSQL delivers what it promises: each multi-Region cluster exposes a writable endpoint in both peered Regions, presenting a single logical database that remains available even if one Region becomes unavailable. The underlying consensus protocol — based on Paxos variants optimized for geographic latency — ensures that a transaction committed in Mumbai is immediately visible in Singapore, with no asynchronous replication window.
