DynoTable
Intermediate7 min read

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 — but any one key only ever lands on one partition.

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:

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 modelled 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:

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.

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. Adaptive capacity can move heat between keys; it cannot push a single key past the per-partition ceiling. A true celebrity key still throttles. Sharding is what gets you past that wall.

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

YesNo, many keyssame prefixYesNoThrottling onone key?Single itemtoo hot?Shard the keyor cache the readLow-cardinalitypartition key?Write-shardthe prefixAdaptive capacitylikely handles it

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 and the per-partition ThrottleCount 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).

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.

Pitfalls to avoid

  • Auto-incrementing or monotonic keys. Sequential IDs and timestamps as the partition key route consecutive writes to the same partition. Add a hash prefix.
  • 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.

Updated