How DynamoDB Physically Stores Data
Imagine DynamoDB as a city with thousands of warehouses. When you store an item, DynamoDB runs your Partition Key through a hash function — like a GPS coordinate calculator — to determine which warehouse the item goes to. Inside that warehouse, items are arranged alphabetically by Sort Key on shelves. When you retrieve data, you go directly to the right warehouse (via the hash) and then walk along the sorted shelves to find exactly what you need.
This physical layout is not an abstraction — it directly determines what queries are fast and what queries are impossible.
1. Partition Key (PK)
The Partition Key is the routing mechanism. DynamoDB applies a deterministic hash function to this value to identify the physical partition (a storage node) where the item lives.
Critical constraints:
- You can only query with an exact match: PK = "USER#123". Range queries (PK > "USER#100") are not supported.
- All items with the same PK are stored on the same physical node. This is both a feature (fast co-located reads) and a risk (hot partitions, covered later).
- Maximum item size is 400 KB. Maximum partition throughput is 3,000 RCUs and 1,000 WCUs per second.
Naming convention: Prefix your keys with the entity type (USER#, ORDER#, PRODUCT#). This prevents accidental key collisions between different entity types and makes the data self-documenting.
2. Sort Key (SK)
The Sort Key is the organizer. Within a single Partition Key, all items are physically sorted on disk by this value in lexicographic (alphabetical) order.
What this enables:
- Range queries: SK between "ORDER#2024-01-01" and "ORDER#2024-12-31"
- Prefix queries: SK begins_with "ORDER#"
- Comparison queries: SK > "ORDER#2024-06-01"
Item Collection: All items sharing the same Partition Key form an Item Collection. This is DynamoDB's native mechanism for modeling one-to-many relationships. An Item Collection has a maximum size of 10 GB — a limit that matters for tables with Local Secondary Indexes (LSIs).
Composite Primary Key in Practice
The combination of PK + SK must be globally unique across the table. This lets you store multiple entity types in the same table:
PK: USER#123 SK: PROFILE → User metadata
PK: USER#123 SK: ORDER#2024-001 → An order belonging to this user
PK: USER#123 SK: ORDER#2024-002 → Another order
PK: USER#123 SK: ADDRESS#home → A saved address
A single Query on PK = "USER#123" retrieves all four items in one network round trip. This is the foundation of single-table design.