What is d4m?

Why?

MongoDB is powerful but heavy. For local development, single-server deployments, embedded use cases, and CI pipelines, running a full mongod process with its memory and operational overhead is overkill. d4m speaks the exact same wire protocol, so your application, ORM, and tools see a real MongoDB server — but under the hood every database is just a SQLite file.

How it works

d4m implements the MongoDB wire protocol (OP_MSG, OP_QUERY, OP_GET_MORE, OP_KILL_CURSORS) over TCP. Incoming BSON commands are parsed, dispatched to a handler, and translated into SQL queries against a per-database SQLite file. Results are packed back into BSON reply documents and sent over the wire — the client never knows the difference.

Architecture

• Tokio async — single-threaded async I/O for connection handling
• SQLite via rusqlite — each database is a separate .db file with WAL mode
• SCRAM authentication — SHA-256 and SHA-1, role-based authorization with root/readWrite/read roles
• Aggregation engine — pipeline stages execute in Rust with SQL pushdown where possible
• Cursor management — batched cursor reads with automatic cleanup of stale cursors

When to use d4m

• Local development without Docker or mongod
• CI/CD pipelines where MongoDB infrastructure is unavailable
• Single-server deployments that don't need replication or sharding
• Embedded applications needing a MongoDB-compatible storage layer
• Prototyping and testing with real MongoDB drivers
• Low-resource environments — Raspberry Pi, edge devices, 32 MB VPS instances

What's not implemented

d4m is not a full MongoDB replacement. The following are intentionally out of scope:

• Transactions, change streams, replica sets, sharding
• TTL indexes, text indexes, geospatial indexes
• Server-side JavaScript ($where, mapReduce)
• Causal consistency and session support
• $bucket, $bucketAuto, $graphLookup, $geoNear, $merge aggregation stages