Fundamentals

You model DynamoDB like a spreadsheet with columns, then discover there is no schema, no ALTER TABLE, and the primary key is the address on disk. Every access pattern you sketch later either fits that address or fights it.

This section is the typed-value model, how items group into collections under one partition key, and why consistency choices show up on every read API. SQL habits die here: attributes are optional per item, types matter at the API boundary, and a composite key is not metadata — it is the physical sort order of your data.

What you can do after

• Read any DynamoDB item and name each attribute's type without guessing from JSON.
• Explain why a Query returns one item collection and what partition key + sort key actually control on disk.
• Size an item before you denormalize and know when a 400 KB hard limit will reject the write.
• Pick strong vs eventual consistency for a read and predict what stale data costs in your UI.

Reading order

Work through the guides in this order. Each step assumes the previous one.

1. When to use DynamoDB — the fit/no-fit decision before you commit storage and migration cost to a key-value design.
2. Data types — S, N, B, sets, lists, and maps; the type tags every API call must respect.
3. JSON marshalling — how plain JSON becomes typed DynamoDB attributes and where silent coercion bites.
4. Item size limit — the 400 KB cap, what counts toward it, and patterns that blow past it when you pack children inline.
5. Item-based actions — every operation targets whole items; partial updates are expressions, not column writes.
6. Item collections — all items sharing a partition key; the unit a single Query can walk in sort order.
7. Composite primary key — partition + sort key as physical layout; why "primary key" in DynamoDB is a range, not a scalar.
8. Consistency — strong vs eventual on the base table; what you can and cannot ask for on a GSI.

A composite key on USER#123 with sort keys PROFILE, ORDER#… lets one Query return a user's profile and recent orders sorted by time. Misunderstand item collections and you either Scan the table or fetch each row with GetItem — both scale poorly and both show up on the bill.

Hands-on in DynoTable

Open a live table in DynoTable and inspect keys in the grid. The table's Overview shows partition and sort key names plus every GSI so you can see how items group before you write a query. Paste a sample item into the free item size calculator to measure bytes toward the 400 KB limit; denormalizing three child records often crosses the 1 KB line where read and write capacity units start rounding up.

The visual filter builder adds hash and range key conditions with type-aware operators, so you practice Query against a real collection instead of hand-writing JSON. Free read-only access covers queries, PartiQL SELECT, and exports; writes require a paid trial or license.

Download DynoTable and run these primitives against your own tables as you read.