Aurora DSQL: The Serverless PostgreSQL That Scales to Zero (Should You Migrate?)

Last Tuesday at 2 AM, I got the call every platform engineer dreads. Our Aurora PostgreSQL cluster hit max connections again—the third time this month. By the time I scaled up the instance, we'd already dropped 847 customer requests. The kicker? Our traffic had barely spiked. We were just paying for a db.r6g.2xlarge that sat idle 18 hours a day because we needed it for those unpredictable bursts.

Sound familiar? AWS heard us. At re:Invent 2024, they announced Aurora DSQL—a genuinely serverless PostgreSQL-compatible database that actually scales to zero. Not the "Serverless v2 with 0.5 ACU minimum" kind of serverless. Real, pay-for-what-you-use serverless.

But here's the thing nobody's talking about: migrating to DSQL isn't a lift-and-shift operation. It's a deliberate architectural decision that requires understanding what you're gaining—and what you're giving up.

What Makes DSQL Different (and Why It Matters)

Aurora DSQL isn't Aurora with a new pricing model. It's a completely different architecture that happens to speak PostgreSQL. Think of it as AWS's answer to Google Spanner or CockroachDB, but with the serverless twist that makes it compelling for teams like ours.

The core difference? Optimistic concurrency control instead of traditional locking. Your application needs to handle transaction retries—not just database connectivity retries, but actual conflict resolution. This is the price of admission for a database that can scale horizontally across regions while maintaining strong consistency.

Here's what you get in return:

• True scale-to-zero: No compute charges when idle, only storage ($0.23/GB-month)
• Active-active multi-region: Write to any region, read from any region, zero replication lag
• Automatic sharding: No manual partitioning, no connection pools, no read replicas to manage
• 99.999% multi-region availability: AWS actually commits to five nines

But you also give up:

• Foreign keys (coming on the roadmap)
• Triggers and stored procedures
• Full PostgreSQL compatibility (it's the wire protocol, not a fork)
• Predictable query costs (more on this later)

The Migration Decision Tree

Before we dive into the how-to, let's be honest about when DSQL makes sense. I've seen teams migrate for the wrong reasons and regret it.

You're a good fit if:

• Your traffic is spiky and unpredictable (think B2C apps, event-driven systems)
• You need multi-region active-active without building it yourself
• Your team is small and can't afford dedicated database operations
• You're building new applications that can design around DSQL's constraints

Think twice if:

• You're running complex analytical queries (stick with Aurora Serverless + Redshift)
• Your schema depends heavily on foreign keys and triggers
• You have a mature RDS deployment with fine-tuned queries
• Your traffic is steady and predictable (provisioned RDS is cheaper)

I learned this the hard way. We initially tried migrating our main OLTP workload and hit a wall with foreign key constraints. We ended up using DSQL for our new event streaming pipeline instead—perfect fit.

Migration Guide: From RDS/Aurora to DSQL

There's no magic "migrate" button. AWS doesn't even offer DMS support for DSQL yet (yes, really). Here's the path that worked for us.

Step 1: Schema Compatibility Audit

First, audit your schema for DSQL limitations. I wrote a quick script for this:

# Check for unsupported features
psql -h your-rds-instance.amazonaws.com -U postgres -d your_db -c "
SELECT 
    'Foreign Keys' as feature, 
    count(*) as count 
FROM information_schema.table_constraints 
WHERE constraint_type = 'FOREIGN KEY'
UNION ALL
SELECT 
    'Triggers', 
    count(*) 
FROM information_schema.triggers
UNION ALL
SELECT 
    'Stored Procedures', 
    count(*) 
FROM pg_proc WHERE prokind = 'p';
"

If any of these return non-zero, you'll need to refactor. Foreign keys became application-level validations for us. Triggers moved to Lambda functions triggered by DynamoDB Streams (we used DSQL alongside DDB for certain workflows).

Step 2: Set Up DSQL Cluster

Creating a DSQL cluster takes literally 30 seconds—no capacity planning required:

# Create single-region cluster
aws dsql create-cluster \
  --region us-east-1 \
  --cluster-identifier my-dsql-cluster

# Get connection details
export PGHOST=$(aws dsql describe-cluster \
  --cluster-identifier my-dsql-cluster \
  --query 'cluster.endpoint' --output text)

# Generate temporary password (expires in 15 minutes)
export PGPASSWORD=$(aws dsql generate-db-auth-token \
  --hostname $PGHOST \
  --region us-east-1)

export PGUSER=admin
export PGSSLMODE=require

Notice the password generation? DSQL uses IAM authentication only—no traditional PostgreSQL users. This is actually great for security, but your connection pooling code needs updates.

Step 3: Data Migration Strategy

Since DMS isn't available, you have three options:

Option A: pg_dump/pg_restore (for databases < 50GB)

# Dump from RDS
pg_dump -h rds-instance.amazonaws.com \
  -U postgres \
  -d production \
  --schema-only > schema.sql

pg_dump -h rds-instance.amazonaws.com \
  -U postgres \
  -d production \
  --data-only \
  --disable-triggers > data.sql

# Restore to DSQL (after manual schema fixes)
psql -h $PGHOST -U admin -d postgres < schema_fixed.sql
psql -h $PGHOST -U admin -d postgres < data.sql

Option B: Incremental approach (zero downtime, databases < 500GB)

We used a pattern borrowed from the logical replication playbook:

1. Set up dual writes: Write to both RDS and DSQL from your app
2. Backfill historical data using batch jobs
3. Verify data consistency with checksums
4. Cutover reads to DSQL, then turn off RDS writes

Option C: Just start fresh (new microservices)

Honestly? If you're building something new, don't migrate—just start on DSQL. We did this for our new notification service and never looked back.

Step 4: Application Code Changes

This is the real work. DSQL's optimistic concurrency means you need retry logic:

import psycopg2
from psycopg2 import errorcodes
import time

def execute_with_retry(conn, query, max_retries=3):
    """Execute query with automatic retry on conflicts"""
    for attempt in range(max_retries):
        try:
            cur = conn.cursor()
            cur.execute(query)
            conn.commit()
            return cur.fetchall()
        except psycopg2.Error as e:
            if e.pgcode == errorcodes.SERIALIZATION_FAILURE:
                conn.rollback()
                time.sleep(0.1 * (2 ** attempt))  # Exponential backoff
                continue
            raise
    raise Exception(f"Max retries ({max_retries}) exceeded")

# Usage
result = execute_with_retry(conn, """
    UPDATE accounts 
    SET balance = balance - 100 
    WHERE user_id = 'user_123'
    RETURNING balance
""")

We wrapped this in a decorator and applied it to all our transaction-heavy code paths. Conflict rate stayed under 2% even during peak traffic.

Real-World Performance Testing

Theory is cheap. Here's what we actually measured with our event processing service (previously on Aurora Serverless v2).

Test Setup:

• Workload: Insert-heavy (10k events/min average, 50k burst)
• Schema: 5 tables, no joins in hot path
• Test duration: 72 hours including weekend lull

Results:

The P99 latency increase surprised us at first. Turns out it's the optimistic locking—under high contention, you pay a retry penalty. But the cost savings and elimination of connection pool issues made it worthwhile.

One gotcha: query plan behavior is different. DSQL doesn't have traditional statistics or vacuum processes, so query optimization works differently. We had to rewrite a few queries that relied on specific PostgreSQL planner behavior.

Cost Analysis: The Real Numbers

Let's kill the suspense: DSQL's pricing is baffling. AWS charges in Distributed Processing Units (DPUs), which bundle compute + I/O into one opaque number.

Pricing breakdown (us-east-1):

• DPUs: $0.33 per million
• Storage: $0.23 per GB-month
• Free tier: 100,000 DPUs + 1GB storage per month

Here's what that actually means for different workloads:

Scenario 1: Side project blog (1k pageviews/day)

• ~50 DPUs/day for reads/writes
• 2GB storage
• Monthly cost: $0.00 (within free tier)
• RDS equivalent: $14.20 (db.t3.micro)

Scenario 2: SaaS dashboard (10k active users)

• ~2M DPUs/month (peaks during business hours)
• 15GB storage
• Monthly cost: $6.60 + $3.45 = $10.05
• Aurora Serverless v2 equivalent: $87+ (0.5 ACU minimum 24/7)

Scenario 3: E-commerce platform (steady 50k req/min)

• ~45M DPUs/month
• 150GB storage
• Monthly cost: $148.50 + $34.50 = $183
• Aurora provisioned equivalent: $445 (db.r6g.large + storage + I/O)

Scenario 4: Analytics-heavy workload (complex joins)

• Don't. Just don't. Use Redshift Serverless or Aurora I/O-Optimized.

The pattern? DSQL wins on spiky, unpredictable workloads. Loses on steady-state or read-heavy analytics.

Production Lessons: What We Wish We Knew

1. DPU cost is unpredictable until you measure

Unlike Aurora where you can estimate costs from instance hours + I/O, DSQL's DPU consumption varies wildly based on query complexity. We found queries with subselects consumed 3x more DPUs than equivalent joins.

Monitor your CloudWatch metrics religiously:

• ComputeDPU: Query execution work
• ReadDPU: Data retrieval
• WriteDPU: Data modifications

2. Connection management is different

DSQL doesn't have connection limits like RDS (no more max_connections errors!), but you still need connection pooling for performance. We use pgBouncer in transaction mode and saw a 30% reduction in latency.

3. Multi-region isn't free

If you enable multi-region, writes incur DPU charges in each region. A single INSERT costs 1x DPU locally, but 3x total with two peered regions. Budget accordingly.

4. IAM authentication needs infrastructure

You can't just hardcode credentials. We set up a Lambda layer that refreshes auth tokens every 10 minutes and injects them into our connection strings. Works beautifully but took a day to build.

The Verdict: Should You Migrate?

After six months running DSQL in production, here's my honest take:

Migrate if:

• You're spending >$500/month on Aurora/RDS for spiky workloads
• You're about to build multi-region active-active (DSQL saves you months)
• Your team lacks database expertise (DSQL requires less tuning)
• You're building greenfield microservices

Don't migrate if:

• Your schema relies on advanced PostgreSQL features
• You need predictable costs (DSQL can surprise you)
• Your workload is steady-state and tuned
• You're risk-averse (DSQL is still maturing)

For us, DSQL was a game-changer for new services but not worth migrating our core application. We now run a hybrid approach: RDS for legacy, DSQL for anything new and bursty.

The future looks promising though. AWS is actively adding features (views and unique indexes just launched). When foreign keys arrive, the migration story gets a lot cleaner.

Next Steps

If you're seriously considering DSQL:

1. Start with a proof of concept: Spin up a cluster (it's free during testing) and benchmark your actual queries
2. Audit your schema: Run the compatibility check and estimate refactoring effort
3. Calculate your DPU usage: AWS's pricing calculator won't help—you need to test
4. Plan for application changes: Optimistic concurrency requires code updates
5. Set up monitoring: CloudWatch metrics are essential for cost control

DSQL isn't a magical solution to all database problems. But for the right workload—unpredictable traffic, multi-region needs, small teams—it's genuinely transformative. We went from "database is down again" to "I forgot we have a database" in about three months.

That 2 AM call? Haven't gotten one since we migrated our spiky workloads to DSQL. And that db.r6g.2xlarge that sat idle most of the day? Decommissioned. The $4,800/year savings funded our entire observability budget.

Just make sure you understand what you're signing up for. DSQL is serverless done right, but serverless isn't right for everyone.

Have you migrated to Aurora DSQL? I'd love to hear your war stories. Drop a comment below or find me on Twitter [@dk_elumalai].