Glonce

LatticeDB combines graph, vector and text search in one file

toolsThe Glonce editorsHacker News🔥64Glonce rating64Impact55Novelty60Relevance85Surprise45Players20Credibility80
LatticeDB combines graph, vector and text search in one file

LatticeDB is a new embedded, single-file property-graph database posted to GitHub with CLI, Python, TypeScript/Node.js and Go bindings. It puts graph traversal, HNSW vector similarity search and BM25 full-text search behind one Cypher-like query language, with a vector distance operator (<=>) and a full-text operator (@@) usable in the same query. The design goal is a zero-configuration, single-writer database for one local machine rather than a server you connect to. Installation is a curl script for the CLI, pip install latticedb for Python, npm install @hajewski/latticedb for Node, and cgo bindings for Go. The project's own benchmarks, run on a single-threaded Apple M1 with an auto-scaled buffer pool, report 0.13 microsecond cached node lookups; a B+Tree it says matches RocksDB's in-memory performance and beats SQLite on disk by 23x; and, at 1 million vectors, a mean vector search latency of 0.83 milliseconds with 100% recall at 10 (HNSW configured with 128-dimensional cosine vectors, M=16, ef_construction=200, ef_search=64, k=10), which the docs describe as scaling sub-linearly with 99 to 100% recall@10 as the dataset grows. Connection page packing in the vector index is said to cut memory use by about 4.5x. The BM25 full-text index is said to run about 300x faster than SQLite's FTS5 and to be competitive with Tantivy, a dedicated Rust search library. The project is explicit about the limits of these comparisons: only the SQLite numbers are measured head to head on the same machine in the same test harness, while the Kuzu and Neo4j figures are pulled from third-party posts on different hardware with methodology LatticeDB does not control, and it tells readers to treat those as order-of-magnitude orientation rather than a real benchmark result. Separate graph benchmarks compare LatticeDB with SQLite at a small scale (10K nodes, 50K edges), a medium scale (100K nodes, 500K edges), and on a depth-limited traversal (10K nodes, 50K edges); the source text gives only the dataset sizes for these three sections, not the measured latency numbers. For the traversal case specifically, LatticeDB uses breadth-first search with an adjacency cache and bitset visited tracking, SQLite uses a recursive common table expression with UNION deduplication, and both reach the same set of about 8,000 reachable nodes, with the gap between them widening at greater depth because SQLite's CTE overhead grows at every recursion level. Beyond search, LatticeDB offers ACID transactions with crash recovery, MERGE/WITH/UNWIND and aggregation functions, variable-length graph paths, a write-ahead log, continuous backup that can restore to a point in time, hot backup without closing the database, durable named event streams with a graph changefeed, and background compaction to reclaim space. In the code examples, similarity search runs on a built-in helper called hash_embed (hashEmbed in the JS binding, HashEmbed in Go); the documentation flags this helper as a deterministic placeholder rather than a real semantic embedding, meaning similar text does not land near similar vectors and a similarity query built on it can return nothing useful, and points users toward a real embedding model instead, with the vector feature list also mentioning a built-in HTTP client for Ollama or OpenAI. The listed use cases are connected local data such as notes, documents, catalogs and citation graphs, local knowledge tools that need graph structure without a separate server, and prototyping as a lighter alternative to Neo4j or Weaviate; agent memory and RAG pipelines are named as one example class of workload the graph/vector/text combination supports, not the reason the engine exists. The source text names no author, company, software license or version number for the project; the GitHub path (jeffhajewski) and the npm package scope (@hajewski) only hint at an identity without stating one in prose, and the page does not say how long the project has been in development or whether it is meant for production use.

Key facts

  • LatticeDB is a single-file embedded graph database that runs graph traversal, HNSW vector search and BM25 full-text search through one Cypher-like query language, with bindings for CLI, Python, TypeScript/Node.js and Go.
  • Benchmarked single-threaded on an Apple M1, it reports 0.13 microsecond cached node lookups, a claimed 23x edge over SQLite on disk, and 0.83 millisecond mean vector search latency at 1 million vectors with 100% recall@10.
  • The BM25 full-text index is said to run about 300x faster than SQLite's FTS5 and to be competitive with the dedicated Tantivy search library, with roughly 4.5x memory savings claimed for the vector index from connection page packing.
  • Only the SQLite comparisons are measured head to head in the project's own test harness; the Kuzu and Neo4j figures come from third-party posts on different hardware, which the project itself says should be read as order-of-magnitude orientation, not a benchmark result.
  • The example embedding helper, hash_embed, is a non-semantic placeholder that can make similarity search return nothing useful, and the source text names no author, company, license or version for the project.

Why it matters

Local-first apps that need to combine relationships, semantic search and keyword search today usually stitch together a graph library, a vector index and a text search engine, or bolt vector and full-text extensions onto SQLite. LatticeDB's pitch is doing all three inside one embedded, single-file engine with one query language, so a developer building something like a personal knowledge base or an agent's memory store does not have to keep three systems in sync.

Who it affects

Developers building local-first tools such as note apps, citation or entity graphs, and agent memory or RAG pipelines are the direct audience, since those are the use cases the project names. It also positions itself as a lighter alternative to running a full Neo4j or Weaviate server for prototyping on a single machine.

How to use it

The database ships as a single file with zero required configuration: install via a curl script for the CLI, pip install latticedb for Python, npm install @hajewski/latticedb for Node.js, or the Go bindings via cgo, then open the file and start writing Cypher-like queries with the <=> vector operator and the @@ full-text operator. The code examples default to the built-in hash_embed helper, which is explicitly a non-semantic placeholder; for search results that need to mean something, the project points to plugging in a real embedding model, and lists a built-in HTTP client for Ollama or OpenAI among its vector features.

How solid is it

The performance numbers come entirely from the project's own documentation, run single-threaded on an Apple M1 with an auto-scaled buffer pool. The project itself draws a line around what its benchmarks actually show: only the SQLite comparisons are measured head to head on the same machine in the same harness, while the Kuzu and Neo4j figures are third-party numbers on different hardware with uncontrolled methodology, which it says should be read as order-of-magnitude orientation rather than a real benchmark. The three graph-scale benchmark sections in the source text give dataset sizes but not the measured results themselves. As a Show HN post, it had drawn 149 points and 38 comments within its first day, which reflects community attention rather than independent verification of the claims.

Risks and caveats

The source text states no software license, no version number, and no author or company name for the project; the GitHub path and npm package scope only imply an identity without naming one in prose, and there is no statement on how long the project has been developed or whether it is meant for production use. The default embedding helper used in every code example is a deterministic placeholder, not a real embedding model, so copying the examples as-is for actual semantic search can silently return irrelevant or empty results. Most of the headline performance multiples rest on comparisons the project ran itself or on numbers it explicitly says it cannot vouch for.

“Only the SQLite rows are measured head to head on the same machine in the same harness. The Kuzu and Neo4j figures come from third-party posts on hardware and with methodology we do not control, so treat them as order-of-magnitude orientation rather than a benchmark result.”

— LatticeDB documentation