Ilia Bukin

LatticeDB is a new embedded, single-file property-graph database that bundles graph traversal, vector similarity, and full-text search into one engine and one query layer. It launched on Hacker News this week as a Show HN and drew 147 points and 38 comments within its first day¹. The pitch, in the author's words, is "like SQLite but for graph databases"¹.

The project's own tagline is a good summary: "Think SQLite, but for connected data you want to query by relationship, semantics, and text"².

One query, three search modes

The core idea is that you shouldn't have to bolt a vector store onto a graph database and a search index onto that. LatticeDB lets you write a single Cypher query that filters by embedding distance, matches full text, and traverses relationships in one pass. The README's example walks from a text chunk to its document to its author:

MATCH (chunk:Chunk)-[:PART_OF]->(doc:Document)-[:AUTHORED_BY]->(author:Person)
WHERE chunk.embedding <=> $query_vector < 0.3
  AND doc.content @@ "neural networks"
RETURN doc.title, chunk.text, author.name
ORDER BY chunk.embedding <=> $query_vector
LIMIT 10

MATCH (chunk:Chunk)-[:PART_OF]->(doc:Document)-[:AUTHORED_BY]->(author:Person)
WHERE chunk.embedding <=> $query_vector < 0.3
  AND doc.content @@ "neural networks"
RETURN doc.title, chunk.text, author.name
ORDER BY chunk.embedding <=> $query_vector
LIMIT 10

The <=> operator is vector distance, @@ is full-text match, and the MATCH clause handles the traversal. It's a deliberately small surface: a C API with Python, TypeScript, and Go bindings wrapping it, all built on a single portable file with no server and no configuration³.

The engine

LatticeDB is written in Zig with no dependencies and released under the MIT license⁴. It's designed for one owning process on one machine: an embedded single-writer model with a write-ahead log for durability⁵. The same transaction/WAL path that handles graph writes also feeds durable named streams and a built-in graph changefeed, so you can consume application events and graph changes from the same file³.

The author says the motivating use case was experimenting with agentic memory, treating related memories as graph traversals, essentially graph RAG as a local data store⁶.

The performance claims, with the caveats attached

The README publishes benchmarks run on an Apple M1, single-threaded: node lookups around 0.13 microseconds, 10-nearest-neighbor vector search over 1M vectors at about 0.83 ms with 100% recall, and full-text search around 19 microseconds⁵.

Those numbers deserve a skeptical read, and the project is fairly upfront about it. The graph-traversal comparisons against Kuzu and Neo4j are third-party figures from other posts on hardware and with methodology the author doesn't control, and only the SQLite comparison was measured head to head in the same harness⁵. The website is careful to say the same thing².

It's worth taking the headline numbers with a grain of salt for another reason: at least one HN commenter ran the included benchmark on an M4 Mac mini and got materially different traversal numbers than the README reports, still faster than SQLite but a far smaller gap⁷. Embedded-database benchmarks are notoriously sensitive to hardware, buffer settings, and graph shape, and this is a one-person project publishing its own numbers.

What it deliberately doesn't do

The README has a refreshing "when to use something else" section. It's not full Cypher: OPTIONAL MATCH and CALL procedures aren't implemented yet⁵. It's single-writer, so if you need many processes or clients writing to the same database over a network, it's the wrong tool⁵. And if your data is fundamentally tabular, a relational database is simpler and just as fast; graph databases pay off when relationships between records are the point⁵.

One thing to flag if you try the examples: the built-in hash_embed helper is a deterministic placeholder, not a real semantic embedding. Similar text won't produce nearby vectors, so a distance threshold is arbitrary and a similarity query may match nothing. The docs are explicit that you should use a real embedding model for anything where results should mean something⁵.

The backstory

The author, who goes by smiths1999 on HN, says they kept running into graph databases at work and found them painful to work with locally, so they set out to build something better¹. In the thread they're candid that they built much of it with LLMs (Claude and Codex) and that the experience reinforced their skepticism of superficial tests: suites would pass while the feature was clearly broken when actually used⁸.

The 0.10.0 release added durable property indexes the query planner can use, stricter write ownership, and storage that gives space back via lattice compact². It's early and lean, but it's a well-scoped answer to a real gap: a local, embedded database where connected, semantic, and textual data live in one file.

LatticeDB is an embedded graph database that wants to be SQLite for connected data

One query, three search modes

The engine

The performance claims, with the caveats attached

What it deliberately doesn't do

The backstory