LatticeDB: a single-file embedded graph database with vector and full-text search

A new open-source project, LatticeDB, has landed on the Hacker News front page with a pitch its listing boils down to "SQLite, but for graph databases." According to the project's README on GitHub, it is an embedded property-graph database that keeps an entire dataset — graph structure, vector indexes and text indexes — in a single portable file, with no server process and no setup required.

One engine, three search modes

The engine's central claim is consolidation. Rather than running a graph store, a vector database and a full-text search service side by side, LatticeDB offers relationship traversal, HNSW vector similarity and BM25 keyword search over the same data through a single query layer. The syntax will look familiar to anyone who has used Cypher: MATCH patterns with WHERE, RETURN, ORDER BY and LIMIT clauses. Two operators extend it — a vector-distance comparison (<=>) and a full-text match (@@) — so one statement can find chunks near a query embedding, filter their parent documents by phrase, and then walk outward to the author node.

There is also an eventing story: durable named streams and a built-in graph changefeed share the same transaction and write-ahead-log path as ordinary graph writes, so an application can consume change events from the very file it queries.

Self-reported benchmarks

The README publishes latency figures from runs on an Apple M1, single-threaded, and includes a build command so others can reproduce them. Node lookups are quoted at 0.13 microseconds (roughly 7.9 million operations per second), node creation at 0.65 microseconds, and edge traversal at 9 microseconds. Vector search across one million embeddings reportedly completes in 0.83 milliseconds with full recall. These are the project's own numbers and have not been independently verified. Build commands referenced in the repository indicate the core engine is written in Zig.

Bindings and installation

LatticeDB ships client libraries for Python, TypeScript/Node.js and Go, plus a CLI installed via a one-line shell script. Published Python wheels and the npm package are expected to bundle the native library on supported platforms, while Go connects through a cgo workflow documented in the repo, including a runnable graph, vector and text retrieval example. The README also flags recent binding-surface cleanups that moved embedding helpers into dedicated modules, with a migration guide for the preferred imports.

Deliberate constraints

The design is local-first and single-writer: one owning process on one machine, with WAL-backed durability. There is no multi-client server mode, so concurrent access from separate processes is out of scope by design. The README is also careful about positioning — it names Graph RAG, agent memory and local knowledge tools as example workloads built on the engine's primitives, not the definition of what the database is for.

Why it matters

Retrieval-augmented generation and agent stacks typically assemble a vector store, a keyword index and, increasingly, a graph database — three services, three consistency stories, three things to operate. LatticeDB's bet is that for single-machine workloads all three can collapse into one file and one query language, much as SQLite collapsed relational storage into an embeddable library. If the published numbers hold up beyond the author's own benchmarks, that makes local knowledge tools and Graph RAG experiments dramatically cheaper to build and ship.

The caveats are real: this is a young project, the performance figures are self-reported, the single-writer model rules out shared multi-process deployments, and it enters a field where SQLite with extensions and purpose-built vector stores already serve many of these workloads. Still, applying the SQLite template to relationship-heavy, AI-adjacent data is a compelling idea, and the project's framing — primitives first, use cases second — suggests it is aiming at a general-purpose tool rather than a narrow RAG accessory.