Things have changed. The embedded database category has real options now — SQLite (which grew up and got serious), DuckDB (analytical powerhouse), libSQL (SQLite’s networked fork), RocksDB and LMDB (KV primitives), and now MongrelDB. I want to talk about this last one because it does something genuinely different.

What MongrelDB is

MongrelDB is an embedded, single-node, log-structured columnar database written in Rust. The name is a deliberate riff on MongoDB — and the joke is the point. A mongrel is a mixed-breed dog, and MongrelDB takes the good parts from several places and bolts them together. Some of those bolts are welded; some are still held on with baling wire. We’ll get to which is which.

The headline numbers from the project’s own cross-engine benchmarks at 1M rows:

• Single-row durable write: 7.7 µs — about 1.8× faster than SQLite (14.2 µs), 37× faster than DuckDB (301 µs)
• Single-row durable update: 7.4 µs
• Bulk insert: 2.3× SQLite, 2.6× DuckDB native
• COUNT(*) is O(1) by design — 0 µs
• Storage: 4.17 bytes/row at 1M rows

Take vendor benchmarks with the usual grain of salt, but these aren’t outlandish. The architecture backs them up.

How it’s built (and why it matters)

Write path: a WAL feeds a Bε-tree memtable, which flushes to immutable sorted runs in a custom .sr PAX columnar format. Read path: merge memtable + sorted runs under MVCC snapshot isolation. This is LSM with some twists.

The unusual part is the eight index kinds in a shared RowId space:

• HOT — trie for primary-key point lookup
• Bitmap — Roaring for low-cardinality equality
• PGM — learned range index (shrinking-cone, ε-bounded)
• FM-index — BWT + wavelet tree for substring / FTS
• HNSW — approximate nearest neighbor for vectors
• PMA — cache-oblivious sorted runs
• Sparse — inverted token lists for learned-sparse retrieval
• MinHash — LSH for set similarity (dedup / join)

You compose conditions in RowId space, then decode only the matching rows and the columns you asked for. That hybrid model — bitmap equality intersected with HNSW ANN intersected with FM substring — is what modern AI retrieval actually needs. Most embedded engines give you a B-tree and a hash index and call it done.

Predicate and projection pushdown go all the way to the page level. Each 65,536-row page carries populated min/max; the reader skips whole pages whose range excludes your predicate. Encrypted columns keep their min/max in a per-run AES-256-GCM stats envelope, so they prune identically to plaintext. The 1.87 GiB/s AES throughput is hardware-accelerated and adds under 5% to typical workloads.

The SQL frontend is DataFusion 54, which means recursive CTEs, window functions, CREATE TABLE AS SELECT, materialized views, multi-statement execution, and a mongreldb_fts_rank UDF for FTS ranking. You can embed the engine in-process (the better-sqlite3 model) or run an optional mongreldb-server daemon (axum/tokio) for multi-process access.

Around the engine you get real database features: WAL-streamed replication (read-scaling, not write-scaling), change data capture via NOTIFY/LISTEN + SSE, Argon2id user/role/GRANT, page-level AES-256-GCM encryption with a proper key hierarchy, and per-table unique / FK / CHECK constraints enforced in the core transaction path — not in your app code.

Language bindings are real, not vapor: Rust core, Node NAPI addon, pure-PHP 8.4+ (no C extension, talks HTTP to the daemon), Python and TypeScript via MongrelDB Kit (schema-aware query builder, migrations, multi-language parity, content-addressed migration checksums).

Where it fits in 2026

The embedded database market has roughly four niches:

1. OLTP embedded — SQLite, libSQL. Single-row writes, simple reads, durable, tiny footprint. SQLite is the 800-pound gorilla.
2. OLAP embedded — DuckDB. Bulk reads, analytical queries, columnar. Wins on filter and aggregation throughput.
3. KV embedded — RocksDB, LevelDB, LMDB. Lower-level primitives; you build indexes on top.
4. AI-native storage — Qdrant, Lance, SQLite extensions. Optimized for vector search and learned indexes.

MongrelDB is trying to sit across (1) and (4) with some of (2)’s analytical chops. The pitch is: “Your app’s primary storage AND your vector search AND your FTS AND your learned-sparse retrieval, in one embedded engine, with no separate vector DB to sync.”

That’s a real pitch. The eight-index approach is what makes it more than marketing.

The Pros

• Writes are genuinely fast. Sub-10µs single-row durable writes in an embedded engine is a real achievement. SQLite is fast; this is faster. DuckDB isn’t in the same race for OLTP.
• AI-native is not marketing. HNSW, Sparse, and FM-index are first-class indexes, not query-time hacks. The hybrid query model matches what AI retrieval actually needs.
• Encryption is built in, not bolted on. Page-level AES-256-GCM with a real key hierarchy (passphrase → Argon2id → KEK → DEK, or raw key file), HMAC’d run metadata, and pruning preserved on encrypted columns.
• Constraints in the core. Unique, FK, and CHECK are enforced at the storage layer. Same for auth — require_auth makes the engine itself reject unauthenticated opens, not just the daemon front-door.
• The Rust + DataFusion choice is smart. Rust for memory safety and FFI ergonomics, DataFusion for the SQL parser/optimizer/planner. Years of battle-tested code you’re not re-implementing.
• MongrelDB Kit is the right abstraction. Cross-language schema, migrations, query builder, triggers, async variants, type generation. That’s how you build a real ecosystem, not just a core and “good luck.”
• The name is honest. A mongrel is a mixed-breed dog. MongrelDB is a mixed-architecture database. They named it for what it is, and that earns points in a category full of overpromising.

The Cons (honest tradeoffs)

• It’s new. SQLite has been hammered on for 25 years in production. MongrelDB is new enough that you don’t have a community of people who have hit the edge cases for you. Auth, replication, and CDC are real, but they’re version 1.0 of those features. Expect rough edges.
• No network mode by default. Like SQLite, you embed it in-process. The daemon exists for multi-process access, but it’s not what MongoDB/PostgreSQL users expect. If you need horizontal scale, this isn’t it — single-node, period. Replication is read-scaling (followers), not write-scaling.
• No KMS integration. Page-level encryption is solid, but there’s no AWS KMS, GCP Cloud KMS, Azure Key Vault, or HashiCorp Vault. You bring your own key (passphrase or key file) and you manage it. For regulated workloads, that’s a checklist item you handle yourself.
• DataFusion is a moving target. Pinning to “DataFusion 54” is great for now. It also means the SQL surface depends on what DataFusion ships. If you want a feature DataFusion doesn’t have, you’re at the mercy of upstream.
• Eight indexes is also a footgun. Having every kind of index doesn’t mean you should build all eight on a single table. The planner has to make smart choices; bloat the index set and writes pay the cost.
• PHP needs a daemon. The PHP client is pure-PHP with no C extension, but it talks to mongreldb-server over HTTP. If you wanted in-process PHP (like PDO/SQLite), you won’t find it here. The NAPI addon is the in-process model; PHP doesn’t get that path.
• The benchmark comparisons are self-published. Cross-engine benchmarks on the vendor’s own machine, with the vendor’s own workloads. Real production data will be different. Run your own before you commit.

Who should use it

MongrelDB is interesting if you’re:

• Building a Node.js, TypeScript, Python, or PHP app that needs a single embedded store and doesn’t want to run a separate server.
• Building an AI-native app where vector search, FTS, and learned-sparse retrieval are first-class features of the primary store, not bolt-ons synced from somewhere else.
• Comfortable being on a newer engine, trading some ecosystem maturity for a tighter architectural fit.
• Running a service-oriented architecture where each service can have its own database and you don’t need cross-service joins at the storage layer.

Who should probably wait

• You need a managed, hosted, multi-region replicated database. This isn’t that.
• Your application is plain CRUD on a normalized schema and SQLite is already serving you fine. SQLite is the safer default.
• You’re doing heavy analytical workloads over millions of rows. DuckDB is still the king there, and exporting to DuckDB via Parquet is a well-trodden path.
• You need deep compliance certifications (SOC2, FedRAMP, HIPAA-eligible). New engines take time to get there.
• You need a 24/7 community on Stack Overflow. SQLite’s tag has 100k+ questions. MongrelDB’s has, well, fewer.

The verdict

MongrelDB is a serious attempt at a thing that hasn’t really existed: a single embedded engine that handles both OLTP and AI-native retrieval, with real SQL, real encryption, real auth, and a real cross-language ecosystem. It’s not a MongoDB killer (different category) and it’s not a SQLite killer (different priorities). It’s its own thing.

The name is honest. A mongrel is what you get when you breed the parts that work and ignore the breed standard. MongrelDB is log-structured columnar storage with MVCC, a learned-index flavor, real encryption, and a DataFusion SQL frontend — all in an embedded Rust engine. The mongrel analogy holds.

If you’re building a Node.js or Python AI app and you don’t want to stand up Qdrant + Postgres + a sync layer, look at this. If you’re writing PHP 8.4 and you’re tired of the SQLite-or-MySQL choice, this is worth a serious look. If you’re running SQLite in production and everything works, you have no urgent reason to migrate — but you should know what’s coming.

The bar for “yet another database” is high, and a lot of “yet another databases” fail. MongrelDB has the architecture and the benchmarks to make a case. Now it needs production years. If you’re willing to be one of the early ones, this is one of the more interesting bets in the embedded space right now.