One Table for Everything
In DynamoDB a common advanced pattern is single table design, where many different entity types live in one table rather than one table per entity. Users, orders, and order items all share a table, distinguished by how their keys are structured.
Partition Key and Sort Key
- The partition key groups related items together on the same partition.
- The sort key orders items within a partition and lets you fetch ranges.
- By giving a user and that user orders the same partition key, one query returns the user and all their orders together.
Overloaded Keys
Single table design relies on overloaded keys, where the same key attributes hold different meanings for different entity types. A partition key might hold USER hash 42 for a profile item and the same value for related order items, with the sort key separating PROFILE from ORDER entries.
Why Do This
- Fetching a parent and its children becomes one query instead of several.
- You avoid cross table joins, which DynamoDB does not support.
- It keeps requests and cost predictable at scale.
The Cost
The design is hard to read and evolve. You must know all access patterns up front, and adding a new query later can mean reshaping keys or adding secondary indexes.
Key idea
Single table design colocates many entity types under shared partition keys so related items are fetched in one query, at the cost of upfront access pattern planning.