DynamoDB Hot Partitions

DynamoDB spreads your data across many physical partitions, each with its own
slice of throughput. A hot partition is when one key draws far more reads or
writes than its slice can serve — so requests to that key throttle while the rest
of the table sits idle.

What is a DynamoDB hot partition?

A DynamoDB hot partition is when one partition key absorbs far more reads or writes than its slice of throughput can serve, so requests to that key throttle while the rest of the table sits idle. The cause is key design — a celebrity item, a low-cardinality key, today's date — not table size. The cure is spreading writes.

• The cause is key design, not table size. One partition key concentrating traffic — a celebrity user, a status="OPEN" flag, today's date — is the trap.
• Adaptive capacity helps, but it isn't a fix. DynamoDB rebalances heat automatically, yet a single item or single key can still exceed what one partition can serve.
• The cure is spreading writes. Add entropy to the key (write sharding) or move the hot read path onto a better-distributed access pattern.
• Coming from SQL, this has no equivalent. A relational table has no notion of "one row's index value is too popular" — DynamoDB's flat throughput-per-key model does.

Why partitions exist at all

DynamoDB is the production heir of the 2007 Amazon Dynamo paper, which traded the
single-node SQL model for a partitioned, horizontally-scaled one. Data is sharded
by a hash of the partition key across physical storage nodes.

Each partition holds a bounded amount of data and serves a bounded amount of
throughput. AWS documents a hard ceiling of 3,000 read units and 1,000 write
units per partition, per second
(AWS — partition behavior).

That ceiling is the whole story. Your table's provisioned throughput is the sum
across all partitions. A key's item collection starts on one partition and
split-for-heat can carve it across several at sort-key boundaries — unless the table
has an LSI or the sort key is ever-increasing, which pins it to one.

Name the trap: traffic that piles on one key

Throughput is shared evenly only if your access is spread evenly across keys.
The moment one key gets disproportionate traffic, it throttles alone while the
table's overall capacity goes unused.

Classic hot-key shapes:

• A celebrity item — one user, product, or tenant that everyone reads.
• A low-cardinality partition key — status, country, type. Few distinct values means few partitions doing all the work.
• A time-bucketed key — PK = "2026-06-23". Every write today hammers one partition; yesterday's is cold forever.

Coming from SQL, none of these would matter. A B-tree index on a popular value is
fine. In DynamoDB the popular value is the unit of physical placement, so
popularity becomes a throughput cliff.

A worked example: the celebrity leaderboard

Say you run a global gaming leaderboard. Scores live in a table keyed like this:

Example	Notes
PK = "BOARD#global"
SK = "PLAYER#<playerId>"

Reads grab the top N by score; writes bump a player's currentScore after each
match. Every row in the global board shares one partition key — BOARD#global
— so every read and write lands on a single partition.

Add a streamer with two million live viewers spamming the refresh button on their
own rank, and that one partition tips past 3,000 read units. You get
ProvisionedThroughputExceededException on the global board while every other
board in the table is idle.

The footgun is the BOARD#global collapse: you modeled a single logical board as a
single physical key.

Spread the writes: sharding the key

The fix is to manufacture cardinality. Append a shard suffix to the partition
key so one logical board fans out across N physical partitions:

Example	Notes
PK = "BOARD#global#<shard>"	shard = playerId mod 10
SK = "PLAYER#<playerId>"

Writes now scatter across ten partitions instead of one — ten times the write
headroom. The cost: a read of the whole board must hit all ten shards and merge,
because no single Query spans shard boundaries. You trade read simplicity for
write distribution.

See the difference for yourself. Paste a single repeated key into the visualizer
below and every write lands in one bucket — the hot partition. Add a shard suffix
(BOARD#global#0 … #9) and the same writes fan out evenly:

This is a teaching hash for intuition, not DynamoDB's real internal hash — the
real function and partition boundaries are AWS internals. Read it as "even spread
vs skew", not as a prediction of which physical partition a key lands on.

AWS calls this write sharding and recommends it precisely for high-velocity,
low-cardinality keys
(AWS — using write sharding).

This is the same key-overloading instinct behind
single-table design — you shape the key for the
access pattern, not for how the data "naturally" sits.

Let adaptive capacity do the easy part

DynamoDB ships adaptive capacity, covered in the re:Invent 2018 session
"Amazon DynamoDB Under the Hood" (DAT401). It continuously redistributes a table's
throughput toward the partitions taking heat, and will isolate a persistently
hot key onto its own partition (key-level isolation,
AWS — bursting & adaptive capacity).

It's instant and free — but it's bounded by physics
(how adaptive capacity works). Adaptive capacity can move
heat between keys, and split-for-heat can even split a hot item collection at a
sort-key boundary. The per-partition ceiling stays absolute only for a single hot
item, an ever-increasing sort key, or a table with an LSI — where a celebrity key
still throttles. Sharding is the deterministic fix; split-for-heat is slow and
opportunistic, so don't wait on it.

Here's the decision path once you see throttles on a busy key:

Most hot partitions resolve to either "shard the key" or "let adaptive capacity
absorb it" — the diagram is just which branch you're on.

Diagnose it before you redesign

You can't fix what you can't see. Throttling shows up as
ProvisionedThroughputExceededException (provisioned) or as
ThrottledRequests, ReadThrottleEvents/WriteThrottleEvents, and
ReadThrottleEventsForKeyRange/WriteThrottleEventsForKeyRange — the
partition-limit-specific counts — in CloudWatch
(AWS — CloudWatch metrics).

Pair that with CloudWatch Contributor Insights for DynamoDB, which ranks your
most-accessed keys directly — the fastest way to confirm a celebrity key by name
(AWS — Contributor Insights).
And if you're not yet sure a hot key is the cause at all — DynamoDB throttles for
four distinct reasons — start from
the throttling guide and let the metrics name the
limit you actually hit.

When you're testing the sharded read path, you'll be hand-building the
KeyConditionExpression for each shard. Generate those without typos with the
DynamoDB Expression Builder — it emits the
exact PK = :pk AND begins_with(SK, :sk) shape per shard.

Warning

On-demand tables are not immune. They auto-scale capacity, but the per-partition
ceiling still applies — a single celebrity key throttles on on-demand exactly as
it does on provisioned. Billing mode is not a hot-partition fix.

Pitfalls to avoid

• Ever-increasing sort keys. A monotonic sort key (a timestamp, a sequence number) forces every new write into the same end of one item collection, and split-for-heat can't help — the collection stays capped at 1,000 write units. Add entropy to the sort key or shard the partition key.
• Sharding the read-heavy path needlessly. If reads dominate and the item is small, a cache or a GSI with a better-distributed key often beats sharding's scatter-gather read cost.
• Confusing a hot partition with a slow Scan. A Scan is slow because it reads everything; a hot partition throttles because one key is overloaded. Different problems — see Query vs Scan.

Next steps

Sketch the sharded keys, then prove the read path against real data. Build the
per-shard conditions in the
DynamoDB Expression Builder, and
download DynoTable to run them against your own tables and watch which
partitions actually take the heat.