Aurora DSQL Explained: Serverless Postgres That Scales to Zero

Amazon Aurora DSQL is a serverless, distributed SQL database that speaks Postgres and scales to zero. It’s genuinely different from RDS and Aurora Serverless — here’s what it is, how it works, and when to reach for it.

What Aurora DSQL is

Aurora DSQL is a fully managed, PostgreSQL-compatible distributed database. The two properties that matter most: it has no instances to size — you don’t pick a class, provision storage, or manage capacity — and it’s active-active across Availability Zones (and, in multi-region configurations, across regions). There is no primary node to fail over; multiple endpoints accept reads and writes concurrently.

Because there’s nothing provisioned, an idle database effectively costs nothing. You pay for the requests and storage you actually use. For teams that want many environments — dev, staging, preview branches, per-customer — that cost model is the headline.

How it differs from what came before

• vs. RDS / Aurora (provisioned): No instance classes, no failover target, no idle baseline cost. You manage a connection string, not a fleet.
• vs. Aurora Serverless v2: v2 auto-scales compute but still has a provisioned floor and a primary writer. DSQL has no minimum capacity and is multi-writer.
• vs. DynamoDB: DynamoDB is key-value/document with its own API; DSQL is relational SQL with Postgres compatibility. You keep joins, transactions, and existing Postgres tooling.

The trade-offs to know

Distributed active-active SQL isn’t free of constraints. The most important ones to design around:

• Optimistic concurrency control. DSQL uses OCC rather than locking. Concurrent transactions that touch the same rows can fail at commit time with a serialization error, and your application is expected to retry. Wrap writes in a retry loop — this is the single biggest behavioral difference from RDS.
• Postgres compatibility is broad, not total. Some features and extensions aren’t supported, and there are limits on things like transaction size. Check the current feature and limits pages before porting a schema that leans on exotic Postgres features.
• IAM-based auth. You connect with short-lived IAM auth tokens rather than a long-lived password, which is great for security but means your connection setup generates a token instead of reading a static secret.

Connecting from an app

Because it’s Postgres-compatible, you use a standard Postgres driver — the twist is the password is a generated IAM token, not a fixed secret:

// Pseudocode: generate a short-lived IAM auth token, then connect
const token = await dsql.getAuthToken({ hostname, region });
const client = new pg.Client({
  host: hostname,
  user: 'admin',
  password: token,      // expires — generate per connection
  database: 'postgres',
  ssl: true,
});
await client.connect();

From there it’s ordinary SQL. Your migrations, query builder, and most tooling work unchanged — just remember the retry-on-serialization-error pattern for writes.

When to use it — and when not to

Reach for DSQL when you want a relational database with serverless economics, lots of cheap environments, multi-AZ resilience without managing failover, and you’re building a new app you can design around OCC from the start. It’s an excellent fit for a serverless SaaS backend.

Think twice if you’re lifting an existing app that depends on Postgres features or extensions DSQL doesn’t support, you need very large single transactions, or you can’t easily add retry logic to your write paths. In those cases Aurora Serverless v2 or provisioned RDS may be the smoother path.

The bottom line

Aurora DSQL pushes “serverless” all the way to the database: no capacity to manage, idle cost near zero, active-active by default, and Postgres on top. Design for optimistic concurrency and it’s one of the most compelling building blocks for a modern AWS SaaS — which is exactly why it’s the default data layer in the stack we build on.