Aurora DSQL Is GA: What We Found in Our Pilot

Aurora DSQL went generally available on May 27, 2025. We’ve been running it in a pilot project on a non-production workload since the early-access window, and we’ve now had enough hands-on time to share what we’ve learned.

This post is a follow-up to our March piece on when distributed SQL is the right answer. The decision framework still holds. The picture of “what it’s actually like to operate” is now considerably clearer.

What we built

The pilot was a customer-facing read/write workload for one of our internal tools: moderate traffic, multi-region active-active across us-east-1 and us-west-2, real strong-consistency requirements. The kind of workload where DynamoDB Global Tables would have been forced to sacrifice transactional semantics, and where self-managed multi-region Postgres would have meant taking on real operational complexity.

We started with the assumption that DSQL would either be a clear win or a clear “wait for v2” situation. The actual answer turned out to be more nuanced.

What held up

Several things worked well:

Multi-region writes really are seamless. Writes accepted in either region appear immediately in the other. No primary, no failover dance. This is the part that’s most interesting on the marketing slides, and it’s the part that delivered.

Operational surface is genuinely small. No replication to monitor, no failover to test, no instance class to tune. The serverless scaling model is real. For a team that doesn’t want to spend time on database operations, this is a meaningful relief.

Cost behavior was predictable. The pricing model rewards consistent traffic and is reasonable at moderate scale. No surprises in the first three months of the bill.

What surprised us

A few things we didn’t fully appreciate from the docs:

The PostgreSQL feature surface is narrower than it looks at a glance. No triggers. No stored procedures in PL/pgSQL. Limited extension support. We knew this going in, but the practical impact is bigger than expected. Code that assumes “Postgres compatibility” without testing will hit feature gaps. Test thoroughly before committing.

Cross-region write latency is real. Single-region transactions are fast. Cross-region transactions (where the write coordinator and the application aren’t co-located) carry tens of milliseconds of additional latency. Not a deal-breaker, but it changes how you design hot paths.

Tooling around the database is still maturing. Standard PostgreSQL tooling mostly works, but the ecosystem of monitoring, query analysis, and migration tools is thinner than for Aurora Postgres. We adjusted our tooling expectations.

Cold-start behavior on idle instances. The serverless scaling means the first request after a quiet period can carry noticeable latency. Important for low-traffic services; less of an issue for sustained workloads.

How we’d update the framework

In our March post, we said:

We’re not yet recommending Aurora DSQL for production-critical workloads as of this writing.

That’s now too cautious. Our updated stance:

• For new workloads that fit the framework (multi-region active-active, transactional, no exotic Postgres features), DSQL is a reasonable production choice as of GA.
• For migrations from existing Aurora, we still recommend caution. The benefit needs to be substantial enough to justify the migration cost; “we want active-active” usually isn’t enough by itself.
• For workloads with heavy stored-procedure or extension dependencies, stay on Aurora Postgres for now. DSQL feature parity will keep improving, but the gap is real today.

Worth knowing if you’re about to pilot

A few practical notes from our pilot:

• Use the AWS-provided pgbench-style load testing tools to characterize your workload before committing.
• Profile your queries against DSQL specifically. Query plans differ from Aurora Postgres in ways that matter for hot paths.
• Plan a rollback to regular Aurora as part of your pilot design. We never had to use ours, but we’d have done the pilot differently if we hadn’t built it in.
• Watch the AWS DSQL changelog actively in the first six to twelve months post-GA. Feature additions are coming fast.

Closing

Aurora DSQL GA is a real milestone. It moves distributed SQL from “interesting AWS announcement” to “credible production database choice for a specific set of workloads.” If your workload fits, it’s worth seriously evaluating. If it doesn’t, regular Aurora is still the right answer.

If you’re working through whether DSQL fits your workload, or planning a pilot, we’d be glad to help.