AWS
Microsoft Azure
Google Cloud
Understand how Aurora DSQL scales, how DPU pricing works, and when it makes sense for distributed AWS workloads.
The short answer
Aurora DSQL is most compelling when a transactional application needs serverless operations, high availability, or active-active writes across AWS Regions.If you already run Aurora PostgreSQL and mainly want automatic capacity scaling, Aurora Serverless v2 may be a simpler fit.
The decision should be driven by workload architecture, compatibility, and cost rather than which service is newer.
What is Aurora DSQL?
Amazon Aurora DSQL is a fully managed distributed SQL database optimized for OLTP workloads.AWS describes it as a serverless relational database that automatically scales compute, I/O, and storage while removing server provisioning, patching, and infrastructure upgrades. See the AWS Aurora DSQL documentation.
Common use cases include:
Microservices
Serverless backends
Event-driven applications
Global SaaS platforms
High-availability transactional systems
For a deeper breakdown of DPUs, storage, and multi-Region costs, read our Aurora DSQL pricing guide.
How Aurora DSQL works
Aurora DSQL separates compute, transaction coordination, and storage so each part can scale independently with workload demand.It also uses optimistic concurrency control.
Instead of relying on traditional row locking throughout transaction execution, DSQL validates transactions when they commit. If another transaction changes conflicting data, the application may need to retry.
That matters for workloads where many concurrent requests modify the same records, such as balances, counters, or high-demand inventory.
Simplified request flow
Your application sends a SQL request.
Aurora DSQL processes the query.
Transaction changes are validated.
Committed data is written to distributed storage.
Multi-Region clusters coordinate writes across Regions.
Aurora DSQL pricing
Aurora DSQL uses usage-based pricing instead of traditional database instance-hour pricing.| Cost area | Billing model |
|---|---|
| Database activity | Distributed Processing Units |
| Storage | GB-month |
| Multi-Region writes | MultiRegionWriteDPU |
| CDC streaming | StreamDPU plus Kinesis charges |
| Data transfer | Applicable AWS transfer rates |
| Backups | AWS Backup charges if used |
In the US East, AWS pricing currently uses $8 per million DPUs. Storage is billed separately by Region. Confirm current rates on the official Aurora DSQL pricing page.
When a cluster is idle, DPU usage can fall to zero. Stored data still incurs storage charges.
Simple cost formula
For US East:
Practical example
Assume a workload generates 50 million billable DPUs.
This is an illustrative estimate, not a guaranteed AWS bill. DPU consumption depends on workload behavior, so request count alone cannot reliably predict cost.
Aurora DSQL free tier
AWS includes 100,000 DPUs and 1 GB of storage each month at no charge.This can be useful for development, testing, and proof-of-concept workloads before estimating production consumption.
Review the latest limits on the Aurora DSQL pricing page.
Database Savings Plans
Aurora DSQL is eligible for AWS Database Savings Plans.A Database Savings Plan exchanges a one-year commitment to consistent eligible database spend for discounted rates.
Usage above the commitment continues at applicable On-Demand pricing. Underused committed spend can reduce realized savings.
For that reason, the main FinOps question is:
How much eligible database spend remains consistently above the commitment?
The commitment should generally be sized against a durable hourly usage floor rather than peak or average spend.
Read our complete AWS Database Savings Plans guide for eligibility, pricing, and commitment sizing.
For broader commitment mechanics, see our AWS Savings Plans guide.
PostgreSQL compatibility
Aurora DSQL is currently compatible with PostgreSQL 16 and supports many familiar PostgreSQL drivers, ORMs, frameworks, expressions, and data types.However, PostgreSQL-compatible does not mean feature-for-feature identical to Aurora PostgreSQL.
Before migration, validate:
Schema requirements
Required extensions
SQL syntax and functions
Drivers and ORM behavior
Transaction retry handling
Query performance
Migration tooling
Key limits to validate
Transaction retries: Applications should safely retry serialization conflicts and make write operations idempotent.Transaction size: Aurora DSQL currently limits the number of rows that can be modified within a transaction. Verify the current limit before migrating bulk-write workflows.
High-contention rows: Workloads repeatedly modifying the same keys require production-like testing.
Extensions and syntax: Validate every PostgreSQL extension and SQL feature your application needs.
DDL behavior: Test schema deployment workflows because DSQL handles some DDL behavior differently from PostgreSQL.
CDC behavior: Aurora DSQL CDC uses customer-managed Kinesis Data Streams, so include both StreamDPU and Kinesis costs.
Multi-Region architecture
Multi-Region active-active operation is one of Aurora DSQL’s clearest differences from traditional Aurora architectures.A peered multi-Region cluster presents a single logical database with writable Regional endpoints while maintaining strong consistency.
AWS designs Aurora DSQL for:
99.99% single-Region availability
99.999% multi-Region availability
Replicated writes create additional MultiRegionWriteDPU consumption, and storage is billed in each Region containing a replica.
AWS currently supports specific Region combinations, so check current availability before designing a global deployment.
DSQL vs Serverless v2
| Decision area | Aurora DSQL | Aurora Serverless v2 |
|---|---|---|
| Architecture | Distributed serverless SQL | Autoscaling Aurora |
| Billing | DPUs | ACU-hours plus related costs |
| Multi-Region writes | Active-active | Primary-writer architecture |
| PostgreSQL model | Compatible with differences | Aurora PostgreSQL |
| Capacity planning | No instance sizing | Configure ACU range |
| Best fit | Distributed transactional apps | Conventional Aurora workloads |
| Migration | Validate compatibility | Usually easier for Aurora workloads |
Choose Aurora Serverless v2 when automatic scaling is the main goal and maintaining the broader Aurora PostgreSQL environment matters more.
How to evaluate Aurora DSQL
Step 1: Check compatibility
List required PostgreSQL features, extensions, schemas, drivers, and ORM behavior.Step 2: Test write contention
Run production-like concurrent transactions and measure retries.Step 3: Measure DPU usage
Track ComputeDPU, ReadDPU, WriteDPU, MultiRegionWriteDPU, and StreamDPU where applicable.Step 4: Build a baseline
Estimate production cost from measured DPU consumption rather than request count.Step 5: Stress-test usage
Model scenarios where workload volume rises or falls by 25% to 30%.Step 6: Size commitments carefully
If evaluating Database Savings Plans, commit against stable eligible usage rather than temporary peaks.Our AWS Savings Plan buying strategy explains how layering and commitment sizing can reduce overcommitment risk.
Aurora DSQL checklist
Current compatibility documentation reviewed
Production-like queries tested
Transaction contention measured
Transaction limits validated
DPU consumption understood
Storage growth estimated
CDC and Kinesis costs estimated if enabled
Region architecture selected
Usage decline scenario modeled
Database Savings Plan coverage evaluated
Optimizing Aurora DSQL costs
Aurora DSQL changes the cost optimization question.What workload behavior is creating these DPUs?
High ReadDPU may indicate queries reading unnecessary data.
High ComputeDPU can point to expensive joins, functions, aggregations, or inefficient query plans.
High WriteDPU indicates write-heavy workload behavior.
Frequent retries can cause the application to repeat work that never successfully commits.
MultiRegionWriteDPU shows replicated-write activity, while StreamDPU reflects CDC streaming.
FinOps can identify where consumption changed. Engineering can determine which queries, architecture decisions, or workload patterns caused it.
Where Usage.ai fits
Aurora DSQL can sit alongside Aurora, RDS, DynamoDB, DocumentDB, and other services covered by AWS Database Savings Plans. The key question is utilization, since a Database Savings Plan commits you to a fixed hourly spend for one year.That makes commitment planning a portfolio decision, not just a DSQL decision.
At Usage.ai, our Flex Insured Commitment Program helps reduce commitment risk. Eligible workloads can achieve up to 50% savings on covered cloud spend, on average, and eligible Flex Commitments include cashback protection under current program terms.
If you want to review your AWS database spend, commitment exposure, and potential savings using actual billing data, Usage.ai can help.
If you want to review your AWS database spend, commitment exposure, and potential savings using actual billing data, Usage.ai can help.
Frequently asked questions
Is Aurora DSQL serverless?
Yes. Aurora DSQL is a fully managed serverless distributed relational database. Teams do not provision or resize traditional database instances.
How much does Aurora DSQL cost?
Aurora DSQL bills database activity through DPUs plus storage and applicable additional services. AWS currently lists $8 per million DPUs in US East.
What is a DPU?
A Distributed Processing Unit measures work performed by Aurora DSQL, including compute, reads, writes, and certain distributed operations.
Does Aurora DSQL support PostgreSQL?
Yes. Aurora DSQL is PostgreSQL-compatible, currently based around PostgreSQL 16 compatibility. It is not feature-identical to Aurora PostgreSQL, so migration testing is required.
Is DSQL better than Serverless v2?
Neither is universally better. Aurora DSQL is designed for distributed transactional workloads and active-active multi-Region operation. Aurora Serverless v2 is usually a better fit when teams want automatic Aurora capacity scaling without moving to a different distributed database architecture.
