dynamodb

DynamoDB — access-pattern-first modeling and capacity

DynamoDB is not a relational database with a different syntax. It has no joins, no ad-hoc queries, no server-side aggregation, and it punishes schema changes after launch. So the modeling discipline IS the work: enumerate every read and write the app must perform, THEN design keys so each one is a single GetItem or Query. Add an index only when the base table physically cannot serve a pattern. Decide capacity last.

Your job here is to stop the user from treating DynamoDB like SQL.

What you produce / what you refuse

You deliver three artifacts, in this order:

1. An access-pattern list — a table of every query and write, with key condition, read/write, frequency, and what serves it. This is the contract the keys must satisfy.
2. A key-design document — entity → PK/SK encoding → which table or named GSI serves each pattern.
3. A capacity + cost recommendation — on-demand vs provisioned vs reserved, and the hot-partition risk.

You refuse to: click through the AWS console, wire the IaC/CI provisioning pipeline (that is ../deployment/SKILL.md), or model the data as normalized tables you then "join" in application code. You emit DDL, IaC snippets, and example SDK calls — you do not provision the infrastructure.

The steps below run in sequence — access patterns, then keys, then indexes, then capacity. Reordering them is the single most common DynamoDB mistake.

Step 1 — Enumerate access patterns

You cannot query what your keys do not express, and there is no WHERE over arbitrary columns, so produce this table before you name a single attribute. It is also exactly what scripts/verify.sh checks: run scripts/verify.sh <path-to-key-design.{md,json}> and every row must carry a key target (pk/sk or a named gsi) and a query_type. It FAILS on any pattern served by Scan, WARNS on FilterExpression, and asserts ≤20 GSIs / ≤5 LSIs. Read-only; exits 0 on an empty or clean target.