Jeff Hajewski launched LatticeDB on Tuesday, an open-source embedded database that merges graph traversal, vector search, and full-text indexing into a single file. The project ships under an MIT license and runs without dependencies, written entirely in Zig.
The timing reflects a broader shift in how developers are thinking about data storage for AI applications. LatticeDB targets a specific niche: programmers who need to query connected data locally without spinning up a server. "Think SQLite, but for connected data you want to query by relationship, semantics, and text," the project site explains.
What makes LatticeDB unusual is its architecture. Most graph databases require a client-server setup. This one embeds directly into applications via pip, npm, or Go. Everything lives in a single database file with a write-ahead log, offering ACID transactions through a single-writer, multi-reader model. The database includes a changefeed that logs node and edge mutations to a reserved stream, which means applications can subscribe to graph changes without polling.
Three search engines, one query layer
The technical stack combines graph traversal, HNSW vector search, and BM25 full-text search under a Cypher-style query language. Developers familiar with Neo4j will recognize the syntax, though Hajewski has implemented only a subset of Cypher. OPTIONAL MATCH and CALL procedures aren't supported yet, according to the comparison documentation.
The query layer introduces custom operators: <=> for vector distance and @@ for full-text matching. Variable-length path queries work, as do multi-hop traversals. The vector search runs on an HNSW index with configurable M and ef parameters. Full-text search relies on a BM25 inverted index with stemming, tokenization, and Levenshtein fuzzy matching baked in.
LatticeDB's published benchmarks report node lookups in 0.13 microseconds and 10-nearest-neighbor vector search at one million vectors in 0.83 milliseconds with 100% recall. Graph traversals allegedly run 14× to 2,819× faster than SQLite with recursive CTEs, though those figures come with caveats about specific hardware and harness configurations.
Hajewski cautioned that the benchmarks show "how much depth costs you" in graph queries rather than proving blanket superiority. That framing feels more honest than typical startup marketing.
A solo project born from frustration
Hajewski works on AI infrastructure at SAP. Before that, he held roles at Noom, Salesforce, Google, and Citrix, according to his personal site. He started building LatticeDB after growing frustrated with existing graph databases during local development work.
"We have been using graph DBs more and more at work," Hajewski wrote in the Show HN thread on Tuesday. "I found them painful to work with locally and decided to try and build something better."
The project is entirely his effort. "Lattice is just me," he wrote when users compared LatticeDB to venture-backed alternatives. That admission shifts the context. This isn't a well-funded team racing to capture market share but an individual engineer scratching his own itch.
Hajewski mentioned one motivating use case: "experimenting with agentic memory," the concept of AI agents storing and retrieving relational data about past interactions. That use case aligns with the current wave of AI agent development across the industry.
Where it fits among alternatives
LatticeDB competes in the embedded graph database category alongside LadybugDB, which succeeded Kùzu after that project archived in October 2025. Users have also mentioned DuckDB's duckpgq extension, which allows graph querying over tabular data, as a contrasting option.
Hajewski drew a clear line between his project and DuckDB's extension. Use "duckpgq if you have tables you want to traverse like a graph sometimes, latticedb when graph traversal is the primary mechanism of querying," he explained on Hacker News. That distinction matters for developers evaluating tools.
The database differentiates itself from Neo4j by running embedded rather than requiring a server, and from vector-only databases like Weaviate by including native graph traversal alongside semantic search. The documentation argues that LatticeDB's integrated approach beats stitching together SQLite with separate extensions for full-text search and vector operations, though that claim depends heavily on the workload.
Rapid iteration in public view
The database shipped Python bindings to PyPI on July 23 as version 0.10.0, TypeScript bindings to npm as @hajewski/latticedb, and a Rust core crate (latticedb-core 0.3.4) on August 16, according to package registries. The project published release notes for version 0.11.1 this week, though those notes included only packaging updates.
The Show HN post collected 179 points and 49 comments by Wednesday. The GitHub repository picked up 508 stars and 18 forks in the first two days. Users asked about concurrent writes and backup strategies. Hajewski said he added file locking "tonight" to prevent multiple processes from writing simultaneously and shipped hot-copy backup functionality the same evening in response to feedback.
That velocity suggests Hajewski is treating early adopter feedback seriously, though it also raises questions about stability. PyPI lists the project status as "3 - Alpha." The documentation warns developers to test on their own workloads rather than trusting published benchmarks, which feels like appropriate caution for a young project.
What's missing and what's next
The single-writer model and lack of clustering make LatticeDB unsuitable for distributed applications, according to the comparison pages. Parts of the Cypher specification remain unimplemented. Language bindings now cover Python, TypeScript/Node, Go, and C.
The database includes durable named streams for event processing, point-in-time restore via "lattice restore --at" with UTC timestamps, and continuous WAL replication through "lattice replicate --follow," according to the backup and replication guide. Hajewski hasn't disclosed a roadmap for additional Cypher features or multi-writer support.
For now, LatticeDB occupies a specific niche: developers building AI agents, knowledge graphs, or local graph applications who want SQLite-style simplicity without giving up graph semantics. Whether that niche proves large enough to sustain the project long-term remains an open question. But for a solo engineer working nights and weekends, the early traction suggests he's onto something.
