DynamoDB on demand and provisioned are not a price tier choice, they are a bet on how predictable your traffic is: provisioned is much cheaper per request when throughput is steady and you keep the capacity busy, while on demand is cheaper overall when traffic is spiky, bursty, or idle between peaks. The practical rule is to launch new or unpredictable tables on on demand to learn their shape, then move steady high volume tables to provisioned with autoscaling and reserved capacity, which together can cut the per request cost dramatically. The expensive mistake is leaving a large, predictable, always busy table on on demand for convenience, paying a premium per request for flexibility it never uses.
Here is how each mode bills, where the break even sits, and how to decide table by table.
How does each capacity mode bill?
Provisioned capacity charges for read capacity units and write capacity units you allocate per hour, whether or not you use them, with autoscaling adjusting the allocation between floors and ceilings you set. You pay for capacity; the discipline is keeping it utilized. On demand charges per read and per write request with no capacity to manage, scaling instantly to any traffic level. You pay for usage; the premium is a higher per request price in exchange for zero idle risk. The two meters mean a steady table that runs capacity near fully utilized is far cheaper provisioned, while a table that sits near idle then spikes hard is far cheaper on demand, because provisioned would either starve during the spike or waste capacity the rest of the time.
Where is the break even?
| Traffic shape | Cheaper mode | Why |
|---|---|---|
| Steady, predictable, high utilization | Provisioned with autoscaling | Capacity stays busy, lowest per request cost, reserved capacity applies |
| Spiky or bursty, idle between peaks | On demand | No idle capacity to pay for, instant scale to the peak |
| New table, unknown pattern | On demand first | Learn the shape with no capacity risk, then switch |
| Near zero baseline, rare use | On demand | Pay per request, nothing when quiet |
As a rough guide, a table whose provisioned capacity would run consistently busy tends to favour provisioned once utilization is high, while genuinely unpredictable traffic favours on demand. Confirm against your own request patterns and current DynamoDB pricing; these thresholds are indicative.
How do you decide table by table?
Do not pick one mode for the whole account. Profile each table's request pattern over a representative period and classify it. Steady, high volume tables move to provisioned with autoscaling, the floor set to the reliable baseline and the ceiling to the real peak, then their steady baseline is covered with reserved capacity for a one or three year term. Genuinely spiky tables stay on on demand, where you accept the per request premium because the alternative is wasted provisioned capacity or throttling. New tables start on on demand until the pattern is clear, then switch, remembering the one switch per 24 hour limit. The result is a portfolio where each table is in the mode its traffic actually justifies, rather than one default applied everywhere.
A worked example
A scaling fintech had put every DynamoDB table on on demand at launch for simplicity and never revisited it. Profiling showed a handful of core tables carried steady, high volume, around the clock traffic, and these accounted for most of the DynamoDB bill while paying the on demand per request premium continuously. We moved those steady tables to provisioned with tight autoscaling and covered their baseline with reserved capacity, while leaving the long tail of genuinely spiky tables on on demand. The per request cost on the core tables fell sharply, and the spiky tables kept their flexibility, cutting total DynamoDB spend as part of the program that left the company 41 percent lighter on cloud spend. Figures are verified against billing data and anonymised.
Frequently asked questions
Is DynamoDB on demand or provisioned cheaper?
Can you switch DynamoDB between on demand and provisioned?
Do reserved capacity discounts apply to DynamoDB?
Put each table in the right mode
We profile DynamoDB and data layer spend and move each table to the capacity mode its traffic justifies, as an independent advisory that takes zero provider commissions and answers only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or a no risk Gainshare basis. Download the cloud cost optimization playbook, read the deeper AWS cost optimization guide, and pair it with RDS Reserved Instances explained.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.