PluginBench
MCP Server
Active
Apache-2.0

Dynoxide MCP Server

io.github.nubo-db/dynoxide

Fast DynamoDB emulator with 35 MCP tools for testing and local development without JVM overhead.

RepositoryRegistry

What is the Dynoxide MCP server?

Dynoxide is a DynamoDB emulator backed by SQLite that runs as an HTTP server, MCP server for coding agents, or embeds directly into Rust and iOS applications. It exposes 35 DynamoDB tools via MCP, enabling agents to create tables, read/write items, query, scan, and manage transactions with millisecond startup and minimal memory footprint.

Dynoxide provides a lightweight, fast alternative to DynamoDB Local for local development and testing. Unlike DynamoDB Local (which requires a JVM and ~181 MB memory), Dynoxide is a native binary that starts in milliseconds, uses ~5 MB idle memory, and can be embedded directly into Rust projects or run as an HTTP/MCP server. It implements the full DynamoDB API including tables, items, queries, scans, batches, transactions, PartiQL, streams, TTL, and GSI/LSI support.

How to install Dynoxide

Copy-paste configuration for popular MCP clients.

transport: stdio
Config generated by PluginBench — verify against the source before use.
~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "dynoxide": {
      "command": "npx",
      "args": [
        "-y",
        "dynoxide",
        "mcp"
      ]
    }
  }
}

Tools & capabilities

Tools this server exposes to the agent.

  • CreateTable — Create a DynamoDB table with specified schema and indexes
  • DeleteTable — Delete a DynamoDB table
  • DescribeTable — Get detailed information about a table
  • ListTables — List all tables in the database
  • PutItem — Write an item to a table
  • GetItem — Retrieve a single item by key
  • UpdateItem — Modify an existing item
  • DeleteItem — Remove an item from a table
  • Query — Query items using a key condition expression
  • Scan — Scan all items in a table with optional filtering
  • BatchGetItem — Retrieve multiple items in a single request
  • BatchWriteItem — Write or delete multiple items in a single request
  • TransactGetItems — Atomically read multiple items
  • TransactWriteItems — Atomically write, update, or delete multiple items
  • PartiQL Execute — Execute PartiQL statements against tables
  • UpdateTable — Modify table settings and indexes
  • TagResource — Add tags to a table
  • UntagResource — Remove tags from a table
  • ListTagsOfResource — List tags on a table
  • DescribeStream — Get information about a DynamoDB stream

Use cases

  • Run fast integration tests for DynamoDB-backed applications without Docker or JVM startup overhead
  • Embed DynamoDB emulation directly into Rust projects for isolated per-test databases with zero startup cost
  • Develop and test DynamoDB applications locally with a drop-in replacement for DynamoDB Local
  • Enable AI coding agents to design, query, and manage DynamoDB schemas and data via MCP tools
  • Test complex DynamoDB operations including transactions, streams, TTL, and secondary indexes

Dynoxide MCP server FAQ

What is Dynoxide?

Dynoxide is a lightweight DynamoDB emulator written in Rust that runs as an HTTP server, MCP server for coding agents, or embeds directly into Rust/iOS applications. It provides full DynamoDB API compatibility with 35 MCP tools, starting in milliseconds and using minimal memory.

Is Dynoxide free?

Yes, Dynoxide is open-source and dual-licensed under MIT and Apache 2.0 at no cost.

How do I install Dynoxide in Cursor or Claude?

Install via npm (`npm install --save-dev dynoxide`) or Docker (`ghcr.io/nubo-db/dynoxide:1.2.1`), then configure your MCP client to connect to the server. See the MCP server documentation at https://github.com/nubo-db/dynoxide/blob/main/docs/mcp.md for setup details.

Does Dynoxide require AWS credentials or authentication?

No, Dynoxide is a local emulator that runs without AWS credentials or any external authentication. It's designed for local development and testing only.

How does Dynoxide compare to DynamoDB Local?

Dynoxide starts in ~15ms vs ~2.3 seconds for DynamoDB Local, uses ~8 MB memory vs ~181 MB, and ships as a ~3 MB download vs ~225 MB. It also supports embedding directly into Rust projects and running as an MCP server, which DynamoDB Local does not.

What DynamoDB features does Dynoxide support?

Dynoxide supports tables, items, queries, scans, batches, transactions, PartiQL, DynamoDB Streams, TTL, tags, and both global and local secondary indexes. Cloud-only features like backups, global tables, and Kinesis streaming are not implemented.

README (reference)

Source of truth, from the repository.

Dynoxide

crates.io docs.rs CI conformance license

A DynamoDB emulator backed by SQLite. Runs as an HTTP server, an MCP server for coding agents, or embeds directly into Rust and iOS applications as a library.

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 <!-- prose:ddb_local_cold_start -->2–5 seconds<!-- /bench --> of cold-start, <!-- prose:ddb_local_idle_memory -->~181 MB<!-- /bench --> of memory at idle, and a <!-- prose:ddb_local_image_size -->~225MB<!-- /bench --> Docker image (<!-- prose:ddb_local_image_size_disk -->~471 MB<!-- /bench --> 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 <!-- prose:dynoxide_idle_memory -->~5.1 MB<!-- /bench -->, and ships as a <!-- prose:dynoxide_binary_size -->~3 MB<!-- /bench --> 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.

Performance

Local Development (Apple Silicon)

MetricDynoxide (embedded)Dynoxide (HTTP)DynamoDB Local
Cold startup<!-- bench:local_startup_embedded -->~0.2ms<!-- /bench --><!-- bench:local_startup_http -->~15ms<!-- /bench --><!-- bench:local_startup_ddb_local -->~2,287ms<!-- /bench -->
GetItem (p50)<!-- bench:local_getitem_embedded -->9µs<!-- /bench --><!-- bench:local_getitem_http -->0.1ms<!-- /bench --><!-- bench:local_getitem_ddb_local -->0.8ms<!-- /bench -->
PutItem throughput<!-- bench:local_putitem_embedded -->~51,613 ops/s<!-- /bench --><!-- bench:local_putitem_http -->~6,703 ops/s<!-- /bench --><!-- bench:local_putitem_ddb_local -->~945 ops/s<!-- /bench -->
50-test suite (sequential)<!-- bench:local_ci_suite_embedded_seq -->~484ms<!-- /bench --><!-- bench:local_ci_suite_http_seq -->~569ms<!-- /bench --><!-- bench:local_ci_suite_ddb_local_seq -->~2,407ms<!-- /bench -->
50-test suite (4x parallel)<!-- bench:local_ci_suite_embedded_par -->~203ms<!-- /bench --><!-- bench:local_ci_suite_http_par -->~235ms<!-- /bench --><!-- bench:local_ci_suite_ddb_local_par -->~1,189ms<!-- /bench -->

CI (GitHub Actions)

Numbers from ubuntu-latest (<!-- prose:ci_runner_hardware -->4-core AMD EPYC 7763, 16GB RAM<!-- /bench -->). Commit <!-- bench:ci_commit_link_root -->be8bfbc<!-- /bench -->.

MetricDynoxide (embedded)Dynoxide (HTTP)DynamoDB LocalLocalStack (all services)
Cold startup<!-- bench:ci_startup_embedded --><1ms<!-- /bench --><!-- bench:ci_startup_http -->~2ms<!-- /bench --><!-- bench:ci_startup_ddb_local -->~3,481ms<!-- /bench --><!-- bench:ci_startup_localstack -->~12,803ms<!-- /bench -->
GetItem (p50)<!-- bench:ci_getitem_embedded -->15µs<!-- /bench --><!-- bench:ci_getitem_http -->0.3ms<!-- /bench --><!-- bench:ci_getitem_ddb_local -->0.8ms<!-- /bench -->-
50-test CI suite<!-- bench:ci_suite_embedded_seq -->794ms<!-- /bench --><!-- bench:ci_suite_http_seq -->759ms<!-- /bench --><!-- bench:ci_suite_ddb_local_seq -->2,466ms<!-- /bench -->-
Full workload (10K items)-<!-- bench:ci_workload_http -->3.0s<!-- /bench --><!-- bench:ci_workload_ddb_local -->11.2s<!-- /bench -->-
Binary / image (download)<!-- prose:ci_binary_download -->~3 MB<!-- /bench --><!-- prose:ci_binary_download_http -->~3 MB<!-- /bench --><!-- prose:ci_image_ddb_local_download -->225 MB<!-- /bench --><!-- prose:ci_image_localstack_download -->1.1 GB<!-- /bench -->
Binary / image (on disk)<!-- bench:ci_binary_size -->7 MB<!-- /bench --><!-- bench:ci_binary_size_http -->7 MB<!-- /bench --><!-- bench:ci_image_ddb_local -->471 MB<!-- /bench --><!-- bench:ci_image_localstack -->1.2 GB<!-- /bench -->
Idle memory (RSS)<!-- bench:ci_memory_embedded_idle -->~5.1 MB<!-- /bench --><!-- bench:ci_memory_http_idle -->~8 MB<!-- /bench --><!-- bench:ci_memory_ddb_local_idle -->~181 MB<!-- /bench --><!-- bench:ci_memory_localstack_idle -->~513 MB<!-- /bench -->

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:

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

DynoxideDynamoDB LocalLocalStack (all services)dynalite
LanguageRustJavaPython + JavaNode.js
StorageSQLiteSQLiteSQLite (via DDB Local)LevelDB
Runtime dependency-JVMDocker + LocalStackNode.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.

Quick Start

Install from npm and start a local server:

npm install --save-dev dynoxide
npx dynoxide --port 8000

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.

Documentation

Supported Operations

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.

For the per-feature support matrix, see the live capability matrix; the full operation-by-operation breakdown is in the compatibility summary.

Acknowledgements

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.)

License

Dual-licensed under MIT and Apache 2.0. See LICENSE-MIT and LICENSE-APACHE.

Trademarks

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.

Related MCP servers

LILinux MCP daemon (mcpd) logo

Linux MCP daemon (mcpd)

AI agent access to Linux servers without SSH: scoped tools, per-call isolation, root only if granted

View repository →
IOio.github.nugehs/aiglare logo

io.github.nugehs/aiglare

Maintained

Audit AI/LLM features for governance guardrails: confidence, fallback, validation, human-in-loop.

1
JavaScript
MIT
View repository →
BObouncer logo

bouncer

Maintained

Static compliance-controls checker for UK Online Safety Act & ICO Children's Code. CLI + MCP.

0
JavaScript
MIT
View repository →
IOio.github.nugehs/gate logo

io.github.nugehs/gate

Maintained

One ship/no-ship verdict from aiglare, bouncer, tieline & repoctx — the unified merge gate.

0
JavaScript
MIT
View repository →
RErepoctx logo

repoctx

Active

Local-first code context, impact analysis, and merge-readiness verdicts for AI agents.

1
JavaScript
MIT
View repository →
TItieline logo

tieline

Maintained

Static FE-BE contract-drift checker: finds frontend calls the backend does not expose. CLI + MCP.

0
JavaScript
MIT
View repository →