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 stores every entity in one table behind overloaded key prefixes, so a parent and its children return in one Query.

Intermediate4 min read

How to Model Data in DynamoDB

How to model data in DynamoDB access-pattern first. A game leaderboard walkthrough that turns four questions into partition keys, sort keys and a GSI.

Intermediate8 min read

When NOT to Use Single-Table Design in DynamoDB

When not to use single-table design in DynamoDB — heavy analytics, plain CRUD over unrelated entities, and entities that scale or fail independently.

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.

Intermediate7 min read

Denormalization in DynamoDB

DynamoDB denormalization — why you duplicate data instead of joining, with a blog author-name example, the staleness footgun, and when to embed vs. duplicate.

Intermediate6 min read

Singleton Items in DynamoDB

DynamoDB singleton items — one fixed-key row holding global state like feature flags or config, read with GetItem and updated with condition expressions.

Intermediate8 min read

Knowledge checkTake the quiz

Check what you’ve learned in this section.

Start with single-table design — everything after it assumes that mental model.

Sketch the schema before you build it with the free Single-Table Design tool — it turns a list of access patterns into a PK/SK/GSI plan. Then try DynoTable to model and browse these layouts against a live table — and for the ad-hoc question your keys don't serve, its SQL Workbench runs JOIN, GROUP BY, and aggregates client-side.