The idea
In DynamoDB you do not join tables, so a common pattern is single table design: store multiple entity types in one table and use generic key names to serve many access patterns.
Generic keys and overloading
The partition and sort keys are named generically, often PK and SK. Different entities pack different meanings into them.
- A user item might use PK as USER#42 and SK as PROFILE.
- An order for that user might use PK as USER#42 and SK as ORDER#1001.
This key overloading groups related items into one item collection so a single query fetches them together.
Designing from access patterns
You start from the queries you need, not the entities. List every access pattern first, then design keys so each pattern is a single Query.
- Use GSIs with overloaded keys to invert relationships and add patterns.
- Use prefixes like ORDER and PROFILE to keep entity types distinct within a collection.
Trade offs
- Pro: fewer round trips, items pre joined, predictable cost.
- Con: rigid model that is hard to change once access patterns shift, and harder for newcomers to read.
Diagram
Key idea
Single table design trades flexibility for performance by modeling from access patterns and overloading keys so related items live in one collection.