← Lessons

quiz vs the machine

Gold1420

Databases

DynamoDB Partition Key Design

Your partition key choice decides whether load spreads evenly or melts one shard.

5 min read · core · beat Gold to climb

The Key That Places Data

In DynamoDB every item has a partition key. Its hash decides which internal partition stores the item. An optional sort key orders items within a partition. The partition key choice is the single biggest factor in performance because it controls how traffic spreads.

Hot Partitions

If many requests target one partition key value, that partition takes disproportionate load while others idle. This is a hot partition, and it can throttle requests even when total capacity looks sufficient. A low cardinality key such as a status flag is a classic mistake.

Designing for Even Spread

  • Pick a key with high cardinality and uniform access, like a user id.
  • Add a suffix or shard number to a hot value to split it across partitions, then query all shards.
  • Use a composite key so the sort key carries the access pattern while the partition key spreads load.

Single Table Design

DynamoDB often stores many entity types in one table, encoding access patterns into key prefixes so related items share a partition and can be fetched together.

Key idea

The partition key determines where each item lives, so a high cardinality evenly accessed key spreads traffic while a low cardinality key creates hot partitions that throttle.

Check yourself

Answer to earn rating on the learn ladder.

1. What does the partition key control in DynamoDB?

2. Why is a low cardinality partition key risky?

3. How can you spread a naturally hot key value across partitions?