# DSQL Vignette: Reads and Compute

DevFeed: [DSQL Vignette: Reads and Compute](<https://devfeed.tech/articles/dsql-vignette-reads-and-compute-12564.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2024/12/04/inside-dsql.html>)

Author: Marc Brooker

Published: 2024-12-04T00: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>), [Scalability](<https://devfeed.tech/topics/scalability.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [SQL](<https://devfeed.tech/topics/sql.md>), [Amazon Web Services](<https://devfeed.tech/topics/aws.md>), [Amazon Aurora](<https://devfeed.tech/topics/amazon-aurora.md>), [AWS Lambda](<https://devfeed.tech/topics/aws-lambda.md>), [Firecracker](<https://devfeed.tech/topics/firecracker.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [aws](<https://devfeed.tech/tags/aws.md>), [aws-lambda](<https://devfeed.tech/tags/aws-lambda.md>), [cloud-native](<https://devfeed.tech/tags/cloud-native.md>), [database](<https://devfeed.tech/tags/database.md>), [dsql](<https://devfeed.tech/tags/dsql.md>), [firecracker](<https://devfeed.tech/tags/firecracker.md>), [scalability](<https://devfeed.tech/tags/scalability.md>), [sql](<https://devfeed.tech/tags/sql.md>)

## 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