A DynamoDB emulator in Rust, backed by SQLite. Runs as an HTTP server or an MCP server for coding agents, embeds into Rust and iOS applications as a library, and compiles to WebAssembly for the browser.
A DynamoDB emulator for testing and CI. A single static binary that starts in milliseconds, verified against real AWS.
2026-11-14
ดาว
—
เครื่องมือ
—
อัปไทม์
—
The crates.io badge above shows the crate version, which covers the Rust library alone. Everything you install rather than depend on carries a separate product version: the binary, the npm packages, the container images, the browser engine and the Action. That is the number dynoxide --version prints and the one to quote in a bug report. Why there are two.
Why Dynoxide?
I built Dynoxide because DynamoDB Local is slow, heavy, and can't embed. It needs a JVM, and the typical Docker-based setups adds ~3 seconds of cold-start, ~209 MB of memory at idle, and a ~225MB Docker image (~473 MB on disk) before you've done anything useful. If you're running integration tests, that's Docker starting, the JVM warming up, and your pipeline waiting.
Dynoxide is a native binary. It starts in milliseconds, idles at ~7.2 MB, and ships as a ~3 MB download. Point any DynamoDB SDK at it and your tests just work.
For Rust projects, there's also an embedded mode - direct API calls via Database::memory() with no HTTP layer at all. Each test gets an isolated in-memory database with zero startup cost. And because it compiles to a native library with no runtime dependencies, it runs on platforms where DynamoDB Local can't, including iOS.
The gap is wider on Apple Silicon because the faster CPU amplifies the difference between native code and JVM overhead. Both are real measurements of the same benchmark suite. Full methodology and per-operation breakdowns →
Conformance
Dynoxide is continuously verified against real DynamoDB by Parity Suite, the DynamoDB conformance suite that runs one test matrix against AWS itself and every major DynamoDB emulator. Pass rates move as the suite grows and each engine changes, so rather than pin a snapshot that goes stale, see the live standings:
Live standings: current pass rates for every engine, broken down by tier
Disclosure: Dynoxide and Parity Suite are maintained by the same person. The suite scores Dynoxide on the same public matrix it runs against every other engine, and the results and test code are open.
This covers the native build. The WebAssembly build is scored as its own row: it passes every test it implements, with a far higher skip count than any other target because several operations are still missing.
How It Compares
Dynoxide
DynamoDB Local
LocalStack (all services)
Floci
MiniStack
dynalite
Language
Rust
Java
Python + Java
Java (GraalVM native image)
Python
Node.js
Storage
SQLite
SQLite
SQLite (via DDB Local)
Its own (in-memory, persistent or WAL)
Its own (in-memory, optional on-disk state)
LevelDB
Runtime dependency
-
JVM
Docker + a LocalStack account (auth token)
Docker
Docker or Python
Node.js
Embeddable (Rust / iOS)
✓
-
-
-
-
-
MCP server for agents
✓
-
-
-
-
-
LocalStack uses DynamoDB Local internally as its DynamoDB engine, so its startup and memory overhead includes DynamoDB Local's JVM plus LocalStack's own Python routing layer. Since March 2026 its image needs a LocalStack account and LOCALSTACK_AUTH_TOKEN to start, even for the services that used to be free. Floci and MiniStack are general AWS emulators like LocalStack, each with its own DynamoDB engine rather than DynamoDB Local.
Quick Start
Run a local server without installing anything:
npx dynoxide --port 8000
Or install it into a project to pin the version, after which npx dynoxide uses that copy:
npm install --save-dev dynoxide
Or run it in Docker, a drop-in for amazon/dynamodb-local:
docker run --rm -p 8000:8000 ghcr.io/nubo-db/dynoxide
Point any AWS SDK or DynamoDB client at http://localhost:8000. For Homebrew, Cargo, pre-built binaries, and embedding as a Rust library, see the installation guide.
Add --log quiet to suppress informational startup and shutdown messages on
stderr (useful in test suites). It works on serve, mcp and import --serve
or --mcp, and warnings and errors still print. Without --log, the output is
unchanged.
Documentation
Installation - npm, Homebrew, Cargo, binaries, GitHub Actions, and Docker
HTTP server - running the DynamoDB-compatible HTTP API
Testcontainers - driving the container from a test suite, and the wait strategy it needs
MCP server - the Model Context Protocol server for coding agents
Dynoxide implements the DynamoDB API across tables, items, query and scan, batches, transactions, PartiQL, streams, TTL, and tags, with GSI and LSI support, the full expression syntax, and DynamoDB-compatible pagination, validation, and error codes. For the operation-by-operation breakdown and a comparison, see the compatibility summary.
Limitations
Dynoxide is built for local development, testing, and CI, not as a production DynamoDB replacement, so two classes of thing are missing on purpose.
Cloud-only operations with no local equivalent aren't implemented: backups and point-in-time restore, global tables, Kinesis streaming, resource policies, and capacity management. Call one and you get an UnknownOperationException.
A few behavioural differences are also worth knowing when you test against it:
ConsistentRead is accepted but changes nothing. SQLite is strongly consistent, so every read already is - you can't reproduce eventually-consistent reads.
Streams expose a single shard. DescribeStream returns one shard, and its ExclusiveStartShardId and Limit paging parameters are accepted but ignored.
Transaction-contention errors (TransactionConflictException, TransactionInProgressException) aren't emulated - there's no concurrent contention in a single process.
Dynoxide's DynamoDB API semantics and validation logic were informed by dynalite, the excellent DynamoDB emulator built on LevelDB by Michael Hart and now maintained by the Architect team.
Dynoxide is a clean-room Rust implementation. No code was ported directly, but dynalite's thorough approach to matching live DynamoDB behaviour, including edge cases and error messages, was an invaluable reference.
Dynoxide uses SQLite as its storage layer. (AWS's DynamoDB Local also uses SQLite internally.)
Amazon DynamoDB, DynamoDB, and AWS are trademarks of Amazon.com, Inc. or its affiliates. Dynoxide is an independent project and is not affiliated with, endorsed by, or sponsored by Amazon, and nothing here grants any right to use those names or marks.