Technology · Databases

LatticeDB Emerges as SQLite-like Alternative for Graph Databases

LatticeDB offers a novel approach to graph databases, aiming to provide the simplicity and embedded nature of SQLite for managing connected, semantic, and textual data.

News AutomationCompiled 21:11 UTC · 1 min read

A diagram illustrating the interconnected nature of data within a graph database. · Photo by Scott Rodgerson on Unsplash

1 sources

Pipeline ingest

3 reads

Positive / Neutral / Negative

0 countries

Related coverage

LatticeDB

Embedded property-graph database with native vector and full-text indexing.

LatticeDB is a single-file local database for connected, semantic, and textual data. It lets you traverse relationships, run vector similarity search, and do BM25 full-text search over the same dataset in one engine and one query layer. It is designed for relationship-heavy workloads on a single machine, with zero-config operation and an embedded single-writer model.

LatticeDB is an embedded, single-file graph database that lets local applications query the same data by relationship, semantics, and text, then consume durable graph and application events from the same file. Workloads like Graph RAG, agent memory, and local knowledge tools are examples built on those primitives, not the definition of the engine.

One file. Your entire database is a single portable file. No server, no configuration.
One query layer. Graph traversal, HNSW vector similarity, and BM25 full-text — in the same query language.
One event log. Durable named streams and a built-in graph changefeed share the same transaction/WAL path as graph writes.
Local-first. Designed for one owning process on one machine, with WAL-backed durability.
Fast. 0.13 μs node lookups. 0.83 ms vector search at 1M vectors with 100% recall.

-- Find chunks similar to a query, traverse to their document, then to the author
MATCH (chunk:Chunk)-[:PART_OF]->(doc:Document)-[:AUTHORED_BY]->(author:Person)
WHERE chunk.embedding $query_vector $query_vector
LIMIT 10

Install

CLI

curl -fsSL https://raw.githubusercontent.com/jeffhajewski/latticedb/main/dist/install.sh | bash

Python

pip install latticedb

Published wheels are expected to bundle liblattice on supported platforms. Source installs can also bundle a staged native library during wheel builds with LATTICE_BUNDLE_LIB_DIR=/path/to/lib.

TypeScript / Node.js

npm install @hajewski/latticedb

Published package tarballs are expected to bundle liblattice on supported platforms. Source checkouts can stage the native library into the package with LATTICE_BUNDLE_LIB_DIR=/path/to/lib npm run bundle:native.

See bindings/go/README.md for the current cgo workflow. The default consumer path uses installed pkg-config metadata; in-repo development can use -tags repolocal against zig-out/lib. There is also a runnable graph/vector/text retrieval example in examples/go.

Recent binding-surface cleanups moved embedding helpers into dedicated modules and subpackages. See docs/client_api_migration.md for the preferred imports and current compatibility aliases.

Start Here

Getting Started maps the shortest path for CLI, Python, TypeScript, and Go.
CLI Quickstart is the smallest copy-paste example in the repo.
Examples Overview covers the larger graph/vector/text retrieval demos.

Example

A complete example: create a small knowledge graph with documents and authors, store embeddings, index text, then query across all three search modes.

Python

from latticedb import Database
from latticedb.embedding import hash_embed

with Database("knowledge.db", create=True, enable_vectors=True, vector_dimensions=128) as db:

 # --- Build the graph ---
 with db.write() as txn:
 # Create authors
 alice = txn.create_node(labels=["Person"], properties={"name": "Alice", "field": "ML"})
 bob = txn.create_node(labels=["Person"], properties={"name": "Bob", "field": "Systems"})
 txn.create_edge(alice.id, bob.id, "COLLABORATES_WITH")

 # Create documents with chunks
 for title, text, author in [
 ("Attention Is All You Need", "The transformer architecture uses self-attention...", alice),
 ("Scaling Laws for LLMs", "We find that model performance scales predictably...", alice),
 ("Log-Structured Merge Trees", "LSM trees optimize write-heavy workloads...", bob),
 ]:
 doc = txn.create_node(labels=["Document"], properties={"title": title})
 chunk = txn.create_node(labels=["Chunk"], properties={"text": text})

 # Store embedding and index text
 txn.set_vector(chunk.id, "embedding", hash_embed(text, dimensions=128))
 txn.fts_index(chunk.id, text)

 txn.create_edge(chunk.id, doc.id, "PART_OF")
 txn.create_edge(doc.id, author.id, "AUTHORED_BY")

 txn.commit()

 # --- Query: vector search + text match + graph traversal ---
 results = db.query("""
 MATCH (chunk:Chunk)-[:PART_OF]->(doc:Document)-[:AUTHORED_BY]->(author:Person)
 WHERE chunk.embedding $query $query
 LIMIT 5
 """, parameters={"query": hash_embed("transformer attention mechanism", dimensions=128)})

 for row in results:
 print(f"{row['doc.title']} by {row['author.name']}")

 # --- Full-text search ---
 for r in db.fts_search("self-attention transformer"):
 print(f"Node {r.node_id}: score={r.score:.4f}")

 # --- Aggregations ---
 stats = db.query("""
 MATCH (doc:Document)-[:AUTHORED_BY]->(p:Person)
 RETURN p.name, count(doc) AS papers
 ORDER BY papers DESC
 """)
 for row in stats:
 print(f"{row['p.name']}: {row['papers']} papers")

TypeScript

import { Database } from "@hajewski/latticedb";
import { hashEmbed } from "@hajewski/latticedb/embedding";

const db = new Database("knowledge.db", {
 create: true,
 enableVectors: true,
 vectorDimensions: 128,
});
await db.open();

// Build a graph
await db.write(async (txn) => {
 const alice = await txn.createNode({
 labels: ["Person"],
 properties: { name: "Alice", field: "ML" },
 });
 const doc = await txn.createNode({
 labels: ["Document"],
 properties: { title: "Attention Is All You Need" },
 });
 const chunk = await txn.createNode({
 labels: ["Chunk"],
 properties: { text: "The transformer architecture uses self-attention..." },
 });

 await txn.setVector(chunk.id, "embedding", hashEmbed("transformer self-attention", 128));
 await txn.ftsIndex(chunk.id, "The transformer architecture uses self-attention...");

 await txn.createEdge(chunk.id, doc.id, "PART_OF");
 await txn.createEdge(doc.id, alice.id, "AUTHORED_BY");
});

// Query across vector search + graph traversal
const results = await db.query(
 `MATCH (chunk:Chunk)-[:PART_OF]->(doc:Document)-[:AUTHORED_BY]->(author:Person)
 WHERE chunk.embedding $query $query
 LIMIT 5`,
 { query: hashEmbed("attention mechanism", 128) }
);

for (const row of results.rows) {
 console.log(`${row["doc.title"]} by ${row["author.name"]}`);
}

await db.close();

Go

db, err := latticedb.Open("knowledge.db", latticedb.OpenOptions{
 Create: true,
 EnableVectors: true,
 VectorDimensions: 128,
})
if err != nil {
 log.Fatal(err)
}
defer db.Close()

err = db.Update(func(tx *latticedb.Tx) error {
 node, err := tx.CreateNode(latticedb.CreateNodeOptions{
 Labels: []string{"Chunk"},
 Properties: map[string]latticedb.Value{"text": "The transformer architecture uses self-attention..."},
 })
 if err != nil {
 return err
 }
 if err := tx.SetVector(node.ID, "embedding", []float32{1, 0, 0, 0}); err != nil {
 return err
 }
 return tx.FTSIndex(node.ID, "The transformer architecture uses self-attention...")
})
if err != nil {
 log.Fatal(err)
}

Performance

Benchmarked on Apple M1, single-threaded, with auto-scaled buffer pool. Run zig build benchmark to reproduce. For the repeated-term FTS indexing workload that previously exposed quadratic append behavior, run zig build fts-benchmark.

Core Operations

Operation	Latency	Throughput	Target	Status
Node lookup	0.13 μs	7.9M ops/sec	`

Full-text search operator: @@
Parameters: $name

Operations

Single-file storage with write-ahead log for crash recovery
Durable named streams with explicit consumer offsets, manual trim, and graph changefeeds
Online freelist reuse plus lattice compact for safe physical tail reclamation
Zero configuration — open a file and start working
Embedded single-writer model for local applications
Clean C API; Python, TypeScript, and Go bindings wrap it

Use Cases

Connected local data — Notes, documents, catalogs, citation graphs, and entity graphs
Graph plus retrieval — Relationship traversal, semantic search, and lexical search over the same dataset
Local knowledge tools — Embedded apps that need graph structure without running a separate server
Agent memory and RAG pipelines — One example class of workload built on the graph/vector/text substrate
Local development — Lightweight alternative to Neo4j or Weaviate for prototyping on one machine

When to Use Something Else

LatticeDB is fast, but speed is not the only thing that matters. Here are cases where a different tool is the better choice.

You need multiple applications writing to the same database at the same time. LatticeDB is embedded with a single-writer model. One process opens the file and owns it. If you need many clients connecting over a network, use Neo4j, PostgreSQL, or another client-server database.

Your data is fundamentally tabular. If your data fits naturally into rows and columns — sales records, user accounts, time series — a relational database like SQLite or PostgreSQL will be simpler and just as fast. Graph databases shine when relationships between records are the point, not an afterthought.

You need to scale beyond a single machine. LatticeDB stores everything in one file on one machine. If you need sharding, replication, or distributed queries across billions of nodes, look at Neo4j cluster, Dgraph, or a managed service like Neptune.

You need the full Cypher language. LatticeDB supports most of Cypher but not all of it. Features like OPTIONAL MATCH and CALL procedures are not yet implemented. If your queries depend on these, Neo4j is the complete implementation.

You need mature tooling and ecosystem. Neo4j has visualization tools, admin dashboards, monitoring, drivers in every language, and years of community resources. PostgreSQL has decades of tooling. LatticeDB is new and lean — which is a strength for embedding, but a weakness if you need a rich operational ecosystem around your database.

Building from Source

Written in Zig. No dependencies.

git clone https://github.com/jeffhajewski/latticedb.git
cd latticedb
zig build # build everything
zig build test # run tests
zig build -Doptimize=ReleaseFast # optimized build