LatticeDB puts graph, vector and text search in one local file

Jeff Hajewski released LatticeDB 0.11.1 on August 25, 2026, an open-source Zig database that combines graph traversal, vector similarity, and full-text search in one local file, targeting local AI applications. The patch follows the substantive 0.11.0 release on August 24, 2026, and the project remains in alpha stage, with Hajewski as sole maintainer.

LatticeDB puts graph, vector and text search in one local file Jeff Hajewski's Zig database targets local AI apps; an August 24th correctness release shows how early the project remains. By Ryan Merket /author/ryan-merket · Published Primary source: GitHub https://github.com/jeffhajewski/latticedb Why it matters Local AI apps often assemble a graph database, vector store and text index. Hajewski is testing whether one embedded file can replace that stack, with alpha-stage risks still visible. Jeff Hajewski https://jeffhajewski.com/?ref=runtimewire released LatticeDB 0.11.1 https://github.com/jeffhajewski/latticedb/releases/tag/v0.11.1?ref=runtimewire on August 25th, putting a fresh version number on an open-source database that combines graph traversal, vector similarity and full-text search in one local file. The patch changes package metadata and leaves the code untouched. The substantive 0.11.0 release arrived on August 24, 2026; GitHub's release page https://github.com/jeffhajewski/latticedb/releases?ref=runtimewire lists 0.11.1, released August 25, 2026, as the latest version. LatticeDB 0.11.1 release notes https://raw.githubusercontent.com/jeffhajewski/latticedb/main/docs/release notes 0.11.1.md?ref=runtimewire LatticeDB's homepage https://latticedb.org/?ref=runtimewire describes the architecture underneath that patch: an embedded property-graph database that gives local applications one engine for relationships, semantic retrieval and keyword search. Hajewski is pitching the operational simplicity associated with SQLite for data whose connections matter as much as its individual records. LatticeDB repository https://github.com/jeffhajewski/latticedb?ref=runtimewire Hajewski's personal site https://jeffhajewski.com/?ref=runtimewire lists earlier roles at Noom, Salesforce, Google and Citrix. He completed a computer science PhD at the University of Iowa in 2020, where his research focused on distributing machine-learning workloads and automating neural-network design. At Salesforce, he built infrastructure for evaluating natural-language-processing models against customer email data; at Noom, he worked on a machine-learning platform for running model evaluations over a large data lake. University of Iowa alumni profile https://cs.uiowa.edu/alumni/profiles?ref=runtimewire That background maps directly onto LatticeDB's scope. Hajewski is building storage infrastructure around three retrieval patterns that AI applications frequently need at the same time, then stripping away the server deployment that usually accompanies them. One file, three retrieval modes LatticeDB https://github.com/jeffhajewski/latticedb?ref=runtimewire is written in Zig and distributed under the MIT license. It stores a property graph in a portable file and uses a write-ahead log for durability. Applications can traverse nodes and edges, run HNSW vector searches and execute BM25 full-text queries through the same Cypher-oriented query layer. LatticeDB also includes ACID transactions, property indexes, durable streams and a graph changefeed. LatticeDB repository https://github.com/jeffhajewski/latticedb?ref=runtimewire Hajewski has exposed LatticeDB through a command-line interface and bindings for Python, TypeScript and Node.js, Go and C. The Python package https://pypi.org/project/latticedb/?ref=runtimewire supports Python 3.9 and later, while the repository includes installation paths for the other bindings. PyPI identifies Hajewski as the sole maintainer and classifies the package as alpha software. PyPI https://pypi.org/project/latticedb/?ref=runtimewire The local-first design gives LatticeDB a clear job. A document application could keep entities and citations as a graph, embeddings in a vector index and document text in a keyword index without coordinating three services. An AI agent could query relationships, semantic similarity and source text against the same transactional state. Hajewski is already using that substrate in Quipu https://github.com/jeffhajewski/quipu?ref=runtimewire , a separate research project for evidence-backed agent memory with temporal facts and deletion controls. Quipu repository https://github.com/jeffhajewski/quipu?ref=runtimewire The design also sets hard limits. LatticeDB expects one process to own the file and follows a single-writer model. It does not provide sharding, replication or distributed queries, and its Cypher implementation omits features including OPTIONAL MATCH and CALL procedures. LatticeDB's own documentation directs applications that need multiple networked writers, full Cypher support or a mature operating toolset toward systems such as Neo4j or PostgreSQL. LatticeDB repository https://github.com/jeffhajewski/latticedb?ref=runtimewire The benchmark numbers need context LatticeDB reports a 0.13-microsecond node lookup and a mean 0.83-millisecond nearest-neighbor search across 1 million vectors, with 100% recall. LatticeDB repository https://github.com/jeffhajewski/latticedb?ref=runtimewire Those figures come from LatticeDB's own benchmark suite. The repository's comparison table also draws measurements for competing systems from different sources, configurations and hardware. The numbers establish Hajewski's performance target and provide a reproducible starting point, rather than an independently controlled ranking against Neo4j, SQLite, Weaviate or other databases. LatticeDB repository https://github.com/jeffhajewski/latticedb?ref=runtimewire The release history shows the cost of moving fast LatticeDB has accumulated 420 commits, and its Python releases date back to February 20, 2026 https://pypi.org/project/latticedb/?ref=runtimewire . Version 0.11.0, released August 24th, fixed several fundamental query-correctness failures. Compound WHERE clauses joining comparisons could fail because boolean operators had the wrong precedence. Subtraction and unary negation did not parse. Left-pointing relationship patterns silently returned no rows. Python and TypeScript also forced db.query into read-only transactions, preventing writes through that interface. LatticeDB 0.11.0 release notes https://raw.githubusercontent.com/jeffhajewski/latticedb/v0.11.0/docs/release notes 0.11.0.md?ref=runtimewire Hajewski's release notes document the causes and affected behavior in detail. Version 0.11.1 then corrected the homepage and documentation links embedded in the PyPI artifacts, which required another release because registry metadata could not be edited after upload. LatticeDB 0.11.1 release notes https://raw.githubusercontent.com/jeffhajewski/latticedb/main/docs/release notes 0.11.1.md?ref=runtimewire That sequence is useful evidence of both pace and maturity. Hajewski is shipping a broad database surface with graph storage, transactions, multiple indexes, a query language and four binding options. PyPI's alpha label remains appropriate while foundational query behavior is still being corrected. Embedded graphs are getting crowded LatticeDB is entering an active field of embedded graph projects. LadybugDB https://ladybugdb.com/?ref=runtimewire positions itself as a columnar graph database for analytical workloads, with Cypher support and commercial contracts. GraphLite https://github.com/GraphLite-AI/GraphLite?ref=runtimewire uses Rust and centers its interface on the ISO Graph Query Language standard. Both borrow the SQLite or DuckDB deployment idea: place graph capabilities inside an application and remove the separate database server. LadybugDB https://ladybugdb.com/?ref=runtimewire ; GraphLite https://github.com/GraphLite-AI/GraphLite?ref=runtimewire LatticeDB's sharper distinction is the combination of graph traversal, HNSW vectors and BM25 text retrieval behind one query layer. That combination fits local knowledge tools and agent memory systems where each retrieval mode needs access to the same records and transaction boundaries. LadybugDB emphasizes columnar graph analytics, while GraphLite emphasizes standards-based graph querying. LatticeDB repository https://github.com/jeffhajewski/latticedb?ref=runtimewire Hajewski's distribution bet is straightforward: package the database as a library, support the languages application developers already use and let a file replace several pieces of local infrastructure. LatticeDB still has to earn trust through correctness, compatibility and production use. Its architecture is coherent, its limits are stated plainly, and its maintainer is publishing the uncomfortable bugs alongside the benchmark wins.