DynoTable

Data Modeling

You normalize into one table per entity because SQL taught you that habit, then ship a DynamoDB table you cannot query without 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, not a religion. This section teaches both the pattern and the cases where multiple tables are cheaper to build and operate.

What you can do after

  • Write down access patterns before keys and map each pattern to a Query or a justified Scan.
  • Design a single-table layout with entity prefixes, overloaded keys, and sparse GSIs for hot subsets.
  • Recognize when separate tables, a cache, or a relational sidecar beat one-table complexity.
  • Use a type attribute and denormalized fields without breaking idempotent writes.

Reading order

  1. Single-table design — the mental model: one table, many entity types, keys chosen for co-location.
  2. How to model data — the worksheet: access patterns in, key design and GSIs out.
  3. When not single-table — bounded contexts, low overlap, and teams that pay operational tax for one layout.
  4. Type attribute — discriminating entity kinds in one collection without ambiguous attribute shapes.
  5. Denormalization — duplicate fields to avoid second hops; know what you give up on updates.
  6. Singleton items — one row per partition for counters, config, and metadata that must live beside a parent.
0 of 7 readQuiz
DynamoDB Single-Table Design: The Complete Guide
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
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.
Intermediate7 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.
Intermediate7 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 = ORDER#K4 returning header, line items, and shipment events in sort order. It fails when two services own unrelated domains and every new feature needs another overloaded GSI. The third guide in this section is the permission slip to use multiple tables when overlap is thin.

Denormalization duplicates display fields onto parent rows so dashboards do not need a second hop. The trade-off is write fan-out: changing a customer's display name might touch every order item that cached it. Singleton items (PK = CONFIG, SK = APP) hold global counters and feature flags beside tenant data without a separate config store. Model those explicitly so a Query on a tenant partition does not accidentally return megabytes of unrelated config.

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. Paste the output into DynoTable and browse how items actually land in collections.

For the pattern your keys do not serve, the SQL Workbench runs JOIN and aggregates client-side over bounded reads — honest relief, not a modeling excuse. Paid plans add write staging when you prototype item shapes in the editor.

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