LatticeDB makes a strong case for merging graph, vector, and text search into one file

LatticeDB is a single-file, embedded property-graph database written in Zig that combines graph traversal, HNSW vector similarity search, and BM25 full-text search under one Cypher-compatible query layer. The premise is simple and genuinely useful: stop routing the same dataset through three separate systems just because your queries have three different shapes.

The architecture is single-writer, local-first, and zero-config. One process opens one file. There is a write-ahead log for crash recovery, continuous backup by shipping changes to a directory, and a hot backup command that works without closing the database. Durable named streams with explicit consumer offsets share the same transaction path as graph writes, so you can build a changefeed off the graph without a separate message broker.

The benchmark numbers are specific and reproducible — the README tells you exactly which zig build command to run for each table. Node lookups land at 0.13 μs on an Apple M1, single-threaded. Ten-nearest-neighbor vector search across one million 128-dimensional vectors comes in at 0.83 ms mean with 100% recall@10, using HNSW with M=16 and ef_search=64. The graph traversal comparisons against SQLite are measured head-to-head on the same machine in the same harness; the Kuzu and Neo4j rows are explicitly flagged as third-party figures on different hardware, which is an honest disclosure you rarely see in a project README. At deeper traversal depths the gap against SQLite's recursive CTE widens dramatically — a 25-hop traversal that takes 587 ms in SQLite takes 318 μs here, a difference that traces to BFS with adjacency cache and bitset visited tracking versus CTE overhead that compounds with each recursion level.

The "when to use something else" section is worth reading carefully. The single-writer model is a real constraint: if multiple processes need concurrent writes, this is the wrong tool. OPTIONAL MATCH and CALL procedures are not yet implemented, so complex Cypher queries that depend on them will need Neo4j. The ecosystem is thin — no visualization dashboards, no admin tooling, no years of community resources. The README says this plainly rather than burying it.

Bindings exist for Python, TypeScript/Node, and Go, all wrapping a C API. The built-in hash_embed helper is a deterministic placeholder — the README is explicit that similar text does not produce nearby vectors, so it exists only to make examples runnable without an external embedding service. For anything where semantic similarity actually matters, you wire in Ollama or OpenAI via the built-in HTTP client.

The target workload is local applications that need relationship structure, semantic retrieval, and text search over the same data without running a server. Graph RAG and agent memory are mentioned as examples of what you can build on these primitives, not as the definition of the engine — a distinction the README draws deliberately. For that class of problem on a single machine, the combination of sub-millisecond vector search, sub-microsecond node lookups, and a unified query language is a genuinely different trade-off than stitching together SQLite, a vector store, and a search index.