Twenty years ago an embedded database decision was often SQLite or a pile of files, and that was not a bad decision tree, because SQLite had already done the difficult work around transactions, recovery, portability, and a file format that would outlive the application framework wrapped around it; the category is wider now, with DuckDB for local analytics, RocksDB and LMDB for lower-level key-value storage, local-first databases built around synchronization, and vector stores built around retrieval, so a new engine has to explain the workload it serves rather than announce that it also writes bytes to disk.
MongrelDB is an independent open-source database written in Rust. It is not MongoDB, not a MongoDB fork, and not a MongoDB-compatible replacement. The name describes the architecture: operational writes, columnar runs, specialized indexes, DataFusion SQL, and optional server deployment share one engine even though those ideas came from database families that are usually operated separately.
What MongrelDB is
The production center is an embedded or single-node operational database. An append-only WAL and group commit feed a Bε-tree memtable keyed by RowId and epoch, mutable state flushes into immutable .sr sorted runs with PAX-style columnar pages, and readers merge those layers under MVCC snapshots.
Six public secondary index families resolve through one RowId space:
- Roaring Bitmap for low-cardinality equality and indexed byte prefixes;
- PGM learned range for ordered numeric and time predicates;
- FM-index for exact substring containment;
- ANN with supported HNSW, DiskANN, IVF, Dense, BinarySign, and product-quantized combinations;
- Sparse inverted vectors for SPLADE-style weighted retrieval;
- MinHash LSH for approximate set similarity and deduplication candidates.
Primary-key lookup is implicit and currently uses an ordered-map implementation behind the public surface. The packed-memory-array tier is internal. Calling those two additional public indexes would make the marketing number larger and the documentation worse, so the accurate public count is six.
DataFusion 54 supplies SQL including joins, recursive CTEs, window functions, CREATE TABLE AS SELECT, materialized views, multi-statement execution, JSON functions, and scored retrieval table functions. Native conditions remain available when a typed application call expresses the query more directly than SQL.
The unusual part is mixed retrieval
A typical retrieval query is not just nearest neighbours. It asks for semantic candidates belonging to one tenant, within a date window, containing an exact identifier, then mixes dense and sparse relevance and reranks a bounded candidate set against full-precision vectors.
MongrelDB’s index families all return RowIds, so equality, range, substring, vector, sparse, and set-similarity paths can combine before the engine decodes the requested columns. Named retrievers fuse through reciprocal-rank fusion, optional exact-vector reranking preserves both approximate and final scores, and remote AI paths enforce candidate, work, deadline, and concurrency ceilings.
That is the engine’s strongest differentiator. An application can keep source rows, operational transactions, analytical projections, and model-derived representations in one local recovery model instead of synchronizing a primary store, vector service, and search index.
What the current measurements say
The published release-build fixture on an Intel Core Ultra 9 386H reports:
| Operation | Measurement |
|---|---|
| Accepted put without fsync | 4.4828 microseconds |
| Durable commit with fsync | 4.6721 milliseconds |
| 1,000 puts plus commit | 7.7071 milliseconds, 129.75 K rows/s |
| Typed bulk load, one million rows | 58.471 milliseconds, 17.102 M rows/s |
| Typed full scan, one million rows | 83.707 milliseconds, 11.946 M rows/s |
| Bitmap equality, one million rows | 8.0387 milliseconds |
| Integer range, one million rows | 8.8231 milliseconds |
| Warm embedded point query p50 | 1.037 microseconds |
These are one-machine engineering results with commands and fixtures in BENCHMARKS.md. They are not cross-engine guarantees, and the durable number is milliseconds, not the single-digit microseconds an earlier version of this article incorrectly claimed.
A production decision runs the application’s own rows, projections, filters, durability policy, encryption mode, and concurrent workload on deployment hardware. Vendor benchmarks are useful for finding a path worth testing, not for avoiding the test.
Where SQLite still wins
SQLite has decades of deployment, an exceptionally stable format, tiny distribution friction, broad language support, mature administration tools, and a community large enough that most failure modes already have a search result. If the application needs reliable relational storage, ordinary indexes, and SQL without native vector, sparse, FM, or mixed analytical requirements, SQLite is the safer default.
MongrelDB also does not open SQLite files or preserve SQLite API compatibility. The SQLite encryption comparison is explicit about that boundary.
Where DuckDB still wins
DuckDB is built for local analytical SQL and has a mature ecosystem around Parquet, data frames, and scan-heavy workloads. If the workload is primarily ingest-then-analyse, with no need for an operational transaction engine and its specialized retrieval indexes, DuckDB is the more established analytical choice.
MongrelDB uses columnar sorted runs and DataFusion because operational applications still need scans and aggregation, not because it should replace an analytics engine at the workload DuckDB was designed to dominate. The embedded HTAP guide explains the mixed-workload boundary and the resource contention that comes with it.
Where a vector service still wins
A dedicated vector database is the right shape when the vector index must exceed one node, scale independently, serve many remote writers, or provide managed multi-region availability. MongrelDB’s embedded and single-node profiles remove a service boundary; they do not remove machine limits.
For desktop, edge, local RAG, agent memory, test harnesses, and services whose vectors belong transactionally with operational rows, an embedded vector database can be the simpler architecture.
Security and operations
Encrypted tables protect sorted-run pages, WAL frames, and persistent result-cache entries with AES-256-GCM. Passphrases derive keys through Argon2id and HKDF, raw high-entropy keys are supported, and HashiCorp Vault Transit can wrap the database root key. Searchable columns can derive equality and order-preserving range tokens, with the frequency and order leakage those techniques imply.
The optional daemon adds authenticated multi-process access, TLS, OIDC or SCRAM sign-in, a MySQL-compatible listener, replication, and cluster machinery. The public website recommends the embedded or single-node server profile first, because that path has the clearest qualification evidence; distributed capability exists, but deployment claims should follow tested operational evidence rather than architecture diagrams.
Who should evaluate it
MongrelDB is worth a fixture when an application needs several of these at once:
- durable operational writes and multi-table transactions;
- local columnar scans and DataFusion SQL;
- dense, sparse, substring, range, and equality retrieval in one row-identity model;
- encryption integrated with WAL and storage pages;
- embedded ownership with an optional daemon for multiple clients;
- native or HTTP access across the current 35-language client matrix.
It is not the conservative default for ordinary relational storage, the first choice for warehouse-only analytics, or the right service for a vector index that already needs a cluster. New database engines earn trust by narrowing claims, publishing the fixture, documenting unfinished surfaces, and being easy to remove after an evaluation; that is a less exciting pitch than “one database for everything,” and it is much closer to how production systems get chosen.