From book-skills
Knowledge base from "The DynamoDB Book" by Alex DeBrie (v1.0, 2020). Use when designing DynamoDB tables, applying single-table design, choosing modeling strategies (one-to-many, many-to-many, filtering, sorting, migrations), reviewing access patterns, or referencing DDB API/expression usage.
How this skill is triggered — by the user, by Claude, or both
Slash command
/book-skills:dynamodb-book [topic, framework name, chapter number, or 'index'][topic, framework name, chapter number, or 'index']This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
**Author**: Alex DeBrie | **Pages**: 448 | **Chapters**: 22 | **Generated**: 2026-05-23
chapters/ch01-what-is-dynamodb.mdchapters/ch02-core-concepts.mdchapters/ch03-advanced-concepts.mdchapters/ch04-three-api-action-types.mdchapters/ch05-using-the-dynamodb-api.mdchapters/ch06-expressions.mdchapters/ch07-approach-data-modeling.mdchapters/ch08-single-table-design.mdchapters/ch09-modeling-to-implementation.mdchapters/ch10-importance-of-strategies.mdchapters/ch11-one-to-many-strategies.mdchapters/ch12-many-to-many-strategies.mdchapters/ch13-filtering-strategies.mdchapters/ch14-sorting-strategies.mdchapters/ch15-migration-strategies.mdchapters/ch16-additional-strategies.mdchapters/ch17-data-modeling-examples-intro.mdchapters/ch18-session-store.mdchapters/ch19-ecommerce-app.mdchapters/ch20-big-time-deals.mdAuthor: Alex DeBrie | Pages: 448 | Chapters: 22 | Generated: 2026-05-23
sparse index, single-table design, adjacency list, etc.; I find the relevant chapterch11 or ch21; I load that chapter fileindexFor details beyond the core frameworks below, I will Read the relevant chapters/chNN-*.md, glossary.md, patterns.md, or cheatsheet.md files in this skill.
DynamoDB modeling is access-pattern-first, not entity-first. You cannot model entities generically and add flexible queries later — every access pattern must be enumerated before the primary key is designed. Modeling DynamoDB like a relational database guarantees a worse outcome than just using a relational database.
The 5-step process:
If you cannot list your access patterns, you are not ready to design a table. Use a relational DB until you can.
Store multiple entity types in one DynamoDB table with overloaded primary keys, so heterogeneous items live together in an item collection (items sharing a partition key) and can be fetched in a single Query.
Use generic attribute names for keys (PK, SK, GSI1PK, GSI1SK, …) and put prefixed entity-type values inside (ORG#acme, USER#alex, REPO#repo1#ISSUE#42). One physical column holds different logical keys per entity type. This is what makes single-table design possible and powers most strategies in chapters 11-16.
| Expression | Used with | Constrains | Evaluated |
|---|---|---|---|
| KeyConditionExpression | Query | PK exact match + SK conditions | At index lookup — cheap |
| FilterExpression | Query, Scan | Any attribute | AFTER fetch — does NOT save RCU |
| ProjectionExpression | All reads | Which attributes returned | After fetch (saves bandwidth only) |
| ConditionExpression | Put/Update/Delete | Item must match before write | Before write — fails with ConditionalCheckFailed |
| UpdateExpression | UpdateItem | What to mutate | At write |
The biggest API anti-pattern in the book: using FilterExpression to reduce reads. It runs after the 1MB query response is assembled and silently breaks Limit=N. If you need to filter by attribute X, design X into a key.
DDB has no joins. Pick the right strategy per relationship per access pattern.
One-to-many (Ch 11) — five strategies, in rough order of preference:
Many-to-many (Ch 12) — four strategies:
"Filtering in DynamoDB is almost exclusively focused on your primary key." Six strategies, five of them ways to put the filter into the PK or SK of base table or GSI. The most important:
STATUS#DATE enables both "orders by status" and "orders by status sorted by date" with a single GSI.Sixth strategy is FilterExpression — see anti-pattern above.
There is no ORDER BY. Items in a partition are stored as a B-tree ordered lexicographically (UTF-8 bytes) on the sort key. You must arrange your items so they are already sorted in the order you need.
"10" sorts before "2". Use f"{n:010d}".ScanIndexForward=false — don't fight it with key encoding.MAX − value to fake ascending order on a naturally descending dimension. DeBrie admits it's "machine code" — readable alternative is to add a separate GSI.The biggest objection to single-table design has a clear answer: classify the change, then apply the right strategy.
Only indexing attributes count when judging "additive." Application attributes can always be added without touching existing rows.
| Limit | Value | Consequence |
|---|---|---|
| Item size | 400 KB | Caps "denormalize as a list/map" strategies |
| Query/Scan response | 1 MB | Forces pagination; FilterExpression breaks Limit semantics |
| Per-partition throughput | 3,000 RCU / 1,000 WCU | Hot-partition risk for "fetch latest" patterns → time-bucket sharding |
| LSI item-collection size | 10 GB | Hard cap on one collection if any LSI exists |
(Plus: 20 GSIs/table, 5 LSIs/table, 48h TTL deletion SLA, 25 items per TransactWriteItems / BatchWriteItem, 100 per BatchGetItem.)
Type attribute on every item (Ch 9) — essential for filtering by entity in single-table designs and for downstream ETL.| # | Title | Key Frameworks |
|---|---|---|
| ch01 | What is DynamoDB? | Five misconceptions, when-to-use checklist |
| ch02 | Core Concepts in DynamoDB | Table/item/attribute, PK + SK, item collection |
| ch03 | Advanced Concepts | Streams, TTL, partitions, consistency, limits, key overloading |
| ch04 | The Three API Action Types | Item / Query / Scan buckets, time-complexity model |
| ch05 | Using the DynamoDB API | ExpressionAttributeNames/Values, no-ORM rule, optional request properties |
| ch06 | Expressions | The 5 expression types; FilterExpression anti-pattern |
| ch07 | Approach to Data Modeling | Access-patterns-first, 5-step process, entity + access-pattern chart |
| ch08 | Single-Table Design | What/why/downsides, two opt-out cases |
| ch09 | From Modeling to Implementation | Boundary pattern, Type attribute, shorten attribute names |
| ch10 | The Importance of Strategies | Why "strategy" is the vocabulary |
| ch11 | One-to-many strategies | All 5 strategies + decision table |
| ch12 | Many-to-many strategies | All 4 strategies, especially adjacency list |
| ch13 | Filtering strategies | All 6, especially sparse indexes |
| ch14 | Sorting strategies | Zero-padding, inverted number, two access patterns in one collection |
| ch15 | Migration strategies | Additive vs mutating, parallel scans, ETL pattern |
| ch16 | Additional strategies | Uniqueness, atomic counters, pagination, singletons, reference counts |
| ch17 | Examples intro | How to read the worked examples |
| ch18 | Session Store | TTL, sparse index, simple PK example (4 patterns) |
| ch19 | E-commerce app | Composite keys, multi-attribute uniqueness (6 patterns) |
| ch20 | Big Time Deals | Time-bucket sharding, read-shard cache, singletons (23 patterns) |
| ch21 | Recreating GitHub's Backend | Full masterclass — 3 GSIs, 24 access patterns |
| ch22 | Migrations on the GitHub model | Migration difficulty ladder applied; inverted-number SK |
This skill covers the book content only (v1.0, April 2020). It does not include:
For hands-on work, combine with the current AWS DynamoDB documentation. The book's modeling principles (access-patterns-first, single-table design, the strategy catalog) remain authoritative.
Provides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.
npx claudepluginhub andersonfpcorrea/andersonfpcorrea-skills --plugin book-skills