Aurora DSQL – Serverless Distributed SQL Database

Amazon Aurora DSQL

• Amazon Aurora DSQL is a serverless, distributed relational database service optimized for transactional (OLTP) workloads.
• Aurora DSQL was previewed at AWS re:Invent 2024 and became generally available on May 27, 2025.
• It offers virtually unlimited scale, the highest availability, and zero infrastructure management.
• Aurora DSQL is PostgreSQL-compatible (currently PostgreSQL 16), enabling developers to use familiar drivers, ORMs, tools, and SQL features.
• It is designed for 99.99% availability in single-Region configuration and 99.999% availability in multi-Region configuration.
• Aurora DSQL uses Optimistic Concurrency Control (OCC) instead of traditional pessimistic locking, eliminating deadlocks and lock contention.
• It supports active-active multi-Region deployments with strongly consistent reads and writes from any Region.
• Aurora DSQL scales to zero when idle — no compute charges when no queries are running.
• It eliminates all operational burden including patching, upgrades, maintenance downtime, capacity planning, and database sharding.

Aurora DSQL Architecture

• Aurora DSQL uses a disaggregated architecture where the database is separated into four independent, multi-tenant components that scale independently:
  • Query Processors (Firecracker MicroVMs) – Stateless compute units that handle SQL parsing, query planning, and execution. They run in AWS Firecracker MicroVMs (same technology as AWS Lambda), enabling true scale-to-zero behavior.
  • Adjudicators – The conflict detection layer that validates write transactions at commit time using Optimistic Concurrency Control. If conflicts are detected, the transaction is rejected with SQLSTATE 40001.
  • Journal (Paxos-Based Log) – A distributed write-ahead log using Paxos consensus that provides cross-AZ durability. Every committed transaction is written to the Journal before being acknowledged.
  • MVCC Storage Replicas – Multi-Version Concurrency Control storage that maintains table data across three Availability Zones in each active Region.
• A control plane coordinates all components, providing redundancy across three AZs with automatic scaling and self-healing.
• Each component scales independently — query processing, commit, and storage layers adapt to workloads of any shape including different read/write ratios, data sizes, and query complexities.

Single-Region Clusters

• Active-active across three Availability Zones, minimizing replication lag and eliminating traditional failover operations.
• All write transactions are committed to a distributed transaction log and synchronously replicated to storage replicas in three AZs.
• Designed for 99.99% availability.
• When a component or AZ becomes impaired, requests are automatically redirected to healthy infrastructure without manual intervention.

Multi-Region Clusters

• Provides 99.999% availability with active-active multi-Region deployment.
• Two Regional endpoints present a single logical database, both available for concurrent read and write operations with strong data consistency.
• Aurora DSQL synchronously replicates writes across Regions, enabling strongly consistent reads and writes from any linked cluster.
• A third Region acts as a witness Region — stores only encrypted transaction logs for Paxos quorum, not full data copies.
• Multi-Region clusters must be created within the same Region set (same continent):
  • US Regions: US East (N. Virginia), US East (Ohio), US West (Oregon)
  • Asia Pacific: Asia Pacific (Osaka), Asia Pacific (Seoul), Asia Pacific (Tokyo)
  • Europe: Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris)
• Cross-continent multi-Region clusters are not currently supported.

Aurora DSQL Key Features

• Serverless & Zero Infrastructure Management
  • No servers to provision, patch, upgrade, or manage.
  • No maintenance downtime — eliminates traditional database failover.
  • Automatically manages storage optimization, statistics collection, and performance tuning.
  • Scales to zero when idle with no compute charges.
• Active-Active Multi-Region
  • Both Regions accept concurrent reads and writes.
  • Single logical database across Regions with strong consistency.
  • No eventual consistency or missing data during failovers.
• Strongly Consistent Reads
  • Provides strong read-after-write consistency.
  • Readers always see the same data regardless of which Region they connect to.
  • Zero data loss for both single and multi-Region clusters due to synchronous replication.
• Optimistic Concurrency Control (OCC)
  • Transactions execute without acquiring locks.
  • Conflicts are detected at commit time, not during execution.
  • Eliminates deadlocks and prevents slow transactions from blocking others.
  • If conflicts occur, the later transaction receives SQLSTATE 40001 and must be retried by the application.
  • Read-only transactions are conflict-free and never fail due to OCC.
• Auto-Scaling
  • Scales compute, I/O, and storage automatically based on workload.
  • No database sharding or instance upgrades required.
  • Query processing, commit, and storage layers scale independently.
• 99.999% Multi-Region Availability
  • Active-active architecture with automatic failure recovery.
  • No manual failover or switchover operations.
  • Multi-AZ and multi-Region availability built-in.
• PostgreSQL Compatibility
  • Compatible with PostgreSQL 16 wire protocol.
  • Supports standard drivers: psycopg2, asyncpg, node-postgres, JDBC.
  • Supports ACID transactions, SQL queries, secondary indexes, joins, CTEs, window functions, aggregations.
  • IAM-based token authentication (no password-based authentication).
• ACID Transactions
  • Full ACID properties even across multiple Regions.
  • Strong snapshot isolation (equivalent to PostgreSQL REPEATABLE READ).
  • Cross-AZ and cross-Region durability.
• Change Data Capture (CDC)
  • Supports streaming changes to Amazon Kinesis Data Streams.
  • Billed as StreamDPU — scales with volume of changes captured.
• Security
  • Full integration with AWS IAM and AWS CloudTrail.
  • Token-based authentication using IAM (blocks standard password-based auth).
  • Encrypted transaction logs in witness Region.

Aurora DSQL Pricing

• Aurora DSQL uses a pay-per-use pricing model with no upfront costs.
• Billing is based on two primary components:
  • Database Activity (DPUs) – Distributed Processing Units measure all work done by the system including compute, I/O reads, I/O writes, and CDC streaming.
  • Storage (GB-month) – Based on total data stored, replicated across 3 AZs (you pay for one logical copy per Region).
• DPU Rate: $8.00 per million DPUs (in US East regions).
• Storage Rate: $0.33 per GB-month.
• Free Tier (permanent, no 12-month expiry):
  • 100,000 DPUs per month (~700,000 TPC-C transactions)
  • 1 GB of storage per month
• Multi-Region Write Replication: Incurs extra DPU charges equal to the cost of originating writes (approximately 50% premium on write DPUs). No separate data transfer charges.
• Scale to Zero: When the cluster is idle, DPU usage scales to zero — $0.00 compute charges. Only storage is billed continuously.
• DPU Sub-components (visible in CloudWatch, all billed at same rate):
  • ComputeDPU – SQL query execution (joins, functions, aggregations)
  • ReadDPU – Data read from storage
  • WriteDPU – Data written to storage
  • MultiRegionWriteDPU – Replication to peered clusters
  • StreamDPU – Change data capture streaming
• Aurora DSQL usage may be eligible for Database Savings Plans.
• Inter-AZ replication within a Region is included at no additional charge.

Aurora DSQL vs Aurora Serverless v2 vs Aurora Global Database vs DynamoDB Global Tables

Feature	Aurora DSQL	Aurora Serverless v2	Aurora Global Database	DynamoDB Global Tables
Architecture	Disaggregated, distributed, OCC	Standard Aurora engine, ACU-based scaling	Provisioned/Serverless instances with cross-Region replication	Fully managed NoSQL, partitioned
Data Model	Relational (SQL)	Relational (SQL)	Relational (SQL)	Key-Value / Document (NoSQL)
Multi-Region Writes	Active-Active (built-in)	Not supported (single-Region only)	Active-Passive (single writer, read replicas in other Regions)	Active-Active (all Regions accept writes)
Consistency	Strong consistency (reads and writes)	Strong consistency (single-Region)	Eventual consistency for cross-Region reads; strong in primary	Eventual consistency (cross-Region); strong consistency for single-Region reads
Availability SLA	99.99% (single-Region), 99.999% (multi-Region)	99.99%	99.99% with <1 min RTO for cross-Region failover	99.999%
Scaling	Serverless, scales to zero, virtually unlimited	Serverless, 0.5-128 ACUs, scales to zero	Provisioned instances or Serverless v2; manual scaling	On-demand or provisioned; auto-scaling
PostgreSQL Compatibility	Subset (no FK, triggers, sequences, stored procs, views)	Full Aurora PostgreSQL/MySQL	Full Aurora PostgreSQL/MySQL	Not applicable (NoSQL)
Concurrency Control	Optimistic (OCC) — no locks, retry on conflict	Pessimistic locking (traditional)	Pessimistic locking (traditional)	Last-writer-wins or conditional writes
Infrastructure Management	Zero (fully serverless)	Minimal (serverless but cluster management needed)	Moderate (instance sizing, replica management, failover config)	Zero (fully serverless)
Pricing Model	Per DPU ($8/million) + storage ($0.33/GB-month)	Per ACU-hour ($0.12/hr) + storage + I/O	Instance hours + storage + I/O + data transfer	Per WRU/RRU (on-demand) or provisioned WCU/RCU + storage
Free Tier	100K DPUs + 1 GB/month (permanent)	None (beyond general AWS Free Tier)	None	25 GB storage + 25 WCU/RCU (provisioned, 12-month)
Transaction Limits	3,000 rows per transaction	Standard PostgreSQL limits	Standard PostgreSQL limits	25 items / 4 MB per transaction
Best For	Global OLTP, low-contention writes, serverless backends, new apps	Variable workloads, existing PostgreSQL apps, single-Region	Disaster recovery, read scaling, cross-Region with single writer	High-throughput key-value access, global apps not needing SQL

Aurora DSQL Limitations

• PostgreSQL Feature Gaps:
  • No foreign keys (referential integrity must be enforced in application code)
  • No triggers
  • No views or materialized views
  • No sequences or SERIAL/IDENTITY columns (use UUIDs via gen_random_uuid())
  • No stored procedures (PL/pgSQL not supported; SQL functions are supported)
  • No PostgreSQL extensions (PostGIS, pgvector, etc.)
  • No explicit locking (SELECT FOR UPDATE not supported)
  • No temporary tables (use CTEs or regular tables with unique naming)
• Transaction Constraints:
  • Maximum of 3,000 rows modified per transaction (INSERT, UPDATE, DELETE)
  • DDL and DML operations require separate transactions
  • Only 1 DDL statement per transaction
  • Fixed isolation level: REPEATABLE READ only (no SERIALIZABLE, no READ COMMITTED)
• Operational Constraints:
  • Single database per cluster (named postgres) — use schemas for logical separation
  • Database connections time out after 1 hour
  • UTF-8 encoding only with C collation only
  • UTC system timezone
  • No password-based authentication (IAM token-based only)
• Multi-Region Constraints:
  • Cross-continent multi-Region clusters not supported
  • Multi-Region clusters must be within the same Region set
  • Multi-Region writes incur additional DPU charges (~50% premium)
• OCC Requirements:
  • Applications must implement retry logic for write transactions (handle SQLSTATE 40001)
  • Not suitable for high write-contention workloads (inventory counters, hot-row updates)
  • Each retry attempt consumes additional DPUs

Aurora DSQL Use Cases

Financial Transactions

• Global-scale financial transaction processing across multiple AWS Regions.
• Core banking systems requiring strong consistency without choosing between consistency and low latency.
• Spend management systems and digital currency infrastructure.
• Payment processing with ACID guarantees across Regions.
• The low-contention nature of financial transactions (each transaction typically touches unique records) makes OCC highly effective.

Global Applications

• Multi-Region SaaS applications requiring active-active writes with strong consistency.
• Global scheduling and booking systems (e.g., Frontdoor home services marketplace).
• Collaborative tools where users in different Regions need consistent data views.
• Multi-Region authentication and session management services.
• Microservices and event-driven architectures with serverless backends (Lambda + API Gateway + DSQL).

Gaming

• Global game state — maintaining consistent world state across geographically distributed players.
• Player inventory — managing in-game items and purchases with ACID guarantees preventing duplication exploits.
• In-game purchases — transactional integrity for virtual currency and item transactions.
• Live events — consistent event state across all Regions simultaneously.
• Real-time player interactions — ensuring consistent data for trades, gifts, and cooperative actions.
• Note: For high-contention leaderboard updates (many players updating the same row), DynamoDB or Aurora with pessimistic locking may be more appropriate. DSQL works well for leaderboards designed with per-player rows.

Other Use Cases

• Order management systems and e-commerce transaction processing.
• User profile and account management (low-contention per-user updates).
• Appointment and resource scheduling systems.
• Event logging and audit trail systems (append-only patterns).
• Development and testing environments (leveraging permanent free tier).

Aurora DSQL Region Availability

• GA Regions (May 2025 launch): US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Osaka), Asia Pacific (Tokyo), Europe (Ireland), Europe (London), Europe (Paris)
• Added July 2025: Asia Pacific (Seoul)
• Added October 2025: Europe (Frankfurt)
• Added February 2026: Additional Regions
• Added May 2026: Asia Pacific (Hong Kong), Asia Pacific (Mumbai), Asia Pacific (Singapore), Europe (Stockholm), South America (São Paulo)
• Region expansion continues through 2026.

AWS Certification Exam Relevance

• AWS Solutions Architect Associate (SAA-C03)
  • Understanding when to choose Aurora DSQL vs Aurora Serverless v2 vs DynamoDB Global Tables for multi-Region architectures.
  • Knowing the availability SLAs (99.99% single-Region, 99.999% multi-Region).
  • Understanding serverless database options and their trade-offs.
• AWS Solutions Architect Professional (SAP-C02)
  • Designing global, active-active architectures with strong consistency.
  • Understanding OCC implications for application design.
  • Comparing multi-Region database strategies: Aurora DSQL vs Aurora Global Database vs DynamoDB Global Tables.
  • Cost optimization for global database architectures.
• AWS Database Specialty (DBS-C01)
  • Deep understanding of Aurora DSQL architecture (disaggregated components, Paxos journal, Adjudicators).
  • PostgreSQL compatibility limitations and migration considerations.
  • OCC conflict resolution and retry patterns.
  • DPU pricing model and cost estimation.
  • When to use DSQL vs other Aurora variants vs DynamoDB.

Amazon Aurora DSQL Practice Questions

Question 1:

A company is building a global financial application that requires active-active writes in multiple AWS Regions with strong consistency for all reads. The application uses a relational data model with SQL queries and ACID transactions. Which database service is MOST appropriate?

1. Amazon Aurora Global Database
2. Amazon DynamoDB Global Tables
3. Amazon Aurora DSQL multi-Region cluster
4. Amazon Aurora Serverless v2 with cross-Region read replicas

Show Answer

Answer: C –

• Aurora DSQL multi-Region clusters provide active-active writes with strong consistency across Regions using a relational/SQL data model — exactly what this scenario requires.
• Aurora Global Database (Option A) supports only active-passive (single writer Region with read replicas in other Regions).
• DynamoDB Global Tables (Option B) provides active-active but with eventual consistency and a NoSQL data model, not relational SQL.
• Aurora Serverless v2 (Option D) is single-Region only and does not support cross-Region writes.

Question 2:

A development team is migrating an existing PostgreSQL application to Aurora DSQL. The application heavily uses foreign keys, database triggers for audit logging, and stored procedures for business logic. What should the team do?

1. Migrate directly — Aurora DSQL supports all PostgreSQL features
2. Refactor the application to enforce referential integrity in application code, move trigger logic to EventBridge/application layer, and move stored procedure logic to the application or Lambda functions
3. Use Aurora DSQL with PostgreSQL extensions to enable missing features
4. Use Aurora Serverless v2 instead, which provides full PostgreSQL compatibility without requiring application changes

Show Answer

Answer: B (if DSQL is required) or D (if full PG compatibility is the priority) –

Aurora DSQL does not support foreign keys, triggers, or stored procedures (PL/pgSQL). These are architectural limitations of the distributed design.

Option B is correct if the team must use DSQL — all these features need application-level workarounds.

Option D is the simpler path if the requirement is just serverless PostgreSQL without application refactoring.

Option A is incorrect — DSQL is a PostgreSQL-compatible subset, not full PostgreSQL.

Option C is incorrect — Aurora DSQL does not support PostgreSQL extensions.

Question 3:

An e-commerce company uses Aurora DSQL for its order processing system. During peak sales events, they notice increased transaction failures with SQLSTATE 40001 errors on their inventory update operations where multiple customers try to purchase the last few items simultaneously. What is the MOST likely cause and solution?

1. The database is running out of capacity; increase the provisioned instances
2. Aurora DSQL’s Optimistic Concurrency Control is detecting write conflicts on the same inventory rows; redesign to reduce contention or switch to Aurora Serverless v2 with pessimistic locking for the inventory service
3. The database connection pool is exhausted; increase the connection limit
4. The transaction isolation level needs to be changed to READ COMMITTED

Show Answer

Answer: B –

• SQLSTATE 40001 is the serialization failure error returned by Aurora DSQL’s OCC when concurrent transactions conflict on the same data.
• High-contention inventory updates (many writers to the same row) are a known poor fit for OCC — they generate high retry rates.
• Solutions include redesigning the schema to reduce contention, or using Aurora Serverless v2 with traditional pessimistic locking for high-contention workloads.
• Option A is incorrect — Aurora DSQL is serverless with no provisioned instances.
• Option D is incorrect — Aurora DSQL only supports REPEATABLE READ isolation; it cannot be changed.

Question 4:

A startup wants to minimize database costs for their development environment while building a globally distributed application. They need a PostgreSQL-compatible database that costs nothing when idle and has a permanent free tier. Which option BEST meets these requirements?

1. Amazon RDS PostgreSQL with a db.t3.micro instance (free tier)
2. Amazon Aurora Serverless v2 (scales to zero)
3. Amazon Aurora DSQL (scales to zero with permanent free tier)
4. Amazon DynamoDB with on-demand capacity

Show Answer

Answer: C –

• Aurora DSQL has a permanent free tier (100,000 DPUs + 1 GB storage/month with no 12-month expiry) and scales to zero when idle — $0 compute charges when not in use.
• RDS free tier (Option A) expires after 12 months and the instance runs continuously (always has charges after free tier expires).
• Aurora Serverless v2 (Option B) can scale to zero but does not have a permanent free tier for compute.
• DynamoDB (Option D) has a free tier but is NoSQL, not PostgreSQL-compatible.

Question 5:

A solutions architect is designing a multi-Region active-active database architecture using Aurora DSQL. The application serves users in the US and Europe. What is a key constraint the architect must consider?

1. Multi-Region clusters can span any two AWS Regions globally
2. Multi-Region clusters must be within the same continent/Region set — cross-continent clusters are not supported
3. Only one Region can accept writes at a time; the other Region is read-only
4. Multi-Region clusters require manual failover configuration

Show Answer

Answer: B –

• Aurora DSQL multi-Region clusters must be created within the same Region set (US Regions, Asia Pacific Regions, or European Regions). Cross-continent multi-Region clusters are not currently supported.
• The architect cannot create a cluster spanning US East and Europe — they would need separate single-Region clusters or a different approach for cross-continent active-active.
• Option A is incorrect — cross-continent is not supported.
• Option C is incorrect — both Regions accept concurrent reads AND writes (active-active).
• Option D is incorrect — Aurora DSQL provides automatic failure recovery with no manual failover.

Frequently Asked Questions

What is Amazon Aurora DSQL?

Aurora DSQL is a serverless, distributed SQL database that provides PostgreSQL compatibility with active-active multi-Region replication, strong consistency, and 99.999% availability — all without managing infrastructure.

How does Aurora DSQL differ from Aurora Global Database?

Aurora Global Database uses a primary-secondary model with async replication (1-second lag). DSQL provides active-active multi-Region writes with strong consistency and optimistic concurrency control, meaning both Regions can accept writes simultaneously.

Is Aurora DSQL compatible with PostgreSQL?

Yes, DSQL is wire-compatible with PostgreSQL and supports standard SQL. However, it has some limitations — it doesn’t support stored procedures, triggers, sequences, or advisory locks due to its distributed architecture.

Related Posts

• Aurora vs RDS vs DynamoDB
• RDS vs Aurora vs DynamoDB Selection Guide

References

• AWS Documentation – What is Amazon Aurora DSQL?
• Amazon Aurora DSQL Product Page
• Aurora DSQL Pricing
• AWS Blog – Introducing Amazon Aurora DSQL
• AWS Blog – Aurora DSQL for Global-Scale Financial Transactions
• AWS Blog – Aurora DSQL for Gaming Use Cases