# Aurora DSQL: Scalable, Multi-Region OLTP

DevFeed: [Aurora DSQL: Scalable, Multi-Region OLTP](<https://devfeed.tech/articles/aurora-dsql-scalable-multi-region-oltp-12599.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2026/07/19/dsql-paper.html>)

Author: Marc Brooker

Published: 2026-07-19T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [DSQL](<https://devfeed.tech/topics/dsql.md>), [Databases](<https://devfeed.tech/topics/databases.md>), [distributed-systems](<https://devfeed.tech/topics/distributed-systems.md>), [Replication](<https://devfeed.tech/topics/replication.md>), [Transactions](<https://devfeed.tech/topics/transactions.md>), [Amazon Web Services](<https://devfeed.tech/topics/aws.md>)

Tags: [aws](<https://devfeed.tech/tags/aws.md>), [database](<https://devfeed.tech/tags/database.md>), [dsql](<https://devfeed.tech/tags/dsql.md>), [replication](<https://devfeed.tech/tags/replication.md>), [systems](<https://devfeed.tech/tags/systems.md>), [transactions](<https://devfeed.tech/tags/transactions.md>)

## AI overview

The article introduces the Aurora DSQL paper, which explains the design of a scalable, multi-region OLTP relational database. It highlights DSQL's disaggregated architecture, transaction processing, replication, strongly consistent reads, operational simplicity, and potential benefits for resilient cloud applications and agentic builders.

## Source excerpt

Aurora DSQL: Scalable, Multi-Region OLTP A paper! Our new paper, Aurora DSQL: Scalable, Multi-Region OLTP, is now available on Arxiv. I'm excited about this one: it's a fully end-to-end look at how Aurora DSQL works, from query processing, to transactions, to replication, to the control plane. We've shared most of this content before in other forms, on this blog, on Marc Bowes' Blog, Werner's Blog, in talks, and on the AWS blog. But this version covers all the ground, all in one place. You should read it. Or check out the interactive transaction simulator to get a feel for how it works. Some highlights Our overall goal was to build a relational database system that simplifies the work of application building and operations, freeing builders from worrying about scale, reliability, durability, and even multi-region fault tolerance. A database of first resort, which is simple and easy to adopt at low scale, and grows with the application, without adding complexity. I've written about this argument before (in DSQL: Simplifying Architectures), and it remains the thing that excites me most about the Aurora DSQL product. I believe we've made it much easier (and, in many cases, cheaper) to build and operate resilient, highly available, cloud applications at all scales. That applies to systems built by humans and agents, with the benefits magnified for agentic builders. Agents are great at building, but not (yet?) so great at long-horizon tasks like database operations. A database designed to simplify operations really helps. DSQL's architecture is disaggregated. Multiple independent services, each focused on a small number of well-defined concerns. DSQL isn't the first disaggregated OLTP database. Many, including Aurora and DynamoDB, came before. What's interesting here is how we learned from those systems, and the lessons that came from operating them at scale: avoiding large caches (they make failovers and read scale tricky), offering strongly consistent scalable reads (a