Local-first database layer

One local data layer
instead of a data stack.

HybridDB gives AI apps durable on-disk rows, keyword search, vector retrieval, local analytics, graph context, and repairable indexes without running Postgres + pgvector, Milvus, and ClickHouse for every local workload.

HybridDB v0.4.2 Python 3.11+
HybridDB pip install hybriddb
Why it matters See the API
Hybrid DB SQLite + FTS5 Rows · Full-text ChromaDB Vectors · Semantic DuckDB Analytics · OLAP Graph Traversal · Rank
dns

No server

Embedded package, no database service to operate.

hard_drive

On-disk

Persistent local data, not an in-memory cache.

manage_search

Keyword + vector

Exact terms and semantic retrieval together.

account_tree

Analytics + graph

Local aggregates, entities, and relationships.

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.

rocket_launch

Ship faster

Use one embedded package instead of wiring a database server, vector service, analytics store, and sync jobs.

lock

Keep data local

Store app data on disk in the customer environment, on-device, or next to the agent runtime.

savings

Reduce ops cost

Avoid running Postgres + pgvector, Milvus, and ClickHouse for local-first AI features that do not need a cluster.

verified

Trust the index

Backups, SQL export/import, integrity checks, and reindexing make derived search state repairable.

Instead of operating

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.

Instead of operating

Milvus

Excellent for distributed vector scale. HybridDB fits smaller local workloads where keyword matches, structured rows, and semantic search need to live together.

Instead of operating

ClickHouse

Excellent for large analytical systems. HybridDB gives local apps practical analytics over their own data without exporting into a warehouse pipeline.

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 ranking 
from hybriddb import HYBRID

results = db.search(
    "docs", "body", "gmail token refresh",
    mode=HYBRID,
)
Maintain Export, check, and rebuild 
db.export_sql("backup.sql")
report = db.check_integrity()
sizes = db.stats()

db.reindex("docs")
Read the 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
edit_square

App writes rows

Agents and apps write ordinary structured records into SQLite-backed tables.

02
receipt_long

Journal records change

Every write is captured so secondary indexes can be replayed, repaired, and verified.

03
hub

Indexes catch up

FTS5, ChromaDB, optional DuckDB, and graph tables are updated from the same local truth.

04
travel_explore

Agents query one API

Keyword search, semantic recall, graph traversal, and maintenance APIs are exposed together.

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.

Graph tables

SQLite-backed nodes and edges for provenance, entities, and dependencies.

Built-in repair layer

SQL export/import, backup/restore, integrity checks, stats, vacuum, and reindex.

Built for

Local AI apps that need data they can inspect.

check_circleLong-running agent systems that need durable, searchable local state.

check_circleEmail caches and knowledge bases that need keyword and semantic retrieval.

check_circleApp-builder tables created and queried by agents at runtime.

check_circleLocal analytics over agent activity without exporting data.

check_circleEntity and provenance graphs for explaining why something was remembered.

FAQ

Clear boundaries make the product easier to understand.

Is HybridDB a vector database?

No. It uses vector search as one layer, alongside rows, FTS, analytics, and graph context.

Where is the source of truth?

SQLite owns transactional app data. DuckDB is an optional local analytics mirror.

Does it require a server?

No. HybridDB is designed as an embedded local data layer for Python agent apps.

What is it not for?

It is not a distributed OLTP database, hosted vector service, or hardened SQL sandbox.

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.

Install HybridDB