A practical field guide to DynamoDB
Understand the read.
Design the table.
Good database design starts with the questions your application asks. Learn to answer them with real tables, real queries, and a little experimentation.
No account. No AWS setup. Just your browser.
“Find every rock song.”
One question. Two ways to answer it. Run each request and compare how much the database reads.
Inspect the actual table · 47 items
- lessons
- 27 lessons
- working models
- 32 working models
- techniques to explore
- 50 techniques to explore
From your first key to a better model.
6 tiers, 27 lessonsFoundations
What an item is, and how the key addresses it.
Reads and cost
The three ways to read, and what each one charges you.
Writing data
Putting, changing, and guarding items.
Modelling relationships
One-to-many, secondary indexes, and sparse indexes.
Single-table design
One table, one index, many access patterns.
Vector search
Storing a position beside the item it describes, and searching by nearness.
Techniques
50 across 32 modelsA model for the question you’re asking
32, easiest firstStart here
The primary key answers every read. No secondary index, nothing to keep in sync.
Working designs
The shapes most production tables take: a collection with an order, a second way in, a write that has to be safe.
The hard ones
Several techniques interacting - transactions, sharded writes, geohashing, many-to-many - where a wrong key is expensive to undo.
The full console
every operation, raw request and responseThe playground is your space to experiment. Start from a working example, build any operation as a form or raw JSON, run it against a seeded table, and read the response, the cost and the latency. Open the playground.
About the engine
It's dynoxide, a DynamoDB emulator written in Rust and backed by SQLite, compiled to WebAssembly so it runs in this tab with nothing to install. Built by Martin Hicks, who also builds Parity Suite, a neutral conformance suite for DynamoDB engines.
The browser is not where it started. dynoxide also builds to a native binary that starts in about two milliseconds and needs neither Docker nor a JVM, which makes a fresh database per test affordable in CI rather than something you work around. Point any AWS SDK at it and your existing tests run unchanged.
What runs here is the WebAssembly build, scored by the same conformance suite as a target of its own. It leaves several operations unimplemented - write transactions, streams, tags and TTL among them - all of which the native build has, so it isn't a like-for-like replacement for it.
Questions
- Is this really DynamoDB, or a simulation of it?
- It's dynoxide, a DynamoDB-compatible engine backed by SQLite. The WebAssembly build is scored by the same conformance suite as dynoxide's native build, as a target of its own. It leaves several operations unimplemented - write transactions, streams, tags and TTL among them - all of which the native build has, so it is not a like-for-like replacement for it. Backups and export to S3 are missing from both builds: they are cloud-only operations with no local equivalent.
- Do I need an AWS account or anything installed?
- No. The engine runs entirely in this browser tab. There's nothing to sign up for and nothing to install.
- Is any of my data sent to a server?
- No. Lesson progress, favourites and playground tables are stored only in your browser and never leave it. There's no account and no login.
- What does the cost shown beside each read mean?
- It's what DynamoDB itself would charge: Count, ScannedCount and ConsumedCapacity, read out live so a Query and a Scan of the same table visibly cost different amounts.