DynoTable

DynamoDB throttled on a hot partition despite capacity

TL;DR — Your table has plenty of unused RCU/WCU overall, but you're still throttled because a single partition key is hot. Every physical partition is designed to deliver a maximum of 3,000 read units and 1,000 write units per second, regardless of how much capacity the table has. Traffic piled onto one key exhausts that one partition. Spread requests across more distinct partition keys (write-sharding) to fix it.

What it means

ProvisionedThroughputExceededException: You exceeded your maximum allowed
provisioned throughput for a table or for one or more global secondary indexes.
# ...yet CloudWatch shows consumed capacity well below provisioned.

DynamoDB spreads a table across many physical partitions, and a table's capacity is divided among them. An individual partition is designed to deliver at most 3,000 read units and 1,000 write units per second — in both capacity modes. If your access pattern focuses traffic on one partition key, that key's partition hits its own ceiling and throttles — even though the table-wide metrics look under-utilized (the error's ThrottlingReason fields, e.g. TableReadKeyRangeThroughputExceeded, name the exact limit that was hit). Adaptive capacity helps, but it can't rescue a genuinely unbalanced key.

Why it happens

  • Low-cardinality partition key — a status flag, a boolean, a "current date", or a single tenant that receives most traffic.
  • A viral / celebrity item — one popular partition key (a trending product, a hot user) draws disproportionate load.
  • Time-series with a "today" key — every write lands on the same date-based partition key.
  • A sequential or monotonic key so writes cluster on the newest partition.
  • A GSI with a low-cardinality partition key, which throttles the base table's writes.

How to fix it

  1. Increase key cardinality. Design the partition key so requests spread across many values — this is the single most effective fix.
  2. Write-shard the hot key. Append a suffix (USER#42#1…USER#42#N) so one logical entity spans multiple partitions; fan out reads across the shards.
  3. Add randomness or a calculated suffix to time-series keys so "today's" writes don't all collide.
  4. Cache hot reads (DAX or an application cache) to shed read pressure off the hot partition.
  5. Keep exponential-backoff retries — this error is retryable and the SDK backs off by default.
  6. Fix low-cardinality GSI keys — a throttled GSI throttles the base table.
  7. Check ThrottlingReason in the error. It names whether the limit was table-wide or key-range specific.

Check size in DynoTable

Find the hot partition key — open the table with ⌘K, sort by partition key, and look for one key carrying far more items than neighbors. Filter to that key and inspect write patterns before you re-shard.

Model write-shard suffixes in the Query Builder and estimate retry traffic with the pricing calculator. Switch profiles with ⌘P; see Connect to AWS and Install.

Sources

FAQ

Why is DynamoDB throttling me when the table has spare capacity? Because a single partition key is hot. Every physical partition has a ceiling of about 3,000 read units and 1,000 write units per second regardless of table-level capacity, so traffic piled onto one key exhausts that one partition while table-wide metrics look under-utilized.

How do I fix a hot partition in DynamoDB? Increase partition-key cardinality so requests spread across many values, write-shard the hot key with a suffix, add a calculated suffix to time-series keys, and cache hot reads. Exponential-backoff retries help ride out short spikes but don't fix an unbalanced key.

References

Last verified 2026-07-13 against the official AWS documentation linked above.

Work with DynamoDB without the Console

A fast DynamoDB desktop client that runs the real SQL DynamoDB can’t — JOINs, GROUP BY, aggregates — with visual editing and an AI agent on your own Bedrock keys.

DownloadSee pricing

Free 30-day trial, no credit card — then the Free plan with no time limit.