A DynamoDB-compatible engine backed by SQLite. Run it as a local server, in CI, embedded in your Rust or iOS app, or in the browser via WebAssembly. ~2ms startup, ~3 MB, no Docker or JVM.
What's new in v0.11.4
Passing a top-level argument together with a subcommand is now a hard parse error, where the argument was silently ignored.
See full changelog →
Coming soon
on main, not yet released
Breaking (Rust API): the public partiql::parser::Statement enum gained a returning field on its Update and Delete variants, and both variants are now #[non_exhaustive]; the public actions::batch_execute_statement::BatchStatementResponse struct gained a table_name field and is now #[non_exhaustive] too.
Why Dynoxide
DynamoDB Local takes ~3,200ms on CI. Dynoxide is ready before your SDK has even connected.
No Docker image, no JVM. Just a native binary that uses ~8 MB of RAM at idle.
Parity Suite, a DynamoDB conformance suite, runs the same tests against Dynoxide and real AWS, scored the same way for every emulator. The full conformance results are public.
Built-in MCP server with 34 tools. Your coding agent can create tables, query data, and manage snapshots.
One engine, many ways to run it
The same DynamoDB-compatible engine, whether you need a local server, an in-process library, a browser build, or an MCP server for your coding agent.
Local HTTP server
Docs →A native binary that serves the DynamoDB wire protocol on a port. A drop-in for DynamoDB Local: point any AWS SDK at the endpoint.
CI service
Docs →A GitHub Action (or the Docker image) that brings Dynoxide up in a pipeline. A ~3 MB download with no JVM warmup, so the database stops being the slow part of the job.
Embedded library
Docs →A Rust crate that runs the engine in-process, with no server and no network. Single-digit microsecond operations, and it runs on platforms DynamoDB Local can't, including iOS.
MCP server
Docs →A built-in Model Context Protocol server with 34 tools, over stdio or HTTP. A coding agent can create tables, query data, and manage snapshots without leaving the conversation.
Browser (WebAssembly) Preview
Docs →Run the engine in the tab via WebAssembly, persisted to OPFS. Drops onto ordinary static hosting, with no special server headers.
Dual-licensed under MIT or Apache-2.0, so you can embed it in your own application and redistribute it.
Now it runs in
the browser
The same engine, compiled to WebAssembly and published on npm. No server, no install - just a DynamoDB-compatible database running on the page, on the official SQLite wasm build. It persists to OPFS, so a table you create survives a reload. Nothing leaves the page.
It runs in a Web Worker and needs no special server headers - no cross-origin isolation, no COOP/COEP - so the whole thing, about 2 MB, drops onto ordinary static hosting.
Create-table, put, get, delete, query and scan all work today, over base tables and both index types. TTL, streams and transactions don't yet. The wasm build isn't run against the conformance suite - this is a preview only.
Learn DynamoDB by operating it →
accesspatterns.dev runs this same engine in your browser - guided lessons, real access-pattern models, and a freeform playground, with the cost of every operation shown as you go.
Local DynamoDB emulator startup, visualised
Time from zero to accepting requests. Dynoxide's bar is so small you might miss it.
Measured on GitHub Actions runners. Local development on Apple Silicon is even faster.
Built for CI,
not just your laptop
A fast emulator doesn't just save you time locally - it changes what's practical in your pipeline. When startup takes milliseconds instead of seconds, you can spin up a fresh database per test. No shared state. No cleanup. No flaky tests.
Pair that with dynoxide import and you're running integration tests against real data shapes - anonymised, compressed, loaded in seconds from a snapshot of production.
A ~3 MB download with no dependencies means no Docker layer caching, no JVM warmup eating into your build minutes, and no "works on my machine" divergence between local and CI.
Already built around amazon/dynamodb-local in a container? Swap the image. The official ghcr.io/nubo-db/dynoxide is a ~5 MB drop-in - same API, where you'd otherwise pull 225 MB. You don't need Docker, but if you want it, it's no longer the slow part.
Drop-in replacement for dynalite
If you're using dynalite for local DynamoDB during development, switching is one line. You don't need to know or care that it's Rust under the hood.
The npm package ships platform-specific binaries - the same approach used by esbuild, Biome, and Turbo. A thin wrapper pulls in the right binary for your OS at install time. No compilation, no native dependencies, no surprises.
Your existing dev setup stays the same. Same SDK calls, same endpoint, same table definitions. The only difference is the name in your package.json - and the fact that your local DynamoDB starts in milliseconds instead of seconds.
Tested against the real thing
998 conformance tests, run against real DynamoDB on AWS. Every emulator gets the same suite, scored the same way.
See the live conformance results on Parity Suite →The score is correctness over the operations each emulator implements, checked against real DynamoDB. It only tests what it tests - a behaviour with no test is a blind spot, not a pass. How the scoring works.
Conformance suite: paritysuite/dynamodb-conformance
Frequently asked questions
How fast does Dynoxide start?
Does Dynoxide require Docker?
Is Dynoxide compatible with DynamoDB?
Can I use Dynoxide as a local DynamoDB emulator?
How does Dynoxide compare to DynamoDB Local?
Try it in ten seconds
The fastest DynamoDB Local alternative. One install, one command, works with any DynamoDB SDK.