DynamoDB on-demand vs provisioned: which costs less

Quick answer

DynamoDB on-demand charges per read and write request with no capacity planning, while provisioned charges for reserved read and write capacity units per hour. On-demand is cheaper for spiky, unpredictable, or low traffic; provisioned is cheaper for steady, predictable, high-volume workloads, often by a wide margin when capacity stays well utilized. As a rule of thumb, per-request on-demand pricing runs several times the equivalent provisioned rate, so once traffic is predictable enough to keep provisioned capacity busy, provisioned wins. Auto scaling and reserved capacity narrow the gap further for provisioned tables.

DynamoDB has two capacity modes, and picking the wrong one can multiply your table cost. On-demand mode charges for each read and write request with no planning required. Provisioned mode charges for reserved read capacity units (RCUs) and write capacity units (WCUs) by the hour, whether you use them or not. The cheaper option depends almost entirely on how predictable your traffic is.

How each mode bills

Mode	You pay for	Best when
On-demand	Each read and write request	Spiky, unpredictable, or low traffic
Provisioned	Reserved RCUs and WCUs per hour	Steady, predictable, high volume

On-demand removes all planning: you never think about capacity, and idle tables cost almost nothing beyond storage. But the per-request rate is high, roughly several times the effective per-request cost of provisioned capacity that is kept busy. Provisioned is cheaper per unit of work, but you pay for the capacity around the clock, so underused capacity is waste. That tradeoff is the whole decision.

When on-demand wins

On-demand is the better deal when traffic is spiky or unpredictable (you would have to over-provision to handle peaks), when volume is low (the reserved capacity would sit mostly idle), for new tables where you do not yet know the load, and for dev and test tables that see sporadic use. In all these cases provisioned capacity would spend most of its time underutilized, and paying per request is genuinely cheaper. On-demand is also the safe default because it cannot throttle from under-provisioning.

When provisioned wins

Provisioned wins for steady, predictable, high-volume workloads where you can keep the reserved capacity highly utilized. When a table runs at consistent throughput, provisioned capacity costs a fraction of the equivalent on-demand bill. Add auto scaling to track daily patterns without over-provisioning for peaks, and buy reserved capacity (a one or three year commitment) for a further large discount on baseline throughput. A busy production table on well-tuned provisioned capacity is often several times cheaper than the same table on-demand.

A practical decision rule

Start new or uncertain tables on-demand so you never throttle and pay only for real usage. Once a table's traffic becomes predictable and its volume is high enough that provisioned capacity would stay well utilized (say above roughly half utilization most of the time), switch it to provisioned with auto scaling. You can change modes (subject to a cooldown), so this is not a one-way door. Watch the same hidden costs that appear across AWS: storage, backups, global tables replication, and streams all bill separately from throughput. See hidden AWS costs to watch for the full list.

Don't forget storage and extras

Capacity mode only governs throughput. DynamoDB also charges for stored data per GB per month, for backups (on-demand and continuous), for global table replication (write capacity in every replica region plus cross-region transfer), and for DynamoDB Streams reads. These are the same category of line items that surprise people on their first AWS bill, and they do not change with capacity mode. Model the whole table cost, not just the RCUs and WCUs, when you compare. For the broader picture of AWS request-based pricing, see how it compares to running a Postgres database on AWS.

FAQ

Is DynamoDB on-demand more expensive than provisioned?

Per request, yes: on-demand pricing runs several times the effective per-request cost of provisioned capacity that stays busy. But on-demand only charges for requests you actually make, so for spiky, low, or unpredictable traffic it is cheaper overall because provisioned capacity would sit mostly idle. Provisioned is cheaper only when you can keep the reserved capacity highly utilized.

When should I use DynamoDB on-demand mode?

Use on-demand for spiky or unpredictable traffic (where you would have to over-provision for peaks), for low-volume tables (where reserved capacity would sit idle), for new tables where you do not yet know the load, and for dev and test tables with sporadic use. On-demand also never throttles from under-provisioning, making it the safe default until traffic becomes predictable.

When is provisioned capacity cheaper?

Provisioned is cheaper for steady, predictable, high-volume workloads where the reserved capacity stays well utilized, roughly above half utilization most of the time. At consistent throughput, provisioned can cost a fraction of the on-demand bill. Add auto scaling to follow daily patterns and reserved capacity commitments for a further discount on baseline throughput.

Can I switch between DynamoDB capacity modes?

Yes. You can change a table between on-demand and provisioned mode, subject to a cooldown period between switches. This means you can start a new or uncertain table on-demand, observe its real traffic pattern, and switch it to provisioned once the load is predictable and high enough to keep reserved capacity utilized. It is not a permanent decision.

What is DynamoDB reserved capacity?

Reserved capacity is a one or three year commitment to a baseline amount of provisioned read and write capacity in exchange for a significant discount versus standard provisioned rates. It applies only to provisioned mode and only to your steady baseline throughput. It stacks with auto scaling: reserve the baseline and let auto scaling handle the variable portion above it.

Does capacity mode affect DynamoDB storage cost?

No. Capacity mode governs only throughput (reads and writes). Stored data is billed per GB per month regardless of mode, and backups, global table replication, and DynamoDB Streams all bill separately too. When comparing modes, model the whole table cost including storage and extras, not just the throughput line, so the comparison reflects the real bill.

What to do next

Model your DynamoDB cost before you deploy the table. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.