DynamoDB adaptive capacity
DynamoDB spreads your table across partitions, but your traffic rarely spreads evenly. Burst capacity and adaptive capacity are the two automatic mechanisms that stop a skewed workload from throttling — until it hits a hard limit.
What is DynamoDB adaptive capacity?
DynamoDB adaptive capacity is an automatic mechanism that shifts unused throughput toward a so a skewed key doesn't throttle while the rest of the table sits idle. Paired with burst capacity, it absorbs spikes and sustained skew for free — but it can't push a single key past the partition ceiling.
- Burst capacity lends you up to 5 minutes (300 seconds) of unused throughput to ride out short spikes. It's a buffer, not a feature you tune.
- Adaptive capacity automatically raises throughput for a — drawing from the rest of your table's unused capacity — so a skewed key doesn't throttle.
- It will even isolate a hot item onto its own partition, giving a single key up to the partition ceiling of 3,000 RCU / 1,000 WCU.
- It is not a license to ignore key design. Past the per-partition ceiling there is nowhere left to borrow — a truly hot key still throttles.
Know the partition ceiling first
Every partition is independently capped: 3,000 read units and 1,000 write units per second. That limit is physical, not provisioned — it holds on both provisioned and on-demand tables. (AWS, Burst and adaptive capacity.)
Coming from SQL, you reason about total server load. In DynamoDB the unit that throttles is the single partition, and one skewed key can melt down while the table sits 90% idle. That's the gap both mechanisms exist to close.
Burst capacity absorbs the short spike
Whenever you don't fully use a partition's throughput, DynamoDB banks the leftover. Up to 300 seconds of that unused capacity is held in reserve, and a sudden burst can drain it faster than your per-second rate would normally allow.
It's invisible and automatic. You can't size it, and DynamoDB may quietly spend some of it on its own background work. Treat it as a cushion for bursty traffic — never as headroom you can plan against.
Adaptive capacity boosts the hot partition
Burst capacity handles short spikes. Adaptive capacity handles sustained skew. When one partition runs hot while its neighbors idle, DynamoDB shifts throughput toward the hot one — up to the table total and the partition ceiling.
Say you run a fleet-telemetry table keyed VEHICLE#<id> (partition) and TS#<epoch> (sort). One delivery van in a flash-sale zone emits 10× the pings of any other. Its partition is hot; the other 200 vans' partitions sit nearly idle.
Adaptive capacity notices and lifts that one partition's throughput, drawing from the unused capacity of the cold partitions. No config, no cost, no warm-up — since May 2019 the boost is effectively instant. (AWS Database Blog, "How DynamoDB adaptive capacity accommodates uneven access patterns".)
The hot van's partition needs 150 WCU but its 100-WCU even share would throttle; adaptive capacity borrows the idle WCU from the cold partitions to cover it.
Isolation: when one item is the problem
Skew isn't always per-key — sometimes a single item is white-hot. If relentless traffic drives one VEHICLE#HOT item, DynamoDB's split-for-heat rebalances partitions so that the frequently accessed item lands alone.
Once isolated, that single item's key can pull the full partition ceiling: 3,000 RCU and 1,000 WCU. That's the absolute roof for one key — there is no mechanism above it. (AWS, Key range throughput exceeded.)
One caveat worth pinning: adaptive capacity won't split an across partitions when the table has a . An LSI binds the collection to one partition — see GSI vs LSI for why.
When adaptive capacity can't save you
This is the trap. Both mechanisms move throughput around; neither creates more than a partition physically allows.
| Scenario | Burst | Adaptive | Outcome |
|---|---|---|---|
| Short spike, table has slack | Covers it | — | No throttle |
| Sustained skew, cold neighbors | — | Boosts hot | No throttle |
| One item, < 3K RCU / 1K WCU | — | Isolates it | No throttle |
| One item, > partition ceiling | Drained fast | At the roof | Throttled — redesign needed |
| Many keys hot at once, table maxed | Drained fast | Nothing idle | Throttled — redesign needed |
If a single key legitimately needs more than 1,000 writes a second, no automatic mechanism rescues you — you must spread the load across more keys.
Write sharding is the usual fix: append a suffix (VEHICLE#HOT#0 … #9) so writes fan out across partitions, then fan reads back in.
That fan-in is itself an access pattern to model deliberately, the same way you'd plan a query path in single-table design — adaptive capacity buys time, not a free pass on key design.
See it on your own table
Adaptive capacity is invisible by design, so you reason about it through one symptom: which keys are hot. When you build the sharded write path, the Expression Builder generates the PutItem and Query syntax for a suffixed key.
To watch how a key actually distributes across your data, download DynoTable and inspect the partition spread on your real tables before you assume adaptive capacity has it covered. For the read side of skew, see Query vs Scan.