Provisioned RDS bills per instance-hour and rewards steady load, especially with reserved pricing. Aurora Serverless v2 bills per ACU-second and fits variable load that rarely sits fully idle. DynamoDB on-demand bills per request and wins on spiky traffic with a low average. Match your traffic curve to the cost shape, not to the marketing page.
What are the three cost shapes?
Provisioned RDS charges for capacity by the instance-hour, whether you use it or not. Aurora Serverless v2 charges per ACU-second, an Aurora Capacity Unit being a slice of compute and memory, scaling between a floor and a ceiling you set. DynamoDB on-demand charges per request, with no capacity concept at all.
Every conclusion in this comparison follows from those units. An hourly instance is a fixed cost with a hard performance ceiling. ACU-seconds track your load curve, within limits we detail below. Per-request billing tracks usage exactly: zero requests, zero throughput cost, storage aside. Rates move over time, shapes rarely do, so we link the official Aurora pricing and DynamoDB pricing pages instead of quoting figures that would age badly.
Why does Aurora Serverless v2 have an idle cost floor?
Because the minimum ACU you configure never sleeps by default. Aurora Serverless v2 scales down to its floor, not to nothing, so a cluster that idles all weekend still bills its minimum capacity every second of it. Serverless here means elastic within a range, not pay-per-use.
The floor exists for a reason: minimum capacity keeps the buffer pool warm and absorbs the first seconds of a spike while scaling catches up. Set it too low and the opening requests of every burst pay in latency; set it too high and you have bought a provisioned instance with extra steps. The capacity range is the one tuning decision this model asks of you, and the capacity settings documentation explains how the two bounds interact with scaling speed.
What changed with scale-to-zero in 2024?
Since late 2024, Aurora Serverless v2 can pause to zero ACUs: set the minimum to 0 and compute suspends after a configurable idle period. Storage keeps billing, and the first connection after a pause waits for a resume, on the order of fifteen seconds, sometimes longer.
That trade-off is excellent for development, staging, and internal tools that sit idle most of the day, and usually wrong for a production API with a latency budget. Support depends on engine versions, and resume times vary with workload, so verify the specifics in the current documentation rather than assume them. What matters for cost reasoning: if auto-pause is acceptable, Aurora's idle floor drops to storage only, which moves its break-even against DynamoDB for rarely touched relational data.
Not sure which cost shape your weekly traffic curve actually fits? Describe your system: a one-page diagnosis within 48 hours.
Get my diagnosis →When does provisioned RDS with reserved pricing win?
When utilization is high and predictable. A provisioned instance is the cheapest way to buy capacity you actually use around the clock, and reserved instances discount it further against one- or three-year commitments. Steady load is exactly what the hourly shape was priced for.
The break-even is a ratio, not a dollar figure. Take the hourly cost of the ACUs your workload averages, divide it by the hourly cost of a provisioned instance with equivalent memory: serverless capacity carries a per-unit premium, so above some average utilization the provisioned instance wins, and reserved pricing pushes that threshold lower still. Run the ratio with current rates from the pricing pages linked above; arithmetic in blog posts ages badly, ours included.
When does DynamoDB on-demand win?
When traffic is spiky and the average is low. Per-request pricing means an idle table costs storage only, and bursts are absorbed without capacity planning. With a high peak-to-average ratio, both relational shapes force a choice: pay for the peak, or queue behind a floor sized for the average.
Two caveats. First, on-demand request rates were cut substantially in late 2024, which moved the break-even in DynamoDB's favor for many spiky workloads; trust the current pricing page over older comparisons. Second, none of this matters if your access patterns do not fit DynamoDB's model. We covered that decision in our DynamoDB vs RDS guide for serverless backends; this article assumes the modeling question is settled and only the bill is in dispute.
Which cost shape fits which traffic profile?
Idle cost and spike behavior are the discriminators. Provisioned RDS wins on steady, high-utilization load. Aurora Serverless v2 wins on variable relational load with a real baseline. DynamoDB on-demand wins on spiky, low-average traffic where the data model fits. The table compresses the whole comparison into five rows.
| Aurora Serverless v2 | Provisioned RDS | DynamoDB on-demand | |
|---|---|---|---|
| Pricing unit | ACU-second | Instance-hour | Per request, plus storage |
| Idle cost | Minimum ACU floor (storage only if auto-pause is acceptable) | Full instance rate, always | Storage only |
| Spike behavior | Scales in seconds, up to the ACU ceiling | Fixed ceiling; growing means resizing or adding replicas | Absorbed per request, within table limits |
| Ops load | Low: one capacity range to tune | Highest: sizing, scaling events, maintenance windows | Lowest: no capacity to manage |
| When it wins | Variable relational load with a real baseline | Steady high utilization, reserved commitment | Spiky, low-average traffic that fits the model |
Read the columns as defaults, not verdicts: a hybrid (a provisioned writer with serverless readers in the same cluster, or DynamoDB beside a relational core) is often the honest answer.
The decision checklist
Five questions before you commit:
- Plot a week of traffic. Flat curve at high utilization: provisioned RDS, then price the reserved commitment.
- Variable curve with a steady baseline: Aurora Serverless v2, floor sized for the baseline, ceiling for the worst spike.
- Spiky with a low average, and the access patterns fit: DynamoDB on-demand.
- Idle environments (dev, staging, internal tools): Aurora with auto-pause, if a cold resume is acceptable.
- Whatever you pick, redo the ratio math against today's pricing pages, not last year's posts.
Real traffic is rarely as clean as the table. Our AWS architecture practice starts every engagement by drawing your curve before naming a database.