DynoTable

Data Modeling

You normalize into one table per entity because SQL taught you that habit, then ship a table whose child rows aren't keyed by the parent, so the screen you need is a full Scan. The migration cost lands after the product is live.

DynamoDB modeling starts from access patterns: list the reads and writes your feature needs, then design keys and GSIs that serve them. Single-table design packs many entity types into one table when their patterns overlap; it is a trade-off. This section teaches both the pattern and the cases where multiple tables are cheaper to build and operate.

What this section teaches you to do

  • Write down access patterns before keys and map each pattern to a Query or GetItem.
  • Design a single-table layout with entity prefixes, overloaded keys, and sparse GSIs for hot subsets.
  • Recognize when separate tables beat one-table complexity.
  • Stamp a type attribute on every item, and keep denormalized copies in sync with a fan-out update.

Reading order

  1. How to model data: the worksheet (access patterns in, key design and GSIs out).
  2. Single-table design: the mental model (one table, many entity types, keys chosen for co-location).
  3. When not single-table: heavy analytics, plain CRUD over unrelated entities, and entities that scale or fail independently.
  4. Type attribute: naming each item's entity so code can route a mixed Query, narrow a GSI, and split the data later.
  5. Denormalization: duplicate fields to avoid second hops; know what you give up on updates.
  6. Singleton items: one fixed-key item for app-wide state such as feature flags and config.
0 of 7 readQuiz
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 two GSIs.
Intermediate8 min read
DynamoDB Single-Table Design: Model Many Entities in One Table
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.
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.
Intermediate8 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.
Intermediate8 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.
Intermediate9 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.

Single-table design shines when one Query returns a parent and its children, for example PK = WS#acme returning the workspace record, its documents and their comments in sort order.

It fails when two services own unrelated domains and every new feature needs another overloaded GSI. When not to use single-table design covers the cases where multiple tables are the better call.

Denormalization copies display fields onto the rows that show them (often the children) so a list screen does not need a second hop. The trade-off is write fan-out: renaming a blog author touches every post that copied the name.

A singleton item lives under one constant key (PK = SETTINGS#APP, SK = FLAGS#V1) and holds app-wide flags or config. You read it with GetItem, cache it, and keep high-frequency writes such as counters off it.

Try it in DynoTable

Sketch keys before you touch AWS. The free single-table design planner turns a list of access patterns into PK/SK placement, GSI suggestions, example items, and CreateTable JSON. Create the table, add a few of the example items, and browse in DynoTable how they land in collections.

For the pattern your keys do not serve, the SQL Workbench runs filters and aggregates (GROUP BY, COUNT, SUM) client-side over bounded reads; its JOINs work across separate tables. Use it for exploration, not for the production read path. Running the Workbench, editing and write staging are on paid plans; browsing and key queries are free.

Download DynoTable to model and browse these layouts against a live table.