No server
Embedded package, no database service to operate.
One local database.
Five engines. Zero servers.
HybridDB gives AI apps durable on-disk rows, keyword search, vector retrieval, local analytics, and graph context from a single Python class — with git-like versioned tables, filters pushed into the vector scan, and a self-healing journal that keeps every derived index repairable.
HybridDB
pip install hybriddb v0.7.0 — Sep 2, 2026 What's new
On-disk
Persistent local data, not an in-memory cache.
Keyword + vector
Exact terms and semantic retrieval together, fused with RRF — with scalar filters pushed into the vector scan via where=, before it runs.
Analytics + graph
DuckDB OLAP plus NetworkX algorithms (PageRank, Louvain, shortest path) — mirrors built lazily, on first OLAP query.
Versioned tables
Git-like versioned tables (0.6.0): time-travel reads and update-heavy rollbacks with batched restores — up to 41× faster.
Pluggable embeddings
Default MiniLM from ChromaDB — no API key, no download. Or pass your own embedding_fn.
Why teams use it
Get AI data features without owning a mini data platform.
HybridDB is for teams that need local search and retrieval inside an app, not another production database cluster to deploy, monitor, secure, and synchronize.
Ship faster
Use one embedded package instead of wiring a database server, vector service, analytics store, and sync jobs.
Keep data local
Store app data on disk in the customer environment, on-device, or next to the agent runtime.
Reduce ops cost
Avoid running Postgres + pgvector, Milvus, and ClickHouse for local-first AI features that do not need a cluster.
Trust the index
Backups, SQL export/import, integrity checks, and reindexing make derived search state repairable.
SQLite + sqlite-vec
Great for rows and full-text; vectors, graphs, and analytics arrive as bolted-on extensions with no unified API. HybridDB ships all five engines behind one interface — with versioning and self-healing none of them offer.
DuckDB alone
DuckDB is analytics-first — it is not a transactional app store with FTS and vector retrieval. HybridDB uses DuckDB for OLAP and pairs it with rows, search, and graphs, mirroring tables lazily so unused engines cost nothing.
Postgres + pgvector
Excellent for server-side app data. HybridDB is lighter when an embedded app needs rows, keyword search, vectors, analytics, graph context, and local repair tools without operating Postgres.
ChromaDB alone
ChromaDB is excellent at vector similarity — it's literally what HybridDB uses under the hood. But it has no rows, no full-text, no OLAP, no graph context, and no versioned tables. HybridDB keeps Chroma as one engine among five, adding metadata pre-filtering, durability, and repair around it.
No shade: we love those open-source projects and use them every day.
Developer shape
Install one package. Keep the technical path simple.
When you do need the details, the API stays concrete: create a table, insert rows, search, then verify or rebuild indexes.
Install Start with one package
pip install hybriddb
from hybriddb import HybridDB, LONGTEXT, TEXT
db = HybridDB("./my_data") Write Create tables and insert rows
db.create_table("docs", {
"title": TEXT,
"body": LONGTEXT,
})
db.insert("docs", {
"title": "Gmail OAuth bug",
"body": "Refresh token failed during sync",
}) Search Retrieve with hybrid + recency ranking
from hybriddb import HYBRID
results = db.search(
"docs", "body", "gmail token refresh",
mode=HYBRID,
recency_weight=0.3,
recency_column="updated_at",
) Graph Graph-aware semantic retrieval
db.register_entity_node("docs", id_column="id")
db.register_edge_rule("docs", "docs", target_match="parent_id")
results = db.search_graph_ppr(
"oauth refresh failure",
k_seeds=8,
) Maintain Check health and reconcile
report = db.health("docs")
db.reconcile("docs")
sizes = db.stats()
db.reindex("docs") How it works
Truth stays simple. Derived indexes stay rebuildable.
HybridDB is not a pile of databases. It is a local data flow where SQLite owns truth and every retrieval layer can be regenerated from the write journal.
01
App writes rows
Agents and apps write ordinary structured records into SQLite-backed tables.
02
Journal records change
Every write is journaled so secondary indexes can be replayed, repaired, and verified.
03
Indexes catch up
FTS5, ChromaDB, optional DuckDB, and NetworkX graph projections update from the same local truth.
04
Self-healing
db.health() reports index drift; db.reconcile() replays the journal and repairs derived state after a crash.
Architecture
Local engines and maintenance tools behind one agent data layer.
Each component has a narrow job. The source data remains inspectable while retrieval, analytics, and graph projections evolve independently.
SQLite
Source of truth for rows, schemas, transactions, and the repair journal.
FTS5
Exact keyword retrieval for names, emails, titles, and high-signal terms.
ChromaDB
Persistent vector collections for semantic recall over long text fields.
DuckDB
Optional columnar analytical queries via the hybriddb[analytics] extra.
NetworkX graph
Nodes, edges, PageRank (with personalization), Louvain communities, shortest path via the hybriddb[graph] extra.
Built-in repair layer
SQL export/import, backup/restore, integrity checks, stats, vacuum, reindex, health(), and reconcile().
Built for
Local AI apps that need data they can inspect.
Long-running agent systems that need durable, searchable local state.
Email caches and knowledge bases that need keyword and semantic retrieval with recency-weighted scoring.
App-builder tables created and queried by agents at runtime, sync or async.
Local analytics over agent activity without exporting data.
Entity and provenance graphs with graph-aware retrieval via search_graph and Personalized PageRank (search_graph_ppr).
FAQ
Clear boundaries make the product easier to understand.
What is HybridDB?
HybridDB is an embedded data layer that unifies rows, full-text search, vector embeddings, graphs, and OLAP analytics in a single local store — one DataLayer API over SQLite + FTS5, ChromaDB, NetworkX, and DuckDB, with no server to run.
Is HybridDB a vector database?
No. It uses vector search as one layer, alongside rows, FTS, analytics, and graph context. You get hybrid keyword + vector retrieval without adopting a separate vector service.
Does HybridDB require a server or cloud?
No. HybridDB is embedded — it runs in-process on your machine. There is no server to deploy, no connection strings, and no external infrastructure.
Is HybridDB free and open source?
Yes — MIT-licensed under the Open Assistants Lab. It runs entirely on your machine with no cloud services and no paid tiers.
How is HybridDB different from using SQLite or DuckDB alone?
SQLite gives you rows and FTS5 full-text; DuckDB gives you analytics; neither does vectors or graphs out of the box. HybridDB combines all four engines behind one API, with cross-engine queries, health checks, and reconciliation built in.
Can I use HybridDB for RAG and semantic search?
Yes. HybridDB stores vector embeddings alongside rows and full-text indexes, so you can do hybrid keyword + vector retrieval — the same pattern CoreMem uses for zero-LLM recall.
What are HybridDB's system requirements?
HybridDB is a Python library with no GPU requirement. It runs on any machine that runs Python — laptops included — and stores everything in local files.
Is my data locked into HybridDB?
No. Rows live in a standard SQLite file you can open with any tool, and the derived indexes (FTS, vectors, graph, analytics) are rebuildable from that source of truth at any time — the self-healing journal exists precisely so nothing is unrecoverable.
Embedded · Local · MIT
Give your AI app one local data layer.
Start with SQLite-shaped records, then add keyword search, semantic retrieval, optional analytics, graph context, and repairable indexes without introducing external infrastructure.