AWS has been iterating on their database offerings for years, trying to bridge the gap between traditional relational databases and the serverless world. With three distinct Aurora PostgreSQL offerings now available, let's break down each one:

	Serverless v2	PostgreSQL Limitless	DSQL
Architecture	Single-writer instance	Sharded with router nodes	Distributed SQL with active-active architecture
Scaling	Vertical (0.5-256 ACUs)	Horizontal (16-6144 ACUs)	Automatic both directions
Multi-Region	Read replicas only	Single region only	Active-active multi-region
High Availability	Multi-AZ failover	Multi-AZ within shards	99.99% single-region, 99.999% multi-region
Best For	Variable workloads	Large-scale OLTP with known sharding keys	Global applications needing consistent data

DSQL Architecture

What makes DSQL interesting isn't just that it's serverless - it's a fundamental rethinking of how a cloud database should work. Instead of running everything on a single instance or using a primary-replica model, DSQL splits functionality into distinct layers that can scale independently:

1. Transaction and Session Router

Handles incoming client connections and the postgres protocol
Routes queries to appropriate query processors

2. Query Processor

Parses and plans SQL queries
Utilises the AWS TimeSync service to ensure a consistent snapshot across nodes
Executes queries directly on the storage layer

3. Adjudicator

Implements optimistic concurrency control
Validates transaction commits
Ensures consistency across regions
Manages conflict resolution
Key to enabling active-active multi-region without explicit sharding

4. Journal

Maintains distributed transaction log
Provides durability guarantees
Enables point-in-time recovery
Synchronously replicates across regions
Critical for maintaining consistency in distributed environment

5. Storage

Manages data persistence and partitioning
Automatically rebalances data across nodes
Handles data replication across AZs
Scales independently of compute layers
Provides consistent performance at any scale

Each layer scales horizontally, independently, and dynamically based on workload demands. This architecture is what enables DSQL's key capabilities:

True Active-Active Multi-Region: The adjudicator and journal layers work together to maintain consistency across regions
Independent Scaling: Each layer can grow or shrink based on its specific demands
True High Availability: With 99.999% for multi-region deployments, there are no single points of failure
Consistent Performance: Potential bottlenecks in one layer don't affect others

Real-World Performance

I built a test application that creates a few million records and hammers it with queries. Here's what I found:

Single-key lookups: 8.8ms p95 latency
Performance is smooth at p95 with spikes only at p99
Write transactions also show consistent low latency
Multi-region write & reads are consistent
No lock contention
No cold start penalties

And because of my last LinkedIn post where i learned everyone was scared of Rust for some reason, let's take a look at an example of writing and reading back some data:

async fn example(cluster_endpoint: String, region: String) -> anyhow::Result<()> {
    // Generate auth token
    let sdk_config = aws_config::load_defaults(BehaviorVersion::latest()).await;
    let signer = AuthTokenGenerator::new(
        Config::builder()
            .hostname(&cluster_endpoint)
            .region(Region::new(region))
            .build()
            .unwrap(),
    );
    let token = signer.db_connect_admin_auth_token(&sdk_config).await?;

    // Setup connection
    let connection_options = PgConnectOptions::new()
                .host(cluster_endpoint.as_str())
                .port(5432)
                .database("postgres")
                .username("postgres")
                .password(token.as_str())
                .ssl_mode(sqlx::postgres::PgSslMode::VerifyFull);

    let pool = PgPoolOptions::new()
        .max_connections(10)
        .connect_with(connection_options.clone())
        .await?;

    // Insert
    let result = sqlx::query(
        "INSERT INTO orders (customer_id, amount) VALUES ($1, $2)"
    )
    .bind("customer-123")
    .bind(99.99)
    .execute(&pool)
    .await?;

    // Query 
    let orders = sqlx::query_as!(
        Order,
        "SELECT id, customer_id, amount FROM orders WHERE customer_id = $1",
				"customer-123"
    )
    .fetch_all(&pool)
    .await?;

    pool.close().await;
    Ok(())
}

Even with cold starts from the Lambda side, we're seeing on average < 25ms total execution time in Rust (al2023) - matching or beating warm Node.js performance.

When Should You Use DSQL?

The choice is pretty clear based on your needs:

Choose DSQL when you need:

Global applications with consistent data everywhere
Five 9s availability with multi-region deployment
Local latency without sacrificing consistency
Automatic scaling without thinking about sharding
Single digit millisecond latency for most operations

Stick with Serverless v2 for:

Apps you need in production right now
Simple apps that just need elastic scaling
Workloads requiring full PostgreSQL compatibility
Dev/test environments
Single-region applications

Current Limitations

Being in preview, there are some things to be aware of:

No foreign key constraints (by design)
No word on billing (though everyone expects a model similar to Dynamo)
No PostgreSQL extensions
IAM-only authentication
Some PostgreSQL features not yet supported
See the full list of known issues

The Future is Distributed

DSQL represents AWS's most ambitious attempt yet at solving distributed SQL. Rather than trying to make traditional databases more cloud-friendly, they've rebuilt DSQL from first principles. The result is a database that offers global scale and strong consistency without the usual tradeoffs.

Is it ready for production? Obviously not yet. But the architecture is sound, the performance is there, and it solves real problems that companies face when building applications. Plus you don't need to learn single table design for DynamoDB - and that's hardly a bad thing.

Aurora DSQL: The Future of Serverless Relational Data