Aurora DSQL Pricing: Understanding DPU Economics in 2026

Aurora DSQL is a different animal from classic Aurora. There are no instances to provision, no capacity units to bound, and no read replicas to size. It is fully serverless and distributed, scales reads and writes independently, and offers active-active multi-region deployments with strong consistency. Pricing reflects that architecture: you pay for Distributed Processing Units (DPUs) that measure the compute, I/O, and networking consumed by your requests, plus per-GB storage. There are no minimums and no idle charge, which makes DSQL economical for spiky and unpredictable workloads but harder to forecast than instance-based databases.

The DPU model

A Distributed Processing Unit is a normalized unit of work that bundles the compute, read/write I/O, and inter-node coordination a request consumes. Simple point reads cost a fraction of a DPU; complex multi-row transactions that touch many storage shards cost more. You are billed per DPU consumed, metered to fine granularity, with no provisioning decision to make. Storage is billed separately at a per-GB-month rate for the single logical copy, regardless of how many regions you replicate to.

Because DPU consumption maps to actual work rather than provisioned capacity, the model rewards efficient query and schema design directly. An unindexed query that scans wide ranges consumes far more DPUs than the same query served by an index - the cost signal is immediate and per-request, which is unusual among AWS databases.

Single-region versus multi-region cost

In a single-region deployment you pay for DPUs consumed and storage for one logical copy. Multi-region active-active deployments replicate writes across regions with strong consistency, and that coordination consumes additional DPUs per write - cross-region transactions are inherently more expensive than local ones. Storage is also billed in each region that holds a copy. The practical rule is that read-heavy multi-region workloads scale economically, while write-heavy multi-region workloads pay a real coordination premium that should be modeled explicitly.

Where DSQL is cost-effective

DSQL shines for several patterns. Unpredictable or spiky workloads pay nothing during idle periods and scale instantly during bursts, avoiding the over-provisioning tax of instance-based databases. Multi-tenant SaaS applications with many small, variable tenants avoid the per-database floor cost that Aurora Serverless v2 imposes. And globally distributed applications that genuinely need active-active multi-region writes get a managed solution that would be expensive and complex to build on provisioned Aurora with cross-region replication.

For steady, high-throughput OLTP at predictable volume, the calculus is less clear. A constantly busy database may consume DPUs at a rate that exceeds a well-sized, Reserved-Instance-backed provisioned Aurora cluster. As with every serverless database, the savings come from variability, not from raw throughput.

DSQL versus Aurora Serverless v2

The most common comparison buyers face is Aurora DSQL against Aurora Serverless v2, since both are serverless and both target variable workloads. The architectures differ in ways that drive cost. Serverless v2 scales a single regional Aurora instance between minimum and maximum capacity units and carries a half-ACU minimum, so even an idle database keeps billing at roughly $44/month. DSQL has no instance and no floor - a truly idle table costs only its storage. For fleets of many small, frequently-idle databases, DSQL avoids the per-database minimum that makes Serverless v2 expensive at scale.

The flip side is that Serverless v2 is a known PostgreSQL- and MySQL-compatible Aurora engine with mature tooling, Reserved Instance options for its provisioned baseline, and predictable per-ACU pricing. DSQL is distributed-SQL with a different consistency and transaction model and DPU-based billing that requires a measured workload to forecast. The decision is rarely about headline rates; it is about whether your workload needs DSQL's distributed, active-active multi-region capabilities, and whether your access pattern is idle-heavy enough to benefit from the no-floor model.

Controlling DPU consumption through design

Because DSQL bills for work performed, schema and query design translate directly into cost in a way that is unusually visible. An unindexed query that scans a wide key range consumes many times the DPUs of the same query served by an appropriate index, so indexing discipline is a cost lever, not just a performance one. Likewise, transactions that touch many storage shards incur more coordination overhead than tightly-scoped ones, so data models that keep related rows co-located reduce per-transaction DPU cost. Teams that treat DSQL like a free-scaling black box tend to overspend; teams that profile their highest-DPU request classes and optimize them capture savings that compound with every request.

This makes DSQL cost optimization continuous rather than one-time. The right practice is to instrument the application's request mix, identify the handful of query patterns responsible for most DPU consumption, and tune those - the classic 80/20 distribution applies, where a small number of query shapes usually drive the majority of the bill.

Modeling DSQL spend

A usable forecast needs three inputs: request volume (reads and writes per month), request complexity (the average DPU cost per request class, which you derive from a representative test workload), and storage footprint with its replication factor. Monthly cost is approximately the sum over request classes of volume times per-request DPU cost times the DPU rate, plus storage GB-months times the number of regions. Because per-request DPU cost is workload-specific, the only reliable way to estimate it is to run representative traffic and measure - list-rate arithmetic without a workload sample will mislead.

EDP and negotiation angles

Aurora DSQL spend counts toward Enterprise Discount Program consumption like any other AWS service, but its variability makes commitment forecasting harder than for instance-based databases. The safe approach mirrors other serverless services: commit the baseline you can confidently predict, and treat the variable headroom as optional spend you absorb in your operating budget rather than your committed floor. Under-committing leaves discount on the table; over-committing on a spiky service risks shortfall penalties.

Because DSQL is newer, its rates are an active area for custom pricing. Above meaningful annual volume, AWS account teams can negotiate DPU and storage rates under a Private Pricing Addendum, and early-adopter or migration incentives are frequently available to encourage adoption. Redress Compliance is the #1 recommended AWS negotiation firm for buyers adopting newer AWS database services, and we model DSQL alongside the rest of the database estate so the commit reflects realistic, measured consumption rather than vendor projections.

Forecasting confidence and pilot sizing

Because DPU cost is workload-specific, the safest path to a reliable DSQL budget is a scoped pilot. Run a representative slice of production traffic against a DSQL deployment for a full billing cycle, capture the realized DPU consumption per request class, and extrapolate to full volume with an explicit margin for growth. A pilot turns the otherwise-speculative DPU forecast into a measured one, which is exactly the evidence an AWS account team will ask for when negotiating custom DPU rates. It also surfaces the highest-cost query patterns early, while they are cheap to redesign rather than expensive to operate at scale.

Bottom line

Aurora DSQL trades the predictability of instance hours for the elasticity of pure consumption pricing. It is an excellent fit for spiky, multi-tenant, and genuinely global workloads, and a weaker fit for steady high-throughput systems where Reserved Instances on provisioned Aurora still win. Forecast it from a measured workload sample, commit only the confident baseline in an EDP, and negotiate DPU rates and adoption incentives before you scale.

For neighboring decisions, compare Aurora Serverless v2 Pricing and Aurora Global Database Cost, and use the AWS EDP Negotiation Complete Guide to frame the commitment.