The embedded stack is five separate databases — HybridDB is one file

The 2026 embedded-data conversation is a tier list: sqlite-vec for vectors-in-SQLite, LanceDB for production ANN, KùzuDB for graphs, DuckDB for analytics, FTS5 for search. Each is excellent at its one thing. The problem is that an agent’s working data is all of those things at once — and wiring five engines together means owning schema creation, index triggers, sync jobs, crash recovery, and drift repair yourself.

HybridDB’s bet is that the unification is the feature: five engines, one file, one API, indexes that heal themselves, and — since 0.6.0 — history you can verify. This post is the measurement behind that bet, and where we concede to the specialists.

Search accuracy — our measured baseline

Real IR benchmarks (BEIR), graded relevance, ChromaDB’s bundled MiniLM:

Dataset	keyword	semantic	hybrid (RRF)
NFCorpus (3,633 docs)	nDCG@10 0.308	0.315	0.343
SciFact (5,183 docs)	nDCG@10 0.668	0.648	0.703

Hybrid fusion beats both single modes on every metric in both domains (+11% nDCG over keyword on NFCorpus, +5% on SciFact). The fusion weight is 0.5 and the curve is flat — no tuning. Full table in the Benchmarks docs.

Analytics — where the specialist almost wins

The honest caveat: for pure analytics, DuckDB standalone is the specialist and HybridDB uses DuckDB under the hood — with one difference: the mirror is kept in sync by the journal instead of by you.

Rows	Query	SQLite (raw)	DuckDB mirror	Speedup
10k	group-by	3.42ms	0.47ms	7.3×
1M	full-scan agg	70.98ms	1.23ms	57.6×
1M	filtered agg	76.86ms	0.22ms	351.9×
1M	join	640.17ms	8.45ms	75.8×

Mirrors are created lazily on first OLAP use (tables you never query cost nothing to maintain), and sync overhead is within noise on the write path.

What no specialist gives you

Versioned, tamper-evident history. Since 0.6.0, any table can opt into an append-only hash chain — every insert/update/delete recorded, as_of(seq) reads, named checkpoints, rollback that records re-applied state instead of erasing it (audit trails stay complete), verify_chain() that detects direct tampering. Agent memory and session logs are the use case this was built for.

The self-healing journal. All vector/analytics mutations are journaled in SQLite; on crash the journal replays pending entries on startup — no ghosts, no drift. health() and reconcile() report and repair divergence. The specialists assume you keep them in sync; HybridDB makes sync its internal invariant.

Five engines behind one schema. LONGTEXT columns automatically get FTS5 + vector; scalar columns mirror into Chroma metadata and filter inside the ANN scan (where= pushdown, v0.7.0); the same row is queryable by keyword, vector, SQL, OLAP, and graph — with one primary key identity across all of them (v0.8.0).

Where we concede

• Pure ANN scale: LanceDB-class engines with disk-based indexes win if you need billions of vectors. HybridDB’s vector layer is Chroma embedded — tuned for agent-scale stores.
• Pure OLAP: if you never query with keyword/vectors, just use DuckDB.
• Pure graph: KùzuDB has years of graph-optimization head start; NetworkX-backed algorithms here are about context for retrieval (PageRank-expanded neighbors of vector seeds), not graph-at-scale.

The positioning is honest: we don’t compete with the specialists at their specialty. We compete at the workload that needs all five consistent — which is most agent applications. Point lookups, hybrid search, per-user stores, versioned memory, and analytics over the same file.

The numbers, reproducible

The full performance study is in docs/PERFORMANCE.md (BEIR tables, mirror maintenance costs, write-path notes), with benchmark commands in the docs: uv run python -m pytest tests/benchmarks -q --run-benchmarks. Smoke runs complete in minutes; full-scale exists for those who want it.