Data Modeling

This is where DynamoDB diverges hardest from SQL. You don't normalize into one table per entity — you start from your access patterns and design keys that serve them, often packing every entity into a single table. Done right, you fetch a parent and its children in one Query, no joins.

Done wrong, you get a table you can't query and a migration you can't run. So the trade-offs matter, and this section is honest about the cases where single-table design is the wrong call.

0 of 7 readQuiz

Single-Table Design in DynamoDB

Single-table design in DynamoDB — why one table with overloaded keys beats a table-per-entity, with a concrete order/customer example and the GSI overloading pattern.

Intermediate4 min read

How to Model Data in DynamoDB

How to model data in DynamoDB the access-pattern-first way — a step-by-step walkthrough that turns a multiplayer leaderboard's queries into partition and sort keys.

Intermediate8 min read

When NOT to Use Single-Table Design in DynamoDB

When NOT to use single-table design in DynamoDB — the workloads where multiple tables win (heavy analytics, simple CRUD, independent scaling), with concrete examples.

Intermediate6 min read

The Type Attribute in DynamoDB

The DynamoDB Type attribute — why you stamp an entity type on every item to identify rows, filter a GSI to one entity, and survive future migrations.