DynamoDB Single-Table Design
Fast recall
Quick revision
Core answer
PK) and sort key (SK). Instead of separate Users, Orders, and OrderItems tables, keys like PK=USER#42, SK=ORDER#100#ITEM#1 encode type and relationship so one Query retrieves related data co-located on a partition. Combined with Global Secondary Indexes (GSIs) for alternate access patterns — often overloaded across entity types — a single table handles many patterns at single-digit-ms latency. The price: you must enumerate every access pattern up front; adding a new query usually means a new GSI or data remodeling. When access patterns are fluid or relational, reach for Postgres instead.Deep NoSQL modeling skill and understanding of DynamoDB's access-pattern-driven design idiom
Multi-table-per-entity design, overloading GSIs badly, not planning access patterns, or using DynamoDB for relational data
Show PK/SK schema, adjacency list, GSI overloading, sparse indexes, write sharding for hot partitions, reference Rick Houlihan talks
Interview-ready guide
Interview answer
Frame the idea
- Single-table design puts all entity types in one table by overloading PK and SK
- One
Queryreturns co-located related data in one round trip - Opposite of relational normalization
Show the design process
- Enumerate every access pattern first
- Map each pattern to a PK/SK shape
- Use GSIs for alternate access; overload + sparse to save cost
- Plan hot partitions with write sharding and DAX
Call out the cost
- Access patterns frozen at design — new queries require GSIs or remodeling
- Each GSI doubles write cost
- Scans are the enemy
- Migrations are painful
Close with when to avoid
- Evolving access patterns, ad-hoc queries, relational data, team inexperience → use Postgres
- Hybrid DynamoDB (hot KV) + Postgres (relational) is common
DynamoDB Single-Table Design
Direct Answer
Single-table design puts all entity types into one DynamoDB table by overloading the partition key (PK) and sort key (SK). Instead of separate Users, Orders, and OrderItems tables, keys like PK=USER#42, SK=ORDER#100#ITEM#1 encode type and relationship so one Query retrieves related data co-located on a partition. Combined with Global Secondary Indexes (GSIs) for alternate access patterns — often overloaded across entity types — a single table handles many patterns at single-digit-ms latency. The price: you must enumerate every access pattern up front; adding a new query usually means a new GSI or data remodeling. When access patterns are fluid or relational, reach for Postgres instead.
Common Mistakes & Pitfalls
Multi-table-per-entity design, overloading GSIs badly, not planning access patterns, or using DynamoDB for relational data
Check your understanding
Answer these without looking back at the article.
- How do sparse GSIs work and when do they save cost?
- What's the adjacency list pattern and how does it model many-to-many?
- How do you handle a celebrity user hot partition in DynamoDB?
- When does DynamoDB multi-table design make more sense than single-table?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.