Skip to main content

Embedded · Rust · Cypher-like

The graph database for connected systems.

LoraDB is an in-process graph store with a Cypher-like query engine — small enough to embed in an agent, a robot, or a stream processor, and expressive enough to model the relationships those systems actually depend on.

  • Node.js · Python · WASM · Go · Ruby
  • Zero daemons · runs in your process
  • Open source · readable end-to-end
MATCH (a:Agent)-[:REMEMBERS]->(c:Context)
      -[:ABOUT]->(e:Entity)
WHERE c.updated_at > temporal.now() - 'PT1H'::DURATION
RETURN e.id, collect(c.summary) AS recent_context

The shape of the problem

Modern systems are graphs. Most databases aren’t.

Relational stores fight relational questions. Document stores fight evolving relationships. Graph platforms are often disproportionate — a service, a protocol, and a TCO that only pays off at scale, when all you wanted was a graph data structure next to the code that uses it. LoraDB is the option that was missing in the other direction: the one you reach for when the graph belongs inside your process.

Long formWhy an embedded graph at allThe argument in full — vs. SQL, vs. document stores, vs. managed graph platforms.

Built for

Systems that reason over connected, evolving context.

AI agents & LLM pipelines

Tools, entities, observations and decisions as a live graph. Retrieval becomes a pattern match, not a similarity score.

Vector retrieval recipes

Context & memory systems

Model claims, evidence, citations, and contradictions as typed edges. Ask "why do we believe this?" as a traversal.

Graph patterns

Event pipelines & streams

Resolve entities, infer relationships, and enrich events in-process with Cypher rules that read top-to-bottom.

Event recipes

Embedded graph storage

A graph data structure inside your own process. No service to deploy, no protocol to speak, no daemon to babysit.

Pick a binding

Start in a minute

Add the package. Open a database. Write a query.

There’s no server to stand up, no protocol to speak. Opening a LoraDB is a function call — in Node.js, Python, WASM, Go, or Ruby. Same Cypher, same result shape, across every binding.

quickstart.ts
import { createDatabase } from '@loradb/lora-node';

const db = await createDatabase(); // in-memory
// const db = await createDatabase('app', { databaseDir: './data' }); // ./data/app.loradb

await db.execute(
"CREATE (:Person {name: 'Ada'})-[:INFLUENCED]->(:Person {name: 'Grace'})"
);

const result = await db.execute(
"MATCH (a)-[:INFLUENCED]->(b) RETURN a.name, b.name"
);

console.log(result.rows);

Common questions

The three questions readers ask first.

What is LoraDB?

LoraDB is a local-first, in-memory property-graph engine written in Rust. It speaks a pragmatic subset of Cypher and runs in-process inside your application — through a Rust crate, five bindings (Node.js, Python, WASM, Go, Ruby), or an HTTP server.

Is LoraDB open source?

LoraDB is source-available under the Business Source License 1.1, with an automatic conversion to Apache 2.0 on the Change Date. The source code, issues, and discussions live in the public lora-db/lora repository on GitHub.

How is LoraDB different from Neo4j, Memgraph, or SQLite?

LoraDB is an embedded graph engine — it lives in the same process as the code that queries it, with no server to deploy and no protocol to speak. Hosted graph platforms (Neo4j, Memgraph) target operational tiers with full Cypher and clustering. SQLite is relational and embedded but does not natively model labelled property graphs or run Cypher. LoraDB fills the gap: graph-native, embedded, single-process.