# DSQL Published articles for DSQL. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Building async Python applications with Tortoise ORM and Amazon Aurora DSQL DevFeed: [Building async Python applications with Tortoise ORM and Amazon Aurora DSQL]() Original publisher: [Read original article]() Author: Lasita Bhattacharya Published: 2026-09-09T15:27:43Z Content type: tutorial Language: en Sources: [AWS Database Blog]() Topics: [DSQL](), [Concurrency](), [AWS IAM](), [Database](), [CRUD]() Tags: [advanced-300](), [amazon-aurora](), [concurrency](), [database](), [dsql](), [how-to](), [iam](), [orm](), [postgresql](), [python](), [rideshare](), [serverless](), [technical-how-to]() ### AI overview A tutorial for building a high-concurrency asynchronous Python rideshare application with Tortoise ORM and Amazon Aurora DSQL. It covers UUID-based models, IAM-authenticated asyncpg connections, OCC retry handling, and asynchronous CRUD operations. ### Source excerpt Build a high-concurrency async Python rideshare application with Tortoise ORM and Amazon Aurora DSQL. This post walks through the key adaptations: UUID primary keys, IAM-authenticated asyncpg connections with a connection-pool patch, individual DDL execution, and optimistic concurrency control (OCC) retry logic. ## Amazon Aurora DSQL observability concepts and usage with Amazon CloudWatch DevFeed: [Amazon Aurora DSQL observability concepts and usage with Amazon CloudWatch]() Original publisher: [Read original article]() Author: James Morle Published: 2026-08-17T23:37:48Z Content type: article Language: en Sources: [AWS Database Blog]() Topics: [DSQL](), [telemetry]() Tags: [amazon](), [amazon-aurora](), [amazon-cloudwatch](), [cost](), [dash](), [database](), [diagnostics](), [dsql](), [insights](), [intermediate-200](), [metrics](), [monitoring](), [mysql](), [observability](), [performance](), [postgresql](), [sql](), [technical-how-to]() ### AI overview This article explains Amazon Aurora DSQL's time-based observability model and its link to performance and DPU-based cost. It introduces DASH session sampling and using Amazon CloudWatch Database Insights, PromQL, and system diagnostics to identify bottlenecks. ### Source excerpt Amazon Aurora DSQL offers time-based observability through Amazon CloudWatch Database Insights. Learn how the DSQL observability model, DASH, Database Insights, PromQL, and the system diagnostics AI skill help you find performance bottlenecks and connect session time directly to cost. ## On building scalable control planes DevFeed: [On building scalable control planes]() Original publisher: [Read original article]() Author: werner@allthingsdistributed.com (Dr. Werner Vogels) Published: 2026-08-04T14:00:00Z Content type: article Language: en Sources: [All Things Distributed]() Topics: [distributed-systems](), [Amazon Web Services](), [Amazon EC2](), [DSQL](), [Cloud]() Tags: [aws](), [cloud](), [distributed-systems](), [dsql](), [infrastructure](), [kubernetes](), [posts](), [servers](), [ssh]() ### AI overview This article explores the engineering of scalable control planes through Zak van der Merwe's experience building them at AWS, first for EC2 and later for DSQL. It explains how control planes record intended state and reconcile it with actual state, bringing together difficult distributed-systems problems and influencing whether services can survive growth. ### Source excerpt Zak van der Merwe has spent his entire career at AWS building control planes. First for EC2 and now for DSQL. On the surface, the control plane looks quite boring: it records what should exist and reconciles that with what actually does. Nobody leaves school dreaming of building one, but Zak will be the first to tell you that if you like solving hard problems in distributed systems, there are few better places to be. It's where many of those hard problems converge, and where the decisions you make determine whether a service survives its own growth. ## Aurora DSQL: Scalable, Multi-Region OLTP DevFeed: [Aurora DSQL: Scalable, Multi-Region OLTP]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2026-07-19T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [DSQL](), [Databases](), [distributed-systems](), [Replication](), [Transactions](), [Amazon Web Services]() Tags: [aws](), [database](), [dsql](), [replication](), [systems](), [transactions]() ### 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 ## Why Strong Consistency? DevFeed: [Why Strong Consistency?]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2025-11-18T00:00:00Z Content type: opinion Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [DSQL](), [Databases](), [Replication](), [MySQL](), [Latency](), [API](), [Amazon EC2](), [Microservice](), [Amazon Web Services]() Tags: [api](), [aws](), [database](), [dsql](), [latency](), [microservices](), [mysql](), [replication]() ### AI overview The article explains how eventual consistency in read-replica architectures can cause applications to observe missing or stale data after a write. It argues that strong consistency simplifies client and service logic by avoiding retries, infinite loops, extra work, and latency, and presents Aurora DSQL as a database designed to make all reads strongly consistent. ### Source excerpt Why Strong Consistency? Eventual consistency makes your life harder. When I started at AWS in 2008, we ran the EC2 control plane on a tree of MySQL databases: a primary to handle writes, a secondary to take over from the primary, a handful of read replicas to scale reads, and some extra replicas for doing latency-insensitive reporting stuff. All of thing was linked together with MySQL's statement-based replication. It worked pretty well day to day, but two major areas of pain have stuck with me ever since: operations were costly, and eventual consistency made things weird. Since then, managed databases like Aurora MySQL have made relational database operations orders of magnitude easier. Which is great. But eventual consistency is still a feature of most database architectures that try scale reads. Today, I want to talk about why eventual consistency is a pain, and why we invested heavily in making all reads strongly consistent in Aurora DSQL. Eventual Consistency is a Pain for Customers Consider the following piece of code, running against an API exposed by a database-backed service: id = create_resource(...) get_resource_state(id, ...) In the world of read replicas, the latter statement can do something a little baffling: reply 'id does not exist'. The reason for this is simple: get_resource_state is a read-only call, likely routed to a read replica, and is racing the write from create_resource. If replication wins, this code works as expected. If the client wins, it has to handle to weird sensation of time moving backwards. Application programmers don't really have a principled way to work around this, so they end up writing code like this: id = create_resource(...) while True: try: get_resource_state(id, ...) return except ResourceDoesNotExist: sleep(100) Which fixes the problem. Kinda. Other times, especially if ResourceDoesNotExist can be thrown if id is deleted, it causes an infinite loop. It also creates more work for client and server, adds latency, and req ## DSQL: Simplifying Architectures DevFeed: [DSQL: Simplifying Architectures]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2025-11-02T00:00:00Z Content type: opinion Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [DSQL](), [Serverless](), [Database](), [PostgreSQL](), [Concurrency]() Tags: [building](), [complexity](), [concurrency](), [cost](), [database](), [dsql](), [efficiency](), [infrastructure](), [memory](), [postgresql](), [scale](), [serverless]() ### AI overview The article presents Aurora DSQL as a way to simplify database-backed application architectures. It highlights serverless operation, automatic scaling of memory, CPU, and storage, managed software updates, usage-based pricing, strong consistency, and snapshot isolation. These features are described as reducing operational debt, infrastructure management, and application complexity. ### Source excerpt DSQL: Simplifying Architectures Complexity is a choice. While we were designing and building Aurora DSQL, we spent a lot of time thinking about our experience building and running database-backed systems. We saw that building great, fast, cost-effective, highly-available, systems was harder than it needed to be. We wanted to make it easier. Today, I want to discuss some of Aurora DSQL's features, and how I think they come together to make your life, as an application, service, or website developer, easier. We wanted for our customers what we wanted for ourselves: a relational database that allows us to build great systems with simple architectures. Serverless: The most obvious one is serverlessness. With DSQL you don't need to pick hardware, manage clusters, design for failover, think about patching engines or systems, monitor CPU and memory, or any of the many other tasks that come with good cluster management. When you get started with any database, you can basically ignore these things: buying excess CPU and memory at small scale is cheap, and monitoring is easy when you aren't also trying to drive efficiency. But this is a kind of operational debt, which will eventually come due. With DSQL, you can avoid this debt entirely: the system scales memory, CPU, and storage to meet your application's needs, and so you don't need to monitor these things. It keeps the database software and system software up-to-date too. Scale-down: I see a lot of database architectures take on a lot of complexity to reduce cost during nights and weekends: scaling down primaries, removing read replicas, and even removing secondaries. These are smart cost management things with many database products, but you simply don't need them with DSQL. DSQL scales up and down with your application, priced on the amount of work your database is doing, not the scale of your infrastructure. Doing no work? You'll spend no money. Strong consistency and just-right isolation: DSQL offers a single isolation ## Dynamo, DynamoDB, and Aurora DSQL DevFeed: [Dynamo, DynamoDB, and Aurora DSQL]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2025-08-15T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [Amazon DynamoDB](), [DSQL](), [Dynamo](), [NoSQL](), [Replication](), [Availability](), [Serverless](), [SQL](), [Amazon Web Services](), [Transactions]() Tags: [amazon-dynamodb](), [availability](), [aws](), [data](), [database](), [databases](), [dsql](), [dynamo](), [replication](), [serverless](), [sql]() ### AI overview This article compares the architectures of Amazon Dynamo, Amazon DynamoDB, and Aurora DSQL, beginning with how they provide durability and availability when a single host fails. It explains Dynamo's replication across successor nodes in a consistent-hashing ring and contrasts it with DynamoDB's replica groups, multi-AZ servers, Paxos replication, quorum acknowledgments, and scaling behavior. ### Source excerpt Dynamo, DynamoDB, and Aurora DSQL Names are hard, ok? People often ask me about the architectural relationship between Amazon Dynamo (as described in the classic 2007 SOSP paper), Amazon DynamoDB (the serverless distributed NoSQL database from AWS), and Aurora DSQL (the serverless distributed SQL database from AWS). There's a ton to say on the topic, but I'll start off on comparing how the systems achieve a few key properties. The key references for this post are: For Dynamo, Dynamo: Amazon's Highly Available Key-value Store from SOSP'07. For DynamoDB, Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service from ATC'22, Distributed Transactions at Scale in Amazon DynamoDB from ATC'23, and Lessons learned from 10 years of DynamoDB from the Amazon Science blog. For DSQL, my blog series on DSQL. Durability The databases we're looking at offer different levels of durability, but all three are designed not to lose data when a single host fails. Dynamo does this by taking advantage of its consistent hashing approach, replicating the data across multiple hosts in order in the hash ring: To achieve high availability and durability, Dynamo replicates its data on multiple hosts. Each data item is replicated at N hosts. ... Each key, k, is assigned to a coordinator node[]. The coordinator is in charge of the replication of the data items that fall within its range. In addition to locally storing each key within its range, the coordinator replicates these keys at the N-1 clockwise successor nodes in the ring. Like Dynamo, DynamoDB assigns a node in a hash ring to each individual item. But that's where the similarities stop. Instead of replicating across multiple nodes in the ring, in DynamoDB each node consists of a replica group with multiple servers in multiple AZs using Paxos to replicate the data. Instead of appearing the ring N times, each item appears once, and takes advantage of fault-tolerant nodes rather than spreading over multiple ## Decomposing Aurora DSQL DevFeed: [Decomposing Aurora DSQL]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2025-04-17T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [DSQL](), [Transactions](), [Concurrency](), [Firecracker](), [PostgreSQL](), [Replication](), [Availability](), [systems]() Tags: [architecture](), [availability](), [blog-post](), [concurrency](), [dsql](), [firecracker](), [postgresql](), [replication](), [systems](), [transactions]() ### 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 ## Snapshot Isolation vs Serializability DevFeed: [Snapshot Isolation vs Serializability]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2024-12-17T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [DSQL](), [Transactions](), [Databases](), [SQL](), [systems]() Tags: [database](), [dsql](), [fundamentals](), [internals](), [sql](), [transactions]() ### AI overview This article examines snapshot isolation and serializability in database systems, using read-write and write-write conflicts to explain transaction behavior. It focuses on write skew, read sets, write sets, and the trade-offs among SQL isolation levels, with Aurora DSQL providing the motivating context. ### Source excerpt Snapshot Isolation vs Serializability Getting into some fundamentals. In my re:Invent talk on the internals of Aurora DSQL I mentioned that I think snapshot isolation is a sweet spot in the database isolation spectrum for most kinds of applications. Today, I want to dive in a little deeper into why I think that, and some of the trade-offs of going stronger and weaker. This post is going to be a little deeper than the last few. If you're not deeply familiar with SQL's isolation levels, I recommend checking out Crooks et al's Seeing is Believing: A Client-Centric Specification of Database Isolation, Berenson et al's A Critique of ANSI SQL Isolation Levels, or Adya et al's Generalized Isolation Level Definitions. Specifically, I'm going to talk about one very specific mental model of transaction isolation: read-write conflicts, and write-write conflicts. Let's start our journey with a transaction, T1: BEGIN; SELECT amnt FROM food WHERE id = 1 OR id = 2; UPDATE food SET amnt = amnt - 1 WHERE id = 1; COMMIT; There are a few things to notice about this transaction, when run in a database system that offers interactive (i.e. back-and-forth with the client) transactions: It directly reads two rows from the database, the rows 1 and 2 from the table food. It directly writes one row in the database, the rows 1 from the table food. It starts and ends at different times: starting during BEGIN and ending during COMMIT. Depending on the way that database is implemented, it also likely reads other data (e.g. the system catalog which tells it which tables exist), and may write other data (e.g. a secondary index on the amnt column of food). The forth point here is critical in real systems, but let's ignore it for now and focus only on the first three2. Before we do that, let's introduce a second transaction, the first one's parallel universe clone, T2. We'll also assume these are the only transactions running at this time. BEGIN; SELECT amnt FROM food WHERE id = 1 OR id = 2; UPDATE f ## DSQL Vignette: Wait! Isn't That Impossible? DevFeed: [DSQL Vignette: Wait! Isn't That Impossible?]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2024-12-06T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [DSQL](), [Databases](), [Availability](), [Replication](), [Latency](), [Serverless](), [Network]() Tags: [architecture](), [availability](), [database](), [dsql](), [latency](), [network](), [replication](), [serverless]() ### AI overview This article examines how Aurora DSQL is designed for availability, durability, and strong consistency during infrastructure failures and network partitions. It focuses on the multi-region active-active architecture, including replicated regional infrastructure, a witness region, synchronous replication, latency trade-offs, and endpoint behavior when a region becomes unavailable. ### Source excerpt DSQL Vignette: Wait! Isn't That Impossible? Laws of physics are real. In today's post, I'm going to look at how Aurora DSQL is designed for availability, and how we work within the constraints of the laws of physics. If you'd like to learn more about the product first, check out the official documentation, which is always a great place to go for the latest information on Aurora DSQL, and how to fit it into your architecture. In yesterday's post, I mentioned that Aurora DSQL is designed to remain available, durable, and strongly consistent even in the face of infrastructure failures and network partitions. In this post, we're going to dive a little deeper into DSQL's architecture, focussing on multi-region active-active. Aurora DSQL is designed both for single-region applications (looking for a fast, serverless, scalable, relational database), and multi-region active-active applications (looking for all those things, plus multi-region, synchronous replication, and the ability to support active-active applications). Aurora DSQL's Multi-Region Architecture Let's start by dipping into Aurora DSQL's multi-region architecture. We'll focus on multi-region clusters here, because they highlight the trade-offs best, but the same rules apply to single region clusters if we substitute AZ for region. In a multi-region DSQL cluster1 each of two regions runs a nearly complete copy of the cluster's infrastructure: a full copy of storage, enough Query Processors (QPs) to handle the load, and so on. The exception is the adjudicator: the leader adjudicator for each shard exists in only one region at a time. We'll come back to that, because it's a key part of the story. What benefits does this architecture offer? Symmetric latency for active-active multi-region architectures. The read, write, and commit latency you'll see will be very similar from both regions (this is unlike databases that do write forwarding, or have a primary region, where there'll be one "fast" region and one or mo ## DSQL Vignette: Transactions and Durability DevFeed: [DSQL Vignette: Transactions and Durability]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2024-12-05T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [DSQL](), [Transactions](), [Concurrency](), [Databases](), [Replication](), [SQL]() Tags: [architecture](), [concurrency](), [database](), [dsql](), [replication](), [scale](), [sql](), [transactions]() ### AI overview This article examines how Aurora DSQL handles database writes and transaction isolation. It explains that writes are initially planned locally in the Query Processor, while commit processing selects a commit time and checks for conflicting writes through a disaggregated adjudicator service. ### Source excerpt DSQL Vignette: Transactions and Durability The hard half of a database system? In today's post, I'm going to look at the other half of what's under the covers of Aurora DSQL, our new scalable, active-active, SQL database. If you'd like to learn more about the product first, check out the official documentation, which is always a great place to go for the latest information on Aurora DSQL, and how to fit it into your architecture. Today, we're going to focus on writes (INSERTS, UPDATES, etc), and how transaction isolation works in Aurora DSQL. As I wrote about yesterday, reads in Aurora DSQL are done using a multiversion concurrency control (MVCC), allowing them to scale out across many replicas of many storage shards, and across a scalable SQL layer, with no contention or coordination between readers. We'd love to be able to achieve the same properties for writes, but the need to ensure that transactions are isolated from each other (the I in ACID), and ordered relative to each other (needed to get strong consistency) requires that we do some amount of coordination. The story of writes in Aurora DSQL is how and when that coordination happens. Let's consider an example transaction: START TRANSACTION; SELECT name, id FROM dogs ORDER BY goodness DESC LIMIT 1; UPDATE dogs SET latest_treat = now(), treats = treats + 1 WHERE id = 5; COMMIT; We do the read part just like we did the read part of yesterday's transaction: we choose a start time ($\tau_{start}$), and perform all our reads at that start time against our MVCC storage system. The writes proceed in a similar way: executing the UPDATE simply writes down a planned change locally inside the Query Processor (QP) that's running this transaction. No replication, durability, or writes to storage have occurred yet. That's important, because it means that the UPDATE (like the SELECT) is fast, in-region, and often in-AZ. Writing Takes Commitment The really interesting thing start with the COMMIT. We need to do three things ## DSQL Vignette: Reads and Compute DevFeed: [DSQL Vignette: Reads and Compute]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2024-12-04T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [DSQL](), [Databases](), [Scalability](), [Architecture & Design](), [SQL](), [Amazon Web Services](), [Amazon Aurora](), [AWS Lambda](), [Firecracker]() Tags: [architecture](), [aws](), [aws-lambda](), [cloud-native](), [database](), [dsql](), [firecracker](), [scalability](), [sql]() ### AI overview This article examines the architecture behind Aurora DSQL, focusing on SQL execution and transactional reads. It explains how DSQL independently scales compute, read throughput, write throughput, and storage by disaggregating storage from compute, and describes its dynamically scalable SQL execution layer. The article also discusses lessons from AWS Lambda and the use of Firecracker MicroVMs running customized Postgres engines for transactions. ### Source excerpt DSQL Vignette: Reads and Compute The easy half of a database system? In today's post, I'm going to look at half of what's under the covers of Aurora DSQL, our new scalable, active-active, SQL database. If you'd like to learn more about the product first, check out the official documentation, which is always a great place to go for the latest information on Aurora DSQL, and how to fit it into your architecture. Today, we're going to focus on running SQL and doing transactional reads. But first, let's talk scalability. One of the most interesting things in DSQL's architecture is that we can scale compute (SQL execution), read throughput, write throughput, and storage space independently. At a fundamental level, scaling compute in a database system requires disaggregation of storage and compute. If you stick storage and compute together, you end up needing to scale one to scale the other, which is either impossible or uneconomical. That's why, when we launched Aurora 10 years ago (nearly to the day!) we chose an architecture which separated compute and storage (from Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases, SIGMOD'17): As the paper says: We use a novel service-oriented architecture (see Figure 1) with a multi-tenant scale-out storage service that abstracts a virtualized segmented redo log and is loosely coupled to a fleet of database instances. In DSQL, we took this pattern one step further: we changed the interface between the SQL executor and storage to remove the need for a large local cache1 right next to the SQL engine. With that out of the way, we could build a new scalable SQL execution layer which can dynamically scale to meet the needs of nearly any workload. Compute Scale: Lessons from Lambda Aurora wasn't the only big launch at re:Invent 2014. Another big one was AWS Lambda2. AWS Lambda brought a new compute scalability model: the ability to scale up efficiently in small units, each with a single well-defined ## DSQL Vignette: Aurora DSQL, and A Personal Story DevFeed: [DSQL Vignette: Aurora DSQL, and A Personal Story]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2024-12-03T00:00:00Z Content type: opinion Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [DSQL](), [Databases](), [Serverless](), [Amazon Web Services](), [PostgreSQL](), [Scalability](), [Transactions](), [Availability]() Tags: [availability](), [aws](), [database](), [dsql](), [postgresql](), [postgresql-compatible](), [scalability](), [serverless](), [sql](), [transactions]() ### AI overview This article introduces Aurora DSQL, a serverless, PostgreSQL-compatible SQL database designed for cloud transaction processing. It describes scaling across workloads, strong consistency and isolation, active-active multi-writer deployments, local reads and writes, and durable atomic transaction commits across availability zones or regions. ### Source excerpt DSQL Vignette: Aurora DSQL, and A Personal Story It's happening. In this morning's re:Invent keynote, Matt Garman announced Aurora DSQL. We're all excited, and some extremely excited, to have this preview release in customers' hands. Over the next few days, I'm going to be writing a few posts about what DSQL is, how it works, and how to make the best use of it. This post is going to look at the product itself, and a little bit of a personal story. The official AWS documentation for Aurora DSQL is a great place to start to understand what DSQL is and how to use it. What is Aurora DSQL? Aurora DSQL is a new serverless SQL database, optimized for transaction processing, and designed for the cloud. DSQL is designed to scale up and down to serve workloads of nearly any size, from your hobby project to your largest enterprise application. All the SQL stuff you expect is there: transactions, schemas, indexes, joins, and so on, all with strong consistency and isolation5. DSQL offers active-active multi-writer capabilities in multiple availability zones (AZs) in a single region, or across multiple regions. Reads and writes, even in read-write transactions, are fast and local, requiring no cross-region communication (or cross-AZ communication in single region setups). Transaction commit goes across regions (for multi-region setups) or AZs (for single-regions setups), ensuring that your transactions are durable, isolated, and atomic. DSQL is PostgreSQL compatible, offering a subset of PostgreSQL's (huge) SQL feature set. You can connect with your favorite PostgreSQL client (even the psql cli), use your favorite ORMs and frameworks, etc. We'll be adding more PostgreSQL-compatible features over time, making it easy to bring your existing code to DSQL. DSQL is serverless. Here, we mean that you create a cluster in the AWS console (or API or CLI), and that cluster will include an endpoint. You connect your PostgreSQL client to that endpoint. That's all you have to do: management,