Vector search usually arrives as a second system, which means the application writes the source row to one database, writes an embedding to another, and then spends the rest of its life pretending those writes happened together; the usual fixes are outbox tables, CDC consumers, retry queues, reconciliation jobs, and a dashboard that tells you how far the index is behind, all useful machinery when two systems are unavoidable, but unnecessary machinery when the workload fits inside one process.
MongrelDB takes the embedded route. The operational row, its dense embedding, its sparse representation, and the metadata used to filter it all live under one database transaction model, while HNSW, DiskANN, IVF, Bitmap, FM, Sparse, MinHash, and learned-range indexes resolve candidates through the same RowId space. That does not make a single-node engine the right answer for every vector workload, but it changes the failure model in a way that matters more than shaving another fraction from an isolated nearest-neighbour benchmark.
For a broader selection checklist, including when a separate vector service is the better answer, start with the embedded vector database guide.
What in-process actually buys
The first gain is the obvious one: no network request sits between the application and the index. A native Rust call, the Node NAPI addon, and the Python binding enter the engine directly; HTTP clients still exist for applications that need a warm multi-process owner, but local embedding does not pay for TCP, request routing, JSON encoding, authentication middleware, and response serialization on each operation.
The second gain is more important: source data and model-derived data share one transaction boundary. An application can update a document, its tenant, its timestamp, and its embedding as one commit, then query against a snapshot that sees either the old row or the new row rather than a row from now and an embedding from thirty seconds ago.
The ANN graph itself is derived state, not the authoritative copy of the row. MongrelDB can checkpoint and rebuild secondary indexes from durable table data, which is the right boundary for a graph whose shape can depend on insertion order and implementation details; the WAL protects authoritative changes, index generations publish atomically, and a damaged or obsolete generation can be rebuilt without inventing missing source vectors.
HNSW is one choice, not the schema
MongrelDB separates the ANN algorithm from the stored representation, because those are different decisions even when libraries like to bundle them into one checkbox.
The current supported combinations are:
| Algorithm | Representation | What it trades |
|---|---|---|
| HNSW | BinarySign | Compact 1-bit signs and Hamming distance, with lower memory use and approximate recall |
| HNSW | Dense | Full finite f32 vectors and cosine distance, with higher memory use |
| HNSW selector | Product quantization | Compact PQ codes and approximate ADC distance; the current backend is a flat PQ scan, not an HNSW graph |
| DiskANN | Dense | A bounded-degree graph and beam search |
| IVF | Dense | Centroid training plus a tunable number of probed lists |
Unsupported combinations fail at index creation rather than silently falling back to a different algorithm. Replacing Dense HNSW with another supported generation is an online build followed by a short publication barrier; the table is not rewritten, and the schema does not lie about which backend is serving candidates.
A native condition remains small:
Condition::Ann {
column_id: 6,
query: vec![0.10, 0.45, 0.78, 0.23],
k: 10,
}
The vector must match the column dimension and contain finite values. HNSW remains approximate, so production qualification compares sampled results against brute force rather than treating k = 10 as a promise that the mathematically closest ten rows always appear.
The point is the filters around the graph
A nearest-neighbour list is rarely the product query. The product query is closer to “find semantically similar documents for this tenant, created in the last ninety days, containing this exact identifier, excluding archived rows, then fuse dense and sparse relevance and rerank the best candidates exactly.”
MongrelDB handles that shape by making every index speak RowId. HNSW produces semantic candidates, Bitmap indexes enforce low-cardinality equality, PGM handles numeric or time ranges, FM handles exact substring containment, Sparse accepts SPLADE-style weighted terms, and MinHash supplies set-similarity candidates; hard filters reduce the candidate set, named retrievers fuse through deterministic reciprocal-rank fusion, and an optional final stage scores a bounded window against stored full-precision vectors.
SQL exposes scored table functions such as ann_search_scored, sparse_search_scored, and hybrid_search_scored. Trusted embedded SQL can also use the Boolean ANN predicate, while remote SQL requires the scored bounded path so deadlines, work ceilings, and candidate limits remain enforceable.
What the measurements do and do not say
The published BENCHMARKS.md records release-build measurements from one Linux x86-64 machine, including a 4.4828 microsecond accepted put without fsync, a 4.6721 millisecond durable commit, and 8.0387 milliseconds for Bitmap equality over one million rows. Those values describe the operational engine around the vector index; they are not HNSW latency numbers, and using them as though they measured ANN would be dishonest.
The ANN qualification suite currently asserts recall floors around 0.90 for Dense HNSW and 0.95 for BinarySign on its deterministic oracle data. A recall floor is a regression tripwire, not a universal quality forecast; corpus shape, embedding dimension, m, construction effort, search effort, filters, and the chosen distance representation all change the result.
The benchmark that matters is your own corpus with your own filters while writes are happening, because a graph that looks wonderful on an isolated random-vector test can still be the wrong database once memory, update rate, tenant isolation, and tail latency enter the room.
Where this shape stops working
If one ANN index already exceeds the memory and storage budget of a node, if dozens of remote writers need independent horizontal scaling, or if the vector workload needs managed multi-region failover, use a dedicated service built for that job. An embedded database removes an operational boundary; it does not repeal machine limits.
For desktop software, local RAG, agent memory, edge jobs, test harnesses, and single-node applications whose source rows and retrieval indexes belong together, the embedded boundary is often the simpler one, and the free MongrelDB Viewer gives that boundary a schema browser, SQL workbench, ANN maintenance surface, and MCP bridge without adding another server.