Understanding Partition Keys

What Is a Partition Key?

In DynamoDB, every item (row) must have a primary key — it uniquely identifies that item in a table.

The Partition Key (also called Hash Key) decides where the item is stored inside DynamoDB's internal partitions.

How DynamoDB Uses It

When you insert or fetch data:

• DynamoDB uses the Partition Key value to compute a hash.
• That hash decides which internal partition the item lives in.
• Items with the same Partition Key are always stored together.

Types of Primary Keys

DynamoDB supports two primary key patterns.

Simple Primary Key (only Partition Key)

Uses one attribute to uniquely identify an item.

Example:

• Partition Key: Name
• Every Pokémon's name is unique → Each item = one Pokémon.

Use Case: Perfect when each Pokémon is unique and can be fetched directly by name:

{
  TableName: "FirstGenPokemon",
  Key: { Name: "Pikachu" }
}

Composite Primary Key (Partition + Sort Key)

Uses two attributes together for uniqueness.

The following is a small teaching example. Type1 has very few possible values, so a large production workload could concentrate traffic on hot keys. Start from real access patterns and choose a high-cardinality, evenly used partition key—or add a deliberate shard when one logical group receives heavy traffic.

Toy example:

• Partition Key: Type1
• Sort Key: Name
• This way, Pokémon of the same type are grouped together.

Use Case: Quickly find all Pokémon of a specific type, sorted alphabetically:

{
  TableName: "FirstGenPokemon",
  KeyConditionExpression: "Type1 = :type",
  ExpressionAttributeValues: { ":type": "fire" }
}