# Decomposing Aurora DSQL

DevFeed: [Decomposing Aurora DSQL](<https://devfeed.tech/articles/decomposing-aurora-dsql-12571.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2025/04/17/decomposing.html>)

Author: Marc Brooker

Published: 2025-04-17T00: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>), [Transactions](<https://devfeed.tech/topics/transactions.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [Firecracker](<https://devfeed.tech/topics/firecracker.md>), [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [Replication](<https://devfeed.tech/topics/replication.md>), [Availability](<https://devfeed.tech/topics/availability.md>), [systems](<https://devfeed.tech/topics/systems.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [availability](<https://devfeed.tech/tags/availability.md>), [blog-post](<https://devfeed.tech/tags/blog-post.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [dsql](<https://devfeed.tech/tags/dsql.md>), [firecracker](<https://devfeed.tech/tags/firecracker.md>), [postgresql](<https://devfeed.tech/tags/postgresql.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 explains Aurora DSQL by decomposing transaction processing into execution, ordering, validation, and persistence. It describes PostgreSQL-powered query processors isolated with Firecracker, parallel ordering and validation by adjudicators, and durable replication across availability zones or regions before changes are applied for read visibility.

## Source excerpt

Decomposing Aurora DSQL Riffing, I guess. Earlier today, Alex Miller wrote an excellent blog post titled Decomposing Transaction Systems. It's one of the best things I've read about transactions this year, maybe the best. You should read it now. In the post, Alex breaks transactions down like this: Every transactional system does four things: It executes transactions. It orders transactions. It validates transactions. It persists transactions. then describes how these steps map to traditional OCC and PCC systems, research designs like Calvin, and real-world systems like FoundationDB. How do these steps map to Aurora DSQL? An overview of DSQL's architecture may be useful if you haven't been following along so far: Now, an hour of video and 20 minutes of reading another post later, we're back. Let's dive in. Executing a transaction means evaluating the body of the transaction to produce the intended reads and writes. Aurora DSQL executes transactions on a horizontally scalable fleet of Firecracker-isolated, PostgreSQL-powered, query processors. At this stage there's no coordination at all. MVCC is used for reads during execution, and no writes escape the query processor running that particular transaction. See this post for more on this step. Ordering a transaction means assigning the transaction some notion of a time at which it occurred. Validating a transaction means enforcing concurrency control, or more rarely, domain-specific semantics. In DSQL, ordering and validating happen in parallel, done by the adjudicators involved in the transaction. Each adjudicator provides a range of possible orderings (not after, not before), and one final adjudicator makes the final ordering decision. Similarly, each involved adjudicator weighs in on validation, with one final adjudicator checking that everybody says yes. Strictly, the final-final order is chosen only after validation completes, but the ordering and validation protocols run in parallel. See this post for more. Persi