When Distributed SQL Is the Right Answer (and When It Isn't)

When Aurora DSQL was previewed at re:Invent 2024, several clients asked whether they should be planning around it. The answer is almost always “wait for GA, but yes, start thinking about it now if you have a specific kind of problem.”

This post is the framework we use to figure out which clients have that problem.

What distributed SQL means here

Aurora DSQL is a PostgreSQL-compatible managed service with three properties that distinguish it from regular Aurora:

1. Active-active across regions. No primary, no failover, writes accepted in any region.
2. Strong consistency. Reads are guaranteed to see prior writes, even across regions.
3. Serverless scaling. Capacity adjusts automatically with load.

The combination is unusual. Most database services force a tradeoff between active-active and strong consistency. Aurora DSQL gives you both, at the cost of higher per-transaction latency for cross-region writes and a narrower SQL feature surface than full PostgreSQL.

The clients who actually need this

In our consulting work we see distributed SQL pay off for a small set of patterns:

Globally distributed writes with relational semantics. Marketplace, ticketing, and inventory systems where users in different regions need to see consistent state and where a write originated in one region must immediately be visible in another. DynamoDB Global Tables can serve some of these workloads but loses transactional semantics; Aurora DSQL is built for them.

Multi-region active-active without operational overhead. Teams that need to survive a regional failure with zero RTO and have been deferring it because the operational lift of self-managed multi-region Postgres is too high.

Serverless workloads with relational data. Teams already running serverless API tiers (Lambda, App Runner) that have reluctantly used Aurora Serverless v2 and want a database that scales the same way the compute does.

The clients who don’t need it

The much larger set of workloads where regular Aurora is the right answer:

• Single-region applications. If you’re not actively planning multi-region, you don’t need distributed SQL.
• Write-light, read-heavy workloads. Aurora with read replicas already handles this well.
• Heavy use of stored procedures, triggers, or PostgreSQL extensions. DSQL’s feature surface is intentionally narrower; check compatibility before committing.
• Cost-sensitive small workloads. The pricing model favors larger workloads. Small databases run cheaper on Aurora Serverless v2 or even RDS.

A simple decision tree

When a client asks “should we use Aurora DSQL?” we walk through this:

1. Are you actively planning multi-region active-active? If no → use Aurora.
2. Is your workload relational with transactions across multiple rows? If no → consider DynamoDB Global Tables.
3. Do you depend on PostgreSQL extensions or stored procedures? If yes → wait for DSQL feature parity or stay on Aurora.
4. Otherwise → Aurora DSQL is worth piloting.

The first question disqualifies the majority of workloads. That’s the right outcome: distributed SQL is a specialized tool, not a default.

A note on the cost of being early

We’re not yet recommending Aurora DSQL for production-critical workloads as of this writing. The service is still maturing, the ecosystem support is uneven, and the cost model rewards waiting for stabilization.

If you have a workload that fits the framework above, the right play is a parallel pilot: build a non-critical service on Aurora DSQL, exercise it, and have a documented rollback to regular Aurora ready. By the time DSQL is fully production-grade, you’ll have the operational experience to use it well.

Closing

Distributed SQL isn’t a replacement for relational databases. It’s a specific answer to a specific problem: globally distributed transactional data with strong consistency. If that’s your problem, Aurora DSQL is one of the few managed answers in the market. If it isn’t, regular Aurora is almost certainly the right choice.

If you’re trying to figure out which side of that line your workload falls on, we’re happy to help work through it.