Amazon Aurora DSQL Explained: The 2026 Guide for AWS Teams

Anastasiia Kuten Marketing & Partnerships Department Manager

May 6, 2026

AWS partner dedicated to startups

• 2000+ Clients
• 5+ Years of Experience
• $10M+ saved on AWS

AWS released the most ambitious database it has ever built, and most teams still think it is just another flavor of Aurora. It is not.

Amazon Aurora DSQL is a new kind of database. Serverless, distributed, PostgreSQL-compatible, active-active across regions, with five nines availability and pay-per-use pricing that scales to zero when idle. It went into preview at re:Invent 2024, hit general availability in 2025, and is now expanding to more regions through 2026.

If you are building a new application that needs to scale globally and stay available no matter what, Aurora DSQL is probably the database you should be considering. If you are migrating an existing PostgreSQL workload, the picture is more complicated. This guide covers everything you need to know.

What Is Amazon Aurora DSQL?

Amazon Aurora DSQL is a serverless, distributed SQL database built for transactional (OLTP) workloads. It uses PostgreSQL-compatible syntax and the standard PostgreSQL wire protocol, so most existing PostgreSQL drivers, ORMs, and tools work with it.

What makes it different from regular Aurora PostgreSQL or Aurora Serverless v2:

• Active-active across multiple regions. Two regions can both accept reads and writes at the same time, with strong consistency. No primary or secondary. No failover required.
• True serverless. No instance sizes to pick. No capacity to provision. Compute, storage, and I/O scale independently and automatically based on actual workload.
• Scales to zero. When the database is idle, you stop paying for compute. Most other Aurora options charge a minimum even when nothing is happening.
• 99.999% availability in multi-region setups. That is roughly 5 minutes of downtime per year, the highest tier AWS offers for any database.
• Pay only for what you use. Billing is based on Distributed Processing Units (DPUs) and storage. No instance hours.

The short version: it is what you would build if you were starting from scratch today and wanted a database that handled global scale, high availability, and zero ops as architectural defaults.

Why AWS Built Aurora DSQL

For decades, application developers have had to pick between two unhappy paths when they needed a relational database to work across regions.

Path one: traditional replication with two-phase commit. Strong consistency, but slow. Every write has to coordinate across regions before it can complete, which adds latency and creates failure modes that are hard to recover from.

Path two: eventual consistency. Fast, but the application has to handle the messy reality that different regions might disagree about the state of the data for short windows. Developers end up writing reconciliation logic, idempotency handlers, and conflict resolution code in every service that touches shared state.

Aurora DSQL is AWS’s answer to “neither of these is good enough.” It gives you strong consistency across regions without the coordination overhead of traditional 2PC. You get a relational database that behaves like a single logical database to your application, even when it is physically distributed across multiple AWS regions.

How Aurora DSQL Works (Without the Marketing)

Aurora DSQL takes the traditional database stack and breaks it into independent layers that scale separately.

A traditional database has the query engine, the transaction processor, and the storage all coupled together on the same machine. When you need more capacity, you scale the whole thing.

Aurora DSQL splits these into separate layers:

• Query Processors (QPs): handle SQL parsing, planning, and execution. They are stateless, run inside Firecracker microVMs, and scale up or down automatically.
• Adjudicators: coordinate concurrency and decide which writes commit. They use a lease system to make sure only one adjudicator has authority over a given key range at a time.
• Journal: the durable, append-only log of all committed transactions. This is where durability lives in Aurora DSQL, not in the storage layer.
• Crossbar: reads from the journal, applies a global ordering, and routes data to the right storage shards.
• Storage: distributed across three Availability Zones for redundancy. Storage replicas are repaired automatically if they fail.

This decoupling is why Aurora DSQL can scale independently along each axis. If your workload is write-heavy, the journal scales. If it is read-heavy, more QPs spin up. If you store more data, the storage layer grows. None of these scaling events affect the others.

For multi-region clusters, Aurora DSQL uses two active regions plus a third witness region that participates only in transaction quorum. The witness region is the tiebreaker if the network between the two active regions is partitioned. This is similar to how Google Spanner works, but with a different consistency model.

Aurora DSQL vs Other AWS Databases: Where It Fits

This is the question most teams need answered before they consider Aurora DSQL seriously.

Aurora DSQL vs Aurora PostgreSQL (Standard)

Standard Aurora PostgreSQL is a managed PostgreSQL with great performance and high availability inside one region. It supports all PostgreSQL features. Multi-region is possible through Global Database, but it is active-passive, not active-active.

Aurora DSQL is active-active across regions, true serverless (scales to zero), and supports a subset of PostgreSQL. Pick standard Aurora PostgreSQL if you need full PostgreSQL feature support or your workload fits comfortably in one region. Pick Aurora DSQL if you need multi-region writes or want zero infrastructure management.

Aurora DSQL vs Aurora Serverless v2

Aurora Serverless v2 scales compute up and down based on load, but it does not scale to zero. There is always a minimum capacity charge. It is single-region active-passive.

Aurora DSQL is more serverless: it actually goes to zero when idle. Even at low scale, Aurora DSQL is often cheaper. At high scale with stable load, Aurora Serverless v2 can be cheaper if you reserve capacity.

Aurora DSQL vs DynamoDB

DynamoDB is a managed NoSQL database. It scales effortlessly and offers global tables for multi-region active-active. The trade-off: NoSQL data model, eventual consistency by default (with strong consistency available), and a learning curve if your team thinks in SQL.

Aurora DSQL gives you SQL, ACID transactions, and joins. If your data is relational and your team writes SQL, Aurora DSQL is the better fit. If your access patterns are well-defined and you want to optimize for predictable performance at any scale, DynamoDB still wins.

Aurora DSQL vs Google Cloud Spanner

Spanner is the closest competitor: globally distributed SQL with strong consistency. AWS claims Aurora DSQL achieves reads and writes up to 4x faster than Spanner in internal benchmarks.

The architectural difference: Spanner uses TrueTime (atomic clocks and GPS) and Paxos for consensus. Aurora DSQL uses microsecond-accurate clock synchronization and a different journaling model. In practice, both deliver strong consistency across regions. Spanner has been battle-tested at Google scale for over a decade. Aurora DSQL is newer but ships with deep AWS ecosystem integration (IAM, CloudTrail, VPC).

What Aurora DSQL Is Best For

Aurora DSQL is purpose-built for OLTP workloads where availability and global scale matter more than supporting every PostgreSQL feature.

Global SaaS applications. If your users are spread across continents and you need consistent low latency for everyone, Aurora DSQL’s multi-region active-active model means users hit the closest region with full read/write capability.

Financial services. Core banking ledgers, payments, trade settlement, and digital currency platforms need strong consistency, ACID transactions, and high availability. Aurora DSQL gives you all three across regions without manual failover or reconciliation logic.

E-commerce and inventory systems. Active-active means a regional outage does not take your store offline. Inventory counts stay consistent across regions automatically.

Gaming backends. Player profiles, leaderboards, and inventory need to work across regions with low latency. Aurora DSQL’s serverless scaling handles unpredictable spikes (game launches, events) without capacity planning.

Cloud-native microservices. If you are building event-driven, serverless architectures with Lambda and Step Functions, Aurora DSQL fits the same operational model: pay per use, scale automatically, no infrastructure to manage.

What Aurora DSQL Is Not Good For

This is the part most marketing-driven articles skip. Aurora DSQL has real limitations that will be deal-breakers for some workloads.

Existing PostgreSQL applications using advanced features. Aurora DSQL supports a subset of PostgreSQL. Features that are not supported (or work differently): foreign keys, triggers, views, sequences, stored procedures, materialized views, certain JSON types, geospatial extensions like PostGIS, vector data types, and many extensions. If your application depends on these, migration will require significant rework.

Bulk data operations and ETL. Aurora DSQL has a 10,000-row limit per transaction. If you regularly run large bulk inserts, updates, or deletes, this will be a problem. The workaround is to batch operations into smaller transactions, but it adds complexity.

Workloads with high write contention on the same rows. Aurora DSQL uses optimistic concurrency control (OCC). When two transactions try to modify the same data, one of them is rejected and your application has to retry. For workloads with frequent contention (think high-frequency counter updates on the same rows), this creates retry storms and degraded performance.

Long-running queries or sessions. Database connections time out after 1 hour. Transactions have a 5-minute limit. This is fine for OLTP workloads but breaks reporting, analytics, or batch jobs that take longer.

Analytics workloads. Aurora DSQL is built for OLTP, not OLAP. For analytics, use Redshift, Athena, or read replicas of standard Aurora PostgreSQL.

Workloads needing cross-database queries. Aurora DSQL uses a single built-in database named postgres per cluster. For logical separation, you have to use schemas or create separate clusters.

Aurora DSQL Pricing Explained

Aurora DSQL has a pricing model that is genuinely different from anything else in the Aurora family. Understanding it upfront prevents bill surprises.

The Two Billing Dimensions

Distributed Processing Units (DPUs): a unified metric that combines compute AND I/O into a single number. There is no separate I/O line item like there is in standard Aurora. DPUs measure the total work your queries do.

Pricing in US East regions: $8.00 per million DPUs.

DPUs break down into sub-components visible in CloudWatch:

• Compute DPUs: query execution (joins, functions, aggregations)
• Read DPUs: data retrieval from storage
• Write DPUs: data writes through the journal

Storage: $0.33 per GB-month. Single billing line for the data your cluster stores.

Multi-Region Costs

Multi-region clusters add roughly 50% to DPU costs because writes have to be replicated across regions. Storage is also charged in each region (you are storing the data twice).

The Free Tier (This Is a Big Deal)

Aurora DSQL has the only meaningful free tier in the entire Aurora product family:

• 100,000 DPUs per month, free, ongoing (no 12-month expiration)
• 1 GB of storage per month

This is enough for personal projects, development environments, and small applications. There is no equivalent free tier for Aurora PostgreSQL or Aurora Serverless v2.

Discount Options

Aurora DSQL is eligible for AWS Database Savings Plans (up to 35% savings with a 1-year commitment). It is NOT eligible for Reserved Instances (which do not exist for serverless services anyway).

Realistic Cost Examples

For a moderate SaaS application with say 1 million transactions per day at 5 DPUs each, single region:

• DPU cost: 1M × 5 × 30 = 150M DPUs/month = $1,200/month
• Storage (50 GB): $16.50/month
• Total: ~$1,217/month

For the same workload across two regions multi-region:

• DPU cost: ~$1,800/month (50% premium for cross-region writes)
• Storage in two regions: $33/month
• Total: ~$1,833/month

Compare this to running comparable Aurora Global Database with provisioned instances and you are typically looking at $2,500 to $4,000/month for the same workload, plus capacity planning and management overhead. The savings are real but require honest workload measurement.

Region Availability

As of May 2026, Aurora DSQL is generally available in these AWS regions:

• US East (N. Virginia, Ohio)
• US West (Oregon)
• Europe (Ireland, Frankfurt, Paris)
• Asia Pacific (Tokyo, Osaka, Seoul, Mumbai)

Multi-region peered clusters are supported between most of these regions. AWS continues to add regions roughly every quarter.

For multi-region clusters, you need to choose: two active regions (the ones serving traffic) plus one witness region. The witness participates in transaction quorum but does not store data, so its cost contribution is minimal.

How to Get Started with Aurora DSQL

Creating your first cluster takes about 2 minutes.

1. Sign in to the AWS Console and navigate to Amazon Aurora DSQL
2. Click Create cluster
3. For a single-region cluster, just give it a name and choose your region. For multi-region, you will configure two regions plus a witness
4. Enable deletion protection (recommended for anything other than throwaway tests)
5. Click Create cluster

Once the cluster is active, connect using the built-in Query Editor in the console, AWS CloudShell, or any standard PostgreSQL client like psql or pgAdmin.

Connection example with psql:

PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token \
  --hostname YOUR_CLUSTER_ENDPOINT \
  --region us-east-1) \
psql --host YOUR_CLUSTER_ENDPOINT \
  --user admin \
  --dbname postgres

Aurora DSQL uses IAM authentication by default. The auth token is short-lived and rotates automatically, so you do not manage long-lived database passwords.

Common Migration Patterns from PostgreSQL

Migrating an existing PostgreSQL application to Aurora DSQL is not a lift-and-shift. Plan for these changes:

Replace foreign keys with application-level validation. Aurora DSQL does not enforce foreign keys at the database layer. Move integrity checks into your application code or service layer. Many high-scale applications already do this for performance reasons.

Replace triggers with explicit logic. If you depend on triggers for audit logging, cascade updates, or denormalization, refactor that logic into application code or use AWS services like EventBridge or DynamoDB Streams.

Handle optimistic concurrency control. Aurora DSQL rejects conflicting writes with error code 40001. Your application needs retry logic to handle these gracefully. Most ORMs (Hibernate, SQLAlchemy, Sequelize, Prisma) have retry support, but you have to enable and tune it.

Batch large operations. Anywhere your code does a bulk insert or update of more than 10,000 rows, break it into smaller transactions.

Replace materialized views with denormalized tables. Update them through application logic or scheduled Lambda functions.

Avoid extensions. If you depend on PostGIS, pgvector, or other extensions, Aurora DSQL is not the right choice. Stay on standard Aurora PostgreSQL or RDS PostgreSQL.

Security and Compliance

Aurora DSQL inherits the AWS security model:

• IAM authentication by default, with token-based auth that rotates automatically
• Encryption at rest with AWS-managed keys or your own customer-managed KMS keys
• Encryption in transit with TLS 1.2+
• VPC integration through AWS PrivateLink endpoints, so traffic never has to traverse the public internet
• CloudTrail integration for full audit logging of all API calls
• Resource-based policies for granular access control at the cluster level

Aurora DSQL is HIPAA-eligible (with a signed BAA), in scope for SOC 1, 2, and 3, and ISO 27001 certified. For GDPR, deploy in EU regions only and your data stays in the EU.

Frequently Asked Questions

Is Aurora DSQL the same as Aurora Serverless?
No. Aurora Serverless v2 is a serverless deployment option for standard Aurora PostgreSQL or MySQL. It is single-region, active-passive, and supports the full feature set of the underlying engine. Aurora DSQL is a different product entirely, with multi-region active-active and a different (smaller) feature set.

Does Aurora DSQL support MySQL?
No. Aurora DSQL is PostgreSQL-compatible only. There is no MySQL version, and AWS has not announced plans for one.

Can I use Aurora DSQL with my existing PostgreSQL ORM?
Most ORMs work with minor configuration changes, including SQLAlchemy, Hibernate, Sequelize, Prisma, and Entity Framework. The exception is anything that relies on PostgreSQL features Aurora DSQL does not support (sequences, certain extensions, etc.). Test thoroughly before committing.

What happens if a region goes down in a multi-region cluster?
The other active region keeps serving reads and writes. The witness region helps maintain quorum. There is no failover process and no data loss because all committed transactions are durable across regions before they are acknowledged.

How is Aurora DSQL different from Aurora Limitless?
Aurora Limitless is horizontal scaling for standard Aurora PostgreSQL (sharding within one region). Aurora DSQL is a different database with a different architecture, designed for multi-region active-active. They solve different problems.

Can I run analytics queries on Aurora DSQL?
Not really. The 5-minute transaction limit and OLTP-optimized design make it a poor fit for analytics. For analytics, replicate to Redshift, Athena, or run a separate analytics-optimized database.

Does Aurora DSQL support read replicas?
There is no traditional concept of read replicas because the architecture distributes reads automatically across the cluster. In multi-region setups, both active regions serve reads with strong consistency.

What is the minimum cost of running Aurora DSQL?
With the free tier, $0 for development workloads. With production traffic, costs start at a few dollars per month and scale linearly with DPU consumption.

How does Aurora DSQL handle schema migrations?
Standard PostgreSQL DDL (CREATE TABLE, ALTER TABLE, etc.) is supported. Schema changes propagate across regions automatically. There are some restrictions on certain ALTER operations on large tables, so test migrations against representative data sizes.

Is Aurora DSQL suitable for production?
Yes, it has been generally available since 2025 and is in production use at customers like Frontdoor (mentioned in AWS case studies for scheduling applications) and other large SaaS and financial services companies. The architectural maturity is solid. The remaining concerns are mostly around the feature set, which AWS continues to expand.

Should You Use Aurora DSQL?

The honest answer depends on three questions.

Are you building something new, or migrating something old? If new, Aurora DSQL is worth a serious look. If old, the migration cost (refactoring foreign keys, triggers, etc.) needs to be weighed against the benefit.

Do you need multi-region active-active? If yes, Aurora DSQL is the easiest path on AWS. If no, you might be better off with Aurora Serverless v2 or standard Aurora PostgreSQL, which give you the full PostgreSQL feature set.

Is your workload OLTP and within the size limits? If yes, you are in the sweet spot. If you have analytics, batch jobs, or large transactions, Aurora DSQL is going to cause friction.

For most cloud-native SaaS, fintech, and gaming applications being built today, Aurora DSQL is genuinely the best database AWS offers. For most existing PostgreSQL applications, it is not.

Summary

Amazon Aurora DSQL is a new kind of database for a new generation of applications. It is serverless, distributed, PostgreSQL-compatible, multi-region active-active, and pay-per-use. It scales to zero when idle and to virtually unlimited capacity when needed. It delivers up to 99.999% availability without manual failover.

The trade-offs are real: a subset of PostgreSQL features, transaction size limits, and a pricing model that requires honest workload measurement to predict. But for the workloads it is designed for (transactional, global, cloud-native), it is one of the most compelling database services on the market.

If you are starting a new project that needs to scale globally and stay available, do not pick a database based on what was best practice in 2018. Aurora DSQL is what AWS believes the next decade of databases looks like, and it is worth at least a free-tier cluster to see for yourself.