The Aurora DSQL Guide

The Aurora DSQL Guide

Aurora DSQL is a distributed SQL database that speaks the PostgreSQL wire protocol. It is not PostgreSQL. Almost everything written about it so far explains the first half of that sentence; this guide is about the second half.

What it actually is #

DSQL is serverless, active-active, and strongly consistent across regions. There is no instance to size, no failover to orchestrate, no connection to a primary that might not be the primary anymore. It scales to zero and bills for what you use. For a certain shape of application — one that needs a relational model, unpredictable load, and multi-region durability without a dedicated DBA — there is nothing else in AWS quite like it.

The cost of that is a storage and transaction engine that AWS wrote from scratch. It answers to the same client libraries as PostgreSQL, so pg connects, psql connects, and your ORM probably connects. Then you write FOREIGN KEY and it says no.

The honest verdict #

Use DSQL if: your write volume is spiky or unpredictable, you want multi-region without building it, your schema is reasonably simple, and you are writing the application from scratch so you can design around the constraints from day one.

Do not use DSQL if: you are migrating an existing PostgreSQL application, you depend on extensions, you do bulk loads of more than a few thousand rows per transaction, or your data integrity story leans on foreign keys and triggers. The migration will not be a migration. It will be a rewrite, and you will find that out in week three.

That is a narrower door than the marketing suggests, and it is worth knowing which side of it you are on before you write a schema.

The guide #

More chapters are being written: connection handling and IAM token lifetime, the retry loop that optimistic concurrency forces on you, schema migrations without DROP COLUMN, and what to do about semantic search when DSQL has no vector type.

About #

Written by Chris, who has shipped two products on Aurora DSQL and hit most of this the hard way. Every claim here is meant to be reproducible against a live cluster — where something is quoted from AWS documentation rather than tested, it says so.