I've been building on DynamoDB since around 2015, and these days I build tools for it: , a native client. So I'm not neutral about it. It's the first database I reach for, and with reason - the operational overhead is close to nil, no connections to pool or instances to size, and it holds the same single-digit-millisecond reads whether the table has a thousand items or a billion. The data modelling is a craft, and a satisfying one.
It's also one of the harder databases to learn, and that's the part I keep coming back to. DynamoDB punishes the instincts you bring from SQL. You don't normalise and join at read time; you work out the questions your app will ask first, and shape the data around those access patterns, until one table answers all of them. It's a real shift in how you think, and it's where a lot of people bounce off - it feels backwards right up until it clicks.
The people who teach it best all teach it the same way. team's examples, Rick Houlihan's re:Invent talks - the legendary ones, where he models half a dozen access patterns onto a single table at a hundred miles an hour - none of them hand you rules to memorise. They show you patterns and make you run them. I learned a lot of my DynamoDB from all three, and it stuck because I was building as I went.
That last part is the bit that's hard to come by on your own. Reading about an access pattern and having it in your fingers are different things, and to run one - build the table, write the items, fire the query and see what comes back - you need an AWS account, or a local emulator installed and seeded. Enough friction that plenty of people read about single-table design without ever building one.
There was a second thing pulling the same way. dynoxide had is what came out of it: a place to learn DynamoDB that also happens to be a working app sat on the engine all day. That's where the past month went, and why as the thing accesspatterns.dev depends on. There's no backend, so every query, scan and write runs client-side against a SQLite-backed store. The database is in the tab, which is why it needs no account and nothing to install.
It's a preview. The wasm build doesn't yet run against the conformance suite that holds dynoxide's native build to real DynamoDB, so treat what you see as illustrative rather than authoritative. Building accesspatterns.dev on it is what's been hardening it; getting the wasm engine onto that suite is the next job, and the day it's there is the day the preview label comes off.
It's early, and the part I most want to grow is that library of models. I'd rather it weren't only mine. A shared, runnable catalogue of how people actually model their own problems on DynamoDB would be worth far more than my handful of examples, and that's the direction I want to take it. There's no way to submit one yet, but if you've got a pattern you'd want in there, tell me - and if something behaves wrong, tell me that too. It's the same dogfooding that got the engine this far.
SOCIAL SHARE CARD GENERATOR