Embedded hybrid search database: full-text, sparse, and vector retrieval

What hybrid search combines

Hybrid search is not simply “run vector search after full-text search.” Candidate generation, score normalization, fusion, filtering, and reranking each change recall and latency.

Embedded database with full-text and vector search

“Full-text search” can mean BM25-style term ranking, boolean token queries, phrase search, prefix search, or exact substring containment. Verify which operation an engine implements before comparing it with vector similarity.

SQLite FTS5 plus a vector extension can be a practical composition for an existing SQLite application. Another design combines a text index library and ANN library beside a transactional store. The cost is synchronization: inserts, updates, deletes, snapshots, and backups must remain coherent across every structure.

Fuse ranks without pretending scores share a scale

Cosine distance, sparse dot product, BM25, and literal matches do not share a meaningful numeric scale. Reciprocal-rank fusion combines result positions rather than raw scores and is a useful baseline when retrievers produce incomparable values.

RRF(document) = Σ 1 / (k + rank(document, retriever))

The constant k, each retriever's candidate depth, missing results, ties, and optional weights all affect output. Evaluate fusion against labeled queries rather than choosing defaults from an unrelated corpus.

MongrelDB's embedded hybrid search path

MongrelDB uses separate documented index semantics: HNSW, DiskANN, or IVF for ANN; a sparse inverted index for exact sparse dot-product top-k; an FM-index for exact substring candidates; Bitmap equality; learned ranges; and MinHash similarity. Every family returns RowIds.

Named retrievers can fuse through reciprocal-rank fusion, with optional exact-vector reranking over a bounded candidate window. SQL table functions include ann_search_scored, sparse_search_scored, and hybrid_search_scored.

Why one embedded engine can simplify updates

When source rows and retrieval structures live under one database, the engine can apply transaction, snapshot, delete, and recovery rules to one RowId space. That removes application-level replication between a row store, text engine, and vector service.

The tradeoff is resource coupling. ANN construction, sparse retrieval, SQL scans, and writes compete for the same process CPU, memory, and storage bandwidth. A single engine simplifies operations; it does not make mixed workloads free.

Hybrid-search evaluation plan

1. Create labeled queries for semantic, exact-term, identifier, and filtered cases.
2. Measure dense, lexical, and literal retrievers separately before fusion.
3. Record recall at each candidate depth and after authorization filters.
4. Test updates, deletes, and snapshot visibility during concurrent queries.
5. Inspect tail latency and candidate-cap events, not only median search time.
6. Keep a failure set showing which retriever rescued each query.

Embed or separate the search stack?

Embed when

• one product owns the local corpus;
• offline or edge operation matters;
• source data and search visibility must update together;
• operating several local services would add more risk than value.

Separate services when

• search traffic scales independently;
• specialist ranking pipelines need isolated compute;
• many applications share the same search service;
• managed high availability is required.