LatticeDB

LatticeDB is an open-source, single-file embedded property-graph database written in Zig, created by Jeff Hajewski and released under the MIT License. It combines relationship traversal, HNSW vector similarity search, and BM25 full-text search in one local engine and one Cypher query layer — with no server, no configuration, and no external dependencies. The project reached v0.14.0 as of August 2026 and has accumulated over 500 GitHub stars since its creation in December 2025.

What It Is

LatticeDB is a local-first, embedded graph database designed for workloads where relationships, semantics, and text all matter at once. Think of it as SQLite for connected data: your entire database lives in a single portable file, opened by one owning process. The engine supports ACID transactions with write-ahead log durability, a Cypher query language subset, durable named streams with graph changefeeds, and property equality indexes the query planner can use. It is built for single-machine, single-writer workloads — not distributed or multi-client deployments.

Architecture and Performance

LatticeDB is built in Zig with zero external dependencies. Its storage layer uses a B+Tree with overflow pages for large properties, a BFS adjacency cache with bitset visited tracking for graph traversal, an HNSW index with heuristic neighbor selection and connection page packing for vector search, and a BM25 inverted index with tokenization, stemming, and fuzzy Levenshtein matching for full-text search.

Benchmarks run on Apple M1 (single-threaded, auto-scaled buffer pool) show:

• Node lookup: 0.13 µs (7.9M ops/sec)
• 10-NN vector search at 1M vectors: 0.83 ms mean, 100% recall@10
• 2-hop graph traversal (100K nodes): 39 µs vs. 548 µs for SQLite recursive CTE (14x faster)
• Full-text search (100 docs): 19 µs (~300x faster than SQLite FTS5 per the README)

The README notes that only the SQLite comparison rows are measured head-to-head on the same machine; figures for Neo4j, Kuzu, Weaviate, and Qdrant come from third-party published sources and should be treated as order-of-magnitude orientation.

Query Model: One Query, Three Search Modes

A single Cypher query can combine all three retrieval modes simultaneously. The vector distance operator (<=>) and full-text operator (@@) are first-class citizens in WHERE clauses alongside standard graph MATCH patterns. This means a query can filter chunks by embedding similarity, filter their parent documents by keyword, and traverse to authors — all in one statement. Built-in hash_embed helpers let examples run without an external embedding service; for production use, the engine includes an HTTP client for Ollama and OpenAI embeddings.

Language Bindings and Installation

LatticeDB exposes a clean C API and ships bindings for Python, TypeScript/Node.js, and Go:

• Python: pip install latticedb — published wheels bundle liblattice
• TypeScript: npm install @hajewski/latticedb — published tarballs bundle liblattice
• Go: cgo workflow via pkg-config; -tags repolocal for in-repo development
• CLI: install script via curl for shell-level access and the lattice compact / lattice backup commands

Source builds require only Zig (zig build).

Update: v0.14.0 (August 2026)

The latest GitHub release is v0.14.0, published August 26, 2026. The README documents a release history going back to v0.8.0, with notable milestones including:

• v0.10.0: Durable property indexes used by the query planner, strict single-writer ownership (contention error instead of racing), and B+Tree delete rebalancing with lattice compact for physical space reclamation
• v0.11.x: Durable named streams and graph changefeeds stored in system B+Trees, per-stream sequences, and explicit consumer offsets
• v0.14.0: Current release (full changelog in repo release notes)

The project direction signals continued investment in the embedded graph-plus-retrieval substrate, with the README explicitly positioning Graph RAG, agent memory, and local knowledge tools as example workload classes rather than the engine's definition.

When Not to Use It

The README is candid about limitations: LatticeDB is not suitable for multi-writer or multi-client network deployments, purely tabular data, multi-machine scaling, workloads requiring the full Cypher spec (e.g., OPTIONAL MATCH, CALL procedures), or teams that need mature operational tooling and ecosystem depth. For those cases, the README points to Neo4j, PostgreSQL, Dgraph, or managed services.