DynamoDB capacity planning cost: on-demand vs provisioned

Quick answer

DynamoDB's core cost decision is capacity mode. On-demand bills per read and write request with zero planning, ideal for spiky, unpredictable, or new workloads, but at a higher per-request rate. Provisioned bills for read and write capacity units you reserve per hour (with autoscaling and reserved-capacity discounts), which is cheaper for steady, predictable traffic if you size it well. Add storage (per GB-month) and optional features. The rule of thumb: on-demand for unpredictable or low-utilization tables, provisioned (with autoscaling) for steady, high-utilization ones where the reserved rate wins.

DynamoDB is priced very differently from a traditional database: you do not pay for an instance, you pay for throughput and storage. And the biggest lever is which capacity mode you choose, on-demand or provisioned, because the same workload can cost very different amounts depending on how predictable it is and how well you size capacity.

The two capacity modes

Aspect	On-demand	Provisioned
Billing	Per read/write request	Per reserved capacity unit per hour
Planning	None, scales automatically	You size RCUs and WCUs
Best for	Spiky, unpredictable, new workloads	Steady, predictable traffic
Per-request rate	Higher	Lower if well-utilized
Discounts	None	Autoscaling, reserved capacity

On-demand charges per request (per read and write) with no capacity to plan, it scales instantly and you pay only for what you use. Provisioned mode has you reserve read capacity units and write capacity units per hour; you pay for that reserved throughput whether or not you use it, but the per-request equivalent is cheaper. Both add storage at per-GB-month rates. This on-demand-versus-reserved tradeoff echoes serverless database pricing generally.

When on-demand is cheaper

On-demand wins when traffic is spiky, unpredictable, or low-utilization. If a table sits mostly idle with occasional bursts, provisioned capacity would sit reserved and wasted most of the time, so paying per request is cheaper. It is also the safe default for new tables whose traffic you cannot yet predict, and for workloads where the operational simplicity of never planning capacity is worth the higher per-request rate. No capacity planning means no risk of throttling from under-provisioning.

When provisioned is cheaper

Provisioned mode wins for steady, predictable, high-utilization traffic. If a table runs at consistent load, reserving the right capacity costs meaningfully less per request than on-demand. Enable autoscaling so provisioned capacity tracks demand within bounds (avoiding both throttling and gross over-provisioning), and for very stable baseline throughput, reserved capacity commitments cut the rate further. The catch is sizing: over-provision and you pay for unused capacity ( waste); under-provision and you throttle. Good monitoring of utilization is what makes provisioned mode pay off.

Getting the decision right

Start new or unpredictable tables on on-demand, watch the utilization, and switch steady, high-usage tables to provisioned with autoscaling once the pattern is clear (you can change modes). Size provisioned capacity to real utilization with autoscaling headroom, add reserved capacity for stable baselines, and keep storage in check by removing unneeded data and using TTL to expire old items. Compare DynamoDB against alternatives like DocumentDB for your access pattern, and price the table configuration before you deploy against the resource catalog so the capacity-mode cost is known up front.

FAQ

Should I use on-demand or provisioned DynamoDB capacity?

Use on-demand for spiky, unpredictable, new, or low-utilization tables, where you pay per request and never plan capacity, at a higher per-request rate. Use provisioned (with autoscaling) for steady, predictable, high-utilization tables, where reserving the right capacity costs meaningfully less per request. You can switch modes as a table's pattern becomes clear, so start unpredictable tables on on-demand and move steady ones to provisioned.

How is DynamoDB cost calculated?

By throughput plus storage, not by instance. On-demand bills per read and write request. Provisioned bills for the read capacity units and write capacity units you reserve per hour, whether or not you use them, at a lower per-request equivalent. Both add storage at per-GB-month rates, plus optional features like global tables, streams, and backups. Capacity mode is the biggest cost lever.

When is on-demand DynamoDB cheaper than provisioned?

When traffic is spiky, unpredictable, or low-utilization. If a table sits mostly idle with occasional bursts, provisioned capacity would sit reserved and wasted most of the time, so paying per request is cheaper. On-demand is also the safe default for new tables whose traffic you cannot predict, and where the simplicity of never planning capacity (and no throttling risk) is worth the higher per-request rate.

How do I reduce DynamoDB provisioned capacity cost?

Enable autoscaling so provisioned capacity tracks demand within bounds, avoiding both throttling and gross over-provisioning, size capacity to real utilization rather than peak, and for stable baseline throughput buy reserved capacity to cut the rate further. Monitor utilization closely, since over-provisioning wastes money on unused capacity and under-provisioning causes throttling. Also use TTL to expire old items and reduce storage cost.

Can I switch DynamoDB capacity modes?

Yes. You can change a table between on-demand and provisioned modes (with some frequency limits). A common pattern is to start a new or unpredictable table on on-demand, watch its utilization, and switch it to provisioned with autoscaling once the traffic pattern is steady and predictable enough that reserving capacity is cheaper. This lets you match capacity mode to the workload as it matures.

How does C3X help with DynamoDB capacity cost?

C3X prices DynamoDB tables and their capacity configuration from your Terraform before deploy, so the cost of on-demand versus provisioned capacity, and the sizing of provisioned throughput, is visible in the pull request. Seeing the capacity-mode cost at design time helps you choose the right mode and size it appropriately before an over-provisioned or mismatched table ships.

What to do next

Price your DynamoDB capacity choice before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.