LoraDB v0.11 is a surface release.

v0.5 made the engine stream. v0.6 made persistence feel like a system. v0.7 was a process release. v0.8 made plans and runtime metrics easier to inspect from bindings. v0.9 gave the planner a schema catalog. v0.10 made the function library a library.

v0.11 puts the engine behind a URL. play.loradb.com is a browser playground for writing LoraDB queries, running them against an in-tab database, and seeing the results as a graph, table, or JSON. It ships as a static Next.js export and runs the database through WebAssembly in the browser.

What the playground is​

Open a tab. Write a LoraDB query. See the graph.

The playground loads three of LoraDB's workspace packages:

• @loradb/lora-wasm runs the Rust engine through WebAssembly.
• @loradb/lora-query provides the Monaco-based query editor, formatting, highlighting, completion, and diagnostics.
• @loradb/lora-graph-canvas renders graph-shaped results as nodes and relationships.

Around those packages the app adds query tabs, result views, a schema browser, history, saved queries, snapshots, a command palette, keyboard shortcuts, and copyable query links. Saved work lives in IndexedDB and localStorage; the hosted app does not receive your graph.

Same engine, not a demo dialect​

The playground is not a hand-written browser mock of LoraDB. It uses the same Rust crates that power the bindings, compiled for WASM and loaded from the browser bundle:

• the same parser and analyzer;
• the same planner and executor;
• the same value model for nodes, relationships, paths, temporal values, points, vectors, lists, and maps;
• the same snapshot byte format exposed by the WASM binding.

That matters for docs and bug reports. A query you can reduce in the playground is a useful reproduction for the engine, not just a screenshot of a separate teaching tool.

The workbench​

The first release keeps the layout intentionally simple: editor on top, results below, and an activity sidebar for supporting tools. The split between editor and results is resizable and persisted locally.

Editor. Multi-tab query editing with LoraDB-aware highlighting, completion, formatting on command, diagnostics, and the familiar Cmd/Ctrl+Enter run shortcut.

Results. The same result can be inspected several ways:

• Graph renders nodes and relationships when the result contains graph entities.
• Table gives a compact grid for scalar and structured columns.
• JSON shows the adapted row payload.
• Plan shows parser/analyzer information such as diagnostics, variables, labels, relationship types, and parameters. Full explain/profile execution plans remain binding and HTTP APIs.

Sidebar. Saved queries, schema, snapshots, history, and settings live behind the activity bar. The schema panel introspects labels, relationship types, property keys, and per-label counts from the current database.

Inspector. Selecting graph entities opens their labels, type, properties, and internal IDs in the inspector drawer.

Sharing a query​

The Share action copies a URL with the query body encoded in the hash as #q=<compressed-query>. The codec uses lz-string's URL-safe encoding; it is not base64 and it does not encode your local database.

That boundary is deliberate. A shared link is a way to send the query text, not a way to publish your graph. If the recipient needs the same data, export a snapshot and send the .lorasnap file alongside the query link.

Snapshots use the same byte format as the WASM binding:

1. Run the seed statements.
2. Open Snapshots and create a snapshot.
3. Export the snapshot file.
4. Share the snapshot and the query URL together.

What runs where​

The playground is a fully static export. There are no API routes, no server actions, and no shared hosted database. next build writes HTML, JavaScript, CSS, and WASM assets into apps/play.loradb.com/out; Cloudflare Pages serves those files.

That has three practical consequences:

• No backend account. There is no sign-in and no hosted graph for the app to sync with.
• Local persistence. Saved queries, history, settings, snapshots, and the auto-restored graph are browser-origin data.
• Browser-sized workloads. The engine is real, but this surface is still one browser tab. It is for learning, debugging, examples, and small local graphs, not load testing.

A graph that needs server-side durability, multiple clients, operational controls, or production ingress still belongs in an application binding or the HTTP server.

What the playground does not do yet​

The release is useful because the boundaries are clear:

• No parameter drawer. The editor can detect parameter names, but this first UI does not expose a host-side params panel. Docs examples meant to run directly in the playground should use trusted inline literals or seed data.
• No multi-database selector. The browser origin owns one local playground database.
• No true query abort. The Cancel button drops the pending result from the UI; the current WASM execute call still runs until it returns.
• No remote import. Import accepts snapshot files from the local machine. The app does not fetch remote URLs to seed a graph.
• Hash links only. Share state lives in the URL hash so a static export can refresh cleanly.

New package surfaces​

Two UI packages are versioned with this release:

• @loradb/lora-query packages the query editor pieces used by the playground.
• @loradb/lora-graph-canvas packages the graph canvas used by the result view.

They are published under the same Business Source License 1.1 release terms as the rest of the repository. The docs site itself remains separately MIT-licensed.

How v0.11 fits the journey​

The earlier releases made the engine more capable and observable. v0.11 makes it easier to touch.

That changes what a docs page, PR comment, or support thread can ask of a reader. Instead of starting with "clone the repo and wire up a binding", we can often start with "open the playground and run this".

The next obvious improvements are a parameters drawer, seeded docs links, and smoother snapshot handoff from docs into the playground.

Read next​

• Open the playground
• Playground page on loradb.com
• Playground guide
• Cookbook — queries that run as-is
• WASM binding guide
• Limitations

v0.11 is the release where you can try LoraDB before installing it.

LoraDB v0.10 is a function-surface release.

v0.5 made the engine stream. v0.6 made persistence feel like a system. v0.7 was a process release. v0.8 made the planner and executor observable. v0.9 gave the planner a real schema catalog.

v0.10 does the same thing for the function library: the engine now has one canonical name per concept, grouped into namespaces, with the analyzer, executor, optimizer, docs, and binding tests all reading from the same table.

The shape of the change​

LoraDB used to ship a flat soup of function names: head, tolower, substring, coalesce, vector.similarity.cosine, randomUUID, toIntegerOrNull, keys, id, type. Some were single-word, some were dotted, some came from Cypher, some from convenience.

That worked while there were sixty of them. With v0.10 there are 236, covering text, numbers, lists, maps, temporal values, bytes, bits, geo, vectors, graph entities, paths, type inspection, and explicit casts.

The fix is structural, not cosmetic. Every built-in now lives at <namespace>.<operation>, both segments snake_case:

RETURN string.upper('hello')                      AS greeting,
       list.first([1, 2, 3])                      AS head,
       math.clamp($x, 0, 100)                     AS bounded,
       temporal.between(date('2024-01-01'), date()) AS age,
       value.coalesce($preferred, $fallback, 'n/a') AS pick,
       cast.try($maybe_int, INTEGER)              AS as_int;

The rules are enforced module-wide, not per function:

• Two segments only — namespace.operation.
• snake_case for both segments.
• Namespaces name the value family or concern (list.*, string.*, vector.*, node.*). Runtime type questions live under type.*; conversions live under cast.*.
• One operation per concept. Behaviour varies by arguments, not by suffix — no sortMaps / sortNodes / sortText, just list.sort.
• Predicates return BOOL and read as a question (is_, has_, contains, equal_unordered, all_distinct).
• Pure functions only. Mutating procedures live in the procedure dispatcher, not in the function library.

Sixteen namespaces​

The full catalog groups into sixteen pure namespaces and four storage-aware namespaces.

That gives every developer a search shape: when you don't remember the exact name, you remember the namespace and tab through it.

A single source of truth​

The catalog lives in one file, owned by the analyzer:

// crates/lora-analyzer/src/analyzer/builtin_signatures.rs

pub const BUILTIN_SPECS: &[BuiltinSpec] = &[
    spec("list.first",            1, Some(1)),
    spec("list.sort",             1, Some(2)),
    spec("string.upper",          1, Some(1)),
    spec("string.slice",          2, Some(3)),
    spec("math.clamp",            3, Some(3)),
    spec("temporal.between",      2, Some(2)),
    spec("vector.similarity",     2, Some(3)),
    spec_type("cast.try",         2, Some(2), &[1]),
    // …236 entries total
];

Every entry carries an arity range and, where it matters, the argument slots that accept type literals (DATE, INTEGER, VECTOR<FLOAT32>(384)) or enum-like literals (COSINE, EUCLIDEAN).

The executor never re-declares names. It exposes a dispatch arm per namespace, and a small drift-safety test in the executor walks BUILTIN_SPECS and asserts that every entry resolves to an implementation:

#[test]
fn every_signature_has_a_dispatch_arm() { /* … */ }

#[test]
fn every_signature_is_two_segments_and_snake_case() { /* … */ }

If you add a row to the table without an executor arm, the test fails. If you add a non-snake-case name, the test fails. If you add a dispatch arm without a signature, the analyzer rejects calls before they reach you. Drift between the surface and the runtime is no longer possible.

Aliases — for the names you already type​

The new tree would be a worse experience if every existing query had to be rewritten. v0.10 keeps every familiar Cypher spelling working through analyzer aliases:

A second alias family covers in-house migrations from earlier LoraDB spellings:

Aliases resolve during analyzer lowering. They never reach the executor. That means no per-binding plumbing, no aliasing-induced ambiguity in plans, and one place to look when you wonder why a name exists.

Why this is the right shape now​

Three forces pushed v0.10 to land before any larger function surface work:

Predictability. With sixteen namespaces a developer can guess a name without grepping. The right names for "give me the first list element" or "lowercase this string" or "tell me whether this map has a key" are reachable from the namespace alone.

Drift safety. The analyzer signature catalog and executor dispatch used to be two parallel sources of truth. They drifted. Tests caught some of that; not all of it. The drift-safety tests in v0.10 make the two sources structurally identical — adding a function means adding one line of signature plus one match arm, and the test suite enforces the pairing.

Cross-binding consistency. The bindings (@loradb/lora-node, @loradb/lora-wasm, lora-python, lora-ruby, lora-go, the lora-ffi C ABI) call Cypher through the same parser. When the parser exposes one canonical name per concept, every binding inherits the same surface for free. The binding tests in v0.10 exercise the namespaced names directly so a regression in one shows up in all five test suites.

Pipeline updates​

Behind the surface, every layer learned about namespaces:

• Parser — function_invocation now accepts namespace.operation invocations and parses the full canonical form. The grammar uses a small namespace = (symbolic_name ~ dot)+ rule reused for procedure calls.
• Analyzer — BUILTIN_SPECS and BUILTIN_ALIASES resolve every function reference. Aliases are normalized to the canonical spelling before type checking, so the resolved tree always reads canonically.
• Compiler — plan_namespaced_call covers the new arms in one place; the optimizer can recognize storage-aware namespaces (node.*, edge.*, path.*, value.*) and lower them where beneficial.
• Executor — the function library was reorganised into one module per namespace, with a small dispatcher that returns None for any name outside the namespace tree.
• Database / store / server — internal call sites now use the canonical names. The on-disk format and snapshot codec are unchanged; only the function names in code paths moved.

Examples​

Some queries the new shape makes pleasant to write.

A search ranking that combines vector similarity and structure

MATCH (d:Doc)
WITH d, vector.similarity(d.embedding, $query) AS score
WHERE score > 0.6
MATCH (d)-[:MENTIONS]->(e:Entity)
RETURN d.id,
       string.upper(d.title)               AS title,
       value.coalesce(d.summary, '(none)') AS summary,
       score,
       list.unique(collect(e.name))        AS entities
ORDER BY score DESC
LIMIT 5;

Working a list down to a single shape

RETURN list.first(value.coalesce($items, []))                AS head,
       list.last($items)                                     AS tail,
       list.unique(list.flatten($items))                     AS uniq,
       list.zip($items, list.range(1, list.size($items)))    AS indexed;

Parsing and normalising user input

WITH cast.try($input, INTEGER) AS as_int,
     string.trim(cast.to($input, STRING)) AS as_string
RETURN value.coalesce(as_int, 0)                AS count,
       string.lower(as_string)                  AS key,
       type.of($input)                          AS reported_type,
       type.is($input, INTEGER)                 AS was_int;

Temporal arithmetic without remembering the constant names

WITH temporal.now() AS now, $birthday AS dob
RETURN temporal.between(dob, now)               AS lived,
       temporal.in_days(dob, now)               AS days_lived,
       temporal.truncate(now, 'day')            AS today,
       temporal.add(now, duration('P1Y'))       AS next_year;

Binding behaviour​

The bindings did not change shape — db.execute(query, params) returns the same tagged values it did in v0.9, and the vector / temporal / spatial helpers still produce the same wire format. What changed is that every binding's parameter and similarity test now exercises the namespaced builtin path through Cypher, including via type-cast literals ([1.0, 0.0, 0.0]::VECTOR<FLOAT32>(3)).

If a binding test exercised vector.similarity.cosine(...) before, it now exercises vector.similarity(...). Behavioural parity is checked in the same place as before.

Existing user code keeps working through the alias table.

Documentation​

Every namespace has its own reference page; the function overview was rewritten around the canonical names. A new developer-facing page, docs/developer/functions.md, documents the rules for adding new built-ins: signature, executor module, integration test in builtin_namespaces.rs, docs entry, drift-safety check. The contribution surface is one page now, not five.

Breaking changes and migration​

There are no on-disk migrations. The WAL and snapshot codecs are unchanged.

For Cypher callers, the canonical names are new, but the old spellings keep working through aliases — including the cases the analyzer used to special-case (coalesce is variadic, vector.similarity accepts either two or three arguments, cast.to accepts a type literal in arg position 1).

For Rust callers, the executor function library was reorganised into modules per namespace. If you were calling individual builtin implementations from outside the engine — generally not a supported path — the module paths changed. If you were calling them through Compiler::compile + Executor::run, nothing changed.

Notable fixes​

• The analyzer now reports a single, consistent error for unknown function names — including a "did you mean" hint when the name matches a namespace prefix.
• value.coalesce(...) short-circuits on the first non-null argument even when later arguments would have errored.
• Numeric predicates (number.is_finite, number.is_nan, number.is_integer) accept both INTEGER and FLOAT and never raise.
• Type-literal arguments are validated at parse time, not at runtime, so cast.to(x, UNKNOWN_TYPE) fails before the query executes.

How v0.10 fits the journey​

v0.5 made the engine stream. v0.6 made persistence feel like a system. v0.7 was a process release. v0.8 made the planner and executor observable. v0.9 gave the planner a real schema catalog.

v0.10 makes the function surface itself a system. The analyzer owns public signatures, the executor owns behavior, the docs read off the same names, and the binding tests pin the cross-language contract. The next time we add a function, we add it once.

Still open​

This release does not add new computational power. Every function in the canonical tree was reachable in v0.9 — under a different name. What v0.10 buys is a place to put the next forty functions without making the surface less learnable.

The natural extensions are user-defined functions (UDFs) registered into the same catalog, a documented procedure surface to mirror what db.index.fulltext.queryNodes / db.index.vector.queryNodes already look like, and a SHOW FUNCTIONS introspection that reads the analyzer signature table directly.

Read next​

• Function overview
• Building built-in functions
• Cypher support matrix
• Limitations

v0.10 is the release where LoraDB's function library stops being a list of names and starts being a library.

LoraDB v0.9 is a schema-catalog release.

v0.5 made the engine stream. v0.6 made persistence feel like a system. v0.7 was a process release. v0.8 made the planner and executor observable. v0.9 closes the next gap: the planner now has a real schema catalog to plan against, and the engine has real constraints to enforce.

The result is a single coherent surface — index DDL, constraint DDL, catalog-backed scans, full-text and vector query procedures — wired through the parser, store, optimizer, executor, WAL, and snapshots.

Not a shift away from schema-free graphs​

LoraDB is still a schema-free property graph. Labels, relationship types, and properties continue to appear when you write them. v0.9 does not introduce a mandatory schema.

What it introduces is a way for developers to be explicit about two things:

• Keep a secondary structure for this hot predicate — that is an index.
• Reject writes that violate this invariant — that is a constraint.

Both are opt-in. A graph that never issues a CREATE INDEX or CREATE CONSTRAINT keeps the v0.8 behavior unchanged.

Index DDL​

Index management is now part of the Cypher surface:

CREATE INDEX user_email FOR (u:User) ON (u.email);
CREATE TEXT INDEX user_name FOR (u:User) ON (u.name);
CREATE POINT INDEX venue_location FOR (v:Venue) ON (v.location);
CREATE VECTOR INDEX movie_embedding FOR (m:Movie) ON (m.embedding)
OPTIONS {indexConfig: {`vector.dimensions`: 384, `vector.similarity_function`: 'cosine'}};
CREATE FULLTEXT INDEX article_search FOR (n:Article|Note) ON EACH [n.title, n.body];
CREATE INDEX rel_since FOR ()-[r:FOLLOWS]-() ON (r.since);

SHOW INDEXES;
SHOW VECTOR INDEXES;
DROP INDEX user_email IF EXISTS;

The supported catalog kinds are RANGE, TEXT, POINT, LOOKUP, VECTOR, and FULLTEXT. RANGE is the default for CREATE INDEX; TEXT and POINT activate dedicated string and spatial candidate registries; LOOKUP records label/type token indexes in the catalog; VECTOR records a kNN configuration; FULLTEXT builds an inverted index over one or more properties.

IF NOT EXISTS is idempotent across both duplicate names and equivalent index schemas. Duplicate names surface as 22N71, equivalent schemas as 22N70, and dropping a missing index without IF EXISTS returns 42N51.

Constraint DDL​

Schema constraints share the same surface:

CREATE CONSTRAINT book_isbn FOR (b:Book) REQUIRE b.isbn IS UNIQUE;
CREATE CONSTRAINT author_name FOR (a:Author) REQUIRE a.name IS NOT NULL;
CREATE CONSTRAINT actor_fullname FOR (a:Actor)
REQUIRE (a.first, a.last) IS NODE KEY;
CREATE CONSTRAINT movie_title FOR (m:Movie)
REQUIRE m.title IS :: STRING | LIST<STRING NOT NULL>;

SHOW CONSTRAINTS;
DROP CONSTRAINT book_isbn IF EXISTS;

The supported constraint family covers node and relationship uniqueness, existence, node keys, relationship keys, and property type constraints — including fixed-dimension VECTOR property types. Creating a constraint validates existing data before committing the catalog change; later writes are checked at mutation time.

Faster scan shapes​

The optimizer now uses graph statistics and catalog state when it compiles a query. Eligible scan-and-filter patterns can lower to specialized operators:

• NodeByPropertyScan and NodeByPropertyRangeScan
• NodeByTextScan
• NodeByPointScan
• RelByPropertyRangeScan
• RelByTextScan
• RelByPointScan

That covers node and relationship predicates such as:

MATCH (u:User) WHERE u.age >= 18 AND u.age < 65 RETURN u;
MATCH (u:User) WHERE u.name STARTS WITH 'Al' RETURN u;
MATCH (v:Venue)
WHERE geo.within_bbox(v.location, $southwest, $northeast)
RETURN v;
MATCH ()-[r:FOLLOWS]->() WHERE r.since > 2020 RETURN r;

The executor still refilters conservative candidate sets. TEXT indexes use a trigram candidate path, and POINT indexes use spatial buckets, so correctness does not depend on the index being exact.

Run the same query through profile() (shipped in v0.8) before and after a CREATE INDEX to see the plan rewrite for itself.

Search procedures​

Two catalog-backed procedure families are now exposed through the limited built-in procedure dispatcher.

Full-text indexes support node and relationship scopes, multiple labels or relationship types, and multiple indexed properties:

CREATE FULLTEXT INDEX article_search
FOR (n:Article|Note) ON EACH [n.title, n.body]
OPTIONS {`fulltext.analyzer`: 'standard'};

CALL db.index.fulltext.queryNodes('article_search', 'graph powerful')
YIELD node, score;

The standard analyzer lowercases text, splits on non-alphanumeric boundaries, uses AND semantics across query terms, and scores by summed term frequency. It returns rows in descending score order. It is deliberately small: analyzer choice is currently limited to standard and simple, both on the same synchronous maintenance path.

Vector indexes support node and relationship scopes with explicit dimensions and either cosine or euclidean similarity:

CREATE VECTOR INDEX movie_embedding FOR (m:Movie) ON (m.embedding)
OPTIONS {indexConfig: {`vector.dimensions`: 3, `vector.similarity_function`: 'cosine'}};

CALL db.index.vector.queryNodes('movie_embedding', 5, [1.0, 0.0, 0.0])
YIELD node, score;

This is not an ANN engine yet. VECTOR indexes are catalog entries that validate configuration and scope the query procedure; the current implementation still uses a flat scan over matching entities and returns the top k rows by score. The shape is stable; the speedup is a later release.

Durability and snapshots​

Index and constraint DDL travel through the same write path as graph mutations. WAL payloads now encode CreateIndex, DropIndex, CreateConstraint, and DropConstraint events, and recovery replays them into the in-memory catalog before queries run.

Snapshots also carry both catalogs. The LORACOL1 envelope remains format version 2, and the snapshot body is now version 4: version 3 added the index-catalog trailer, and version 4 adds the constraint-catalog trailer. Readers still accept older body formats, loading older snapshots with empty index or constraint lists as needed.

The snapshot and WAL codecs now use a small store-owned binary codec for nested property values and catalog records. That keeps WAL and snapshots aligned on the same catalog wire shape, including VECTOR/FULLTEXT index definitions and constraint property-type records.

Developer-facing improvements​

Planner APIs now accept GraphStats, and the plan cache fingerprints catalog and cardinality state so adding or dropping an index invalidates stale plans. That means a query explained before CREATE INDEX can recompile into an indexed scan immediately after the catalog changes.

Read-only materialization also gained an optional native parallel feature through Rayon. It is default-on for native builds and disabled for WASM-style consumers through default-features = false.

SHOW INDEXES now accepts type filters such as SHOW RANGE INDEXES, SHOW FULLTEXT INDEXES, and SHOW VECTOR INDEXES. SHOW INDEXES and SHOW CONSTRAINTS also accept a YIELD-anchored projection tail:

SHOW INDEXES
YIELD name, type, entityType
WHERE type = 'FULLTEXT'
RETURN name
ORDER BY name;

Benchmark coverage was reshaped around intent:

• query_implementations mirrors integration-test feature areas;
• index_acceleration compares indexed and unindexed RANGE/TEXT scenarios;
• existing scale, realistic, wal, concurrent, and concurrency_guard suites remain workload-specific tools.

Breaking changes and migration notes​

For Rust callers of lora-compiler, Compiler::compile now requires a &GraphStats argument:

let compiled = Compiler::compile(&resolved, &store.graph_stats());

Use GraphStats::default() when compiling outside a store-backed runtime.

Snapshot writers now emit the newer LORACOL1 envelope/body combination. Current readers accept the previous body version, but older binaries should not be expected to read snapshots written after the index and constraint catalog trailers landed.

There are no data-model migrations for normal users. Existing graphs remain schema-free; add indexes where predicates are hot enough to justify the extra memory, and add constraints only for invariants you want enforced on every matching write.

Notable fixes​

• Plan-cache invalidation now accounts for catalog/cardinality changes.
• Index and constraint catalog DDL survives WAL crash recovery.
• TEXT and POINT indexes track property updates and label/type membership changes.
• FULLTEXT indexes backfill existing data and track property updates/removals.
• Constraint-owned backing indexes cannot be dropped directly; use DROP CONSTRAINT so the catalogs stay in sync.
• Indexed scans preserve already-bound node and relationship variables instead of rebinding them.
• Regex predicates cache compiled patterns per thread, avoiding repeated compilation for row-by-row =~ filters.
• Numeric conversion helpers now reject non-finite or out-of-range float-to-int conversions instead of silently casting.
• Ruby binding calls release the GVL more defensively and surface engine panics as query errors.

How v0.9 fits the journey​

v0.5 made the engine stream. v0.6 made persistence feel like a system. v0.7 was a process release. v0.8 made the planner and executor observable.

v0.9 closes the last gap before the planner stops being a black box: the catalog. Indexes were already inferable from the code; constraints were not enforceable at all. v0.9 gives both a stable surface — Cypher DDL, WAL events, snapshot trailers, and SHOW introspection — that every binding inherits without per-language plumbing.

Still open​

This work does not add ANN structures for vector search, custom full-text analyzers, a full-text query language, general CALL/RETURN procedure pipelines, or sorted-index ORDER BY planning. Composite RANGE indexes are accepted and visible in SHOW INDEXES, but current optimizer rewrites target single-property predicates. Those are the natural extensions of the v0.9 shape, not prerequisites for it.

Read next​

• Indexes — Cypher reference
• Constraints — Cypher reference
• Vector values and similarity functions
• Limitations

v0.9 is the release where LoraDB's planner stops guessing at structure that already exists in the application's head.

LoraDB v0.8 is a diagnostics release.

Until now, the only honest answer to "why is this query slow?" was "read the executor source." v0.8 changes that. Every binding — Rust, Node, WASM, Python, Go, Ruby, FFI — and the HTTP server now expose explain and profile as first-class methods, returning the same plan tree the engine actually compiles and runs.

The release also includes binding-level speedups for bulk reads. That work is not the headline. The headline is that LoraDB queries are no longer opaque.

What explain and profile are​

They are two separate calls with two different contracts.

explain(query, params?) parses, analyzes, and compiles the query and returns the plan that would run. The executor is never invoked. Even mutating queries — CREATE, MERGE, SET, DELETE, REMOVE — are safe to pass: they return a plan and leave the graph untouched. Use this to inspect what the planner decided before you commit to running it.

profile(query, params?) runs the query for real and returns the plan plus runtime metrics. Mutating queries produce the same side effects they would from execute: WAL is written, snapshots observe the commit, the live store advances. profile is a measurement tool, not a sandbox.

In Node:

const plan = await db.explain(
  "MATCH (p:Person) WHERE p.name = $name RETURN p",
  { name: 'Ada' }
);

console.log(plan.shape);          // "readOnly" or "mutating"
console.log(plan.resultColumns);  // ["p"]
console.log(plan.tree.operator);  // top-level physical operator

const profile = await db.profile(
  "MATCH (p:Person) WHERE p.name = $name RETURN p",
  { name: 'Ada' }
);

console.log(profile.metrics.totalElapsedNs);
console.log(profile.metrics.totalRows);
console.log(profile.metrics.perOperator);

The same shape is available over HTTP at POST /explain and POST /profile, and from Python, Ruby, Go, WASM, and the FFI. The JSON envelope is identical across every surface.

What the plan tree actually says​

explain returns a tree, not a string. Each node carries a stable id, an operator label (Projection, Filter, NodeByLabelScan, …), opaque human-readable details, and its children:

{
  "query": "MATCH (p:Person) WHERE p.name = $name RETURN p",
  "shape": "readOnly",
  "resultColumns": ["p"],
  "tree": {
    "id": 3,
    "operator": "Projection",
    "details": { "items": "p" },
    "children": [
      {
        "id": 2,
        "operator": "Filter",
        "details": { "predicate": "..." },
        "children": [
          {
            "id": 1,
            "operator": "NodeByLabelScan",
            "details": { "var": "v0", "labels": "Person" },
            "children": []
          }
        ]
      }
    ]
  }
}

shape is "readOnly" or "mutating" — a property of the plan, not a guess from the query string. resultColumns is the projection order the engine will produce. details is for humans; do not parse it.

What profile adds​

profile decorates the same tree with measurements:

{
  "plan": { "...same shape as /explain..." },
  "metrics": {
    "totalElapsedNs": 124500,
    "totalRows": 3,
    "mutated": false,
    "perOperator": {
      "1": { "rows": 5, "elapsedNs": 18200, "nextCalls": 6, "dbHits": 0 },
      "2": { "rows": 4, "elapsedNs": 21100, "nextCalls": 5, "dbHits": 0 },
      "3": { "rows": 4, "elapsedNs": 24400, "nextCalls": 5, "dbHits": 0 }
    }
  }
}

perOperator keys match tree[*].id. Per-operator elapsedNs is inclusive of descendants — the "operator + everything below it" view that matches what is visually surprising when reading a profile. dbHits is reserved for a future phase and reads 0 today; saying that out loud is the point of v0.8.

The honest boundary​

A few things profile is not in v0.8:

• It is not a query optimizer. There is no cost model yet; estimatedRows is null.
• It does not sandbox writes. Mutating queries mutate.
• It does not page or sample. The full plan and metrics ride on a single response.
• dbHits is reserved, not measured. v0.8 reports 0 rather than a fabricated number.

That last one matters more than it sounds. A diagnostic surface that quietly invents a metric is worse than one that admits the metric is not implemented.

A short word on bindings​

v0.8 also includes bulk-buffer changes in the Node, WASM, Go, and FFI bindings. Bulk reads now return a single contiguous binary buffer that the host language decodes locally, instead of crossing the FFI boundary row-by-row. Microbenchmarks show roughly 2–4× faster reads for queries that return many rows.

That work shipped quietly because it doesn't change any API. The binding signatures are the same; the wire is just narrower. If your code calls execute and reads many rows, you should see it without doing anything.

How v0.8 fits the journey​

v0.5 made the engine stream. v0.6 made persistence feel like a system. v0.7 was a process release.

v0.8 closes a different gap: the engine has been streaming and persisting for two releases without giving callers a way to see what it actually did. explain and profile make the planner and the executor observable from every surface that runs a query.

The next steps follow from there. Per-operator dbHits, an actual cost model, plan-stability assertions for tests, and an HTTP params field on /query are all natural extensions of the same shape.

Read next​

• HTTP API reference — /explain and /profile
• Node binding — explain and profile
• Limitations

v0.8 is the release where LoraDB stops being a black box at the query boundary.

I use Claude and Codex to build LoraDB.

That is not a positioning statement or a shortcut around the work. It is simply part of how the project gets built.

Claude and Codex help with different parts of the process: reading code, checking assumptions, shaping docs, reviewing release work, and testing whether the project is saying things the implementation can actually support. They are useful tools, but they are not the source of truth.

The Practical Version​

The practical version is fairly ordinary.

Claude is useful inside the repository. It can read files, follow code paths, run commands, patch docs, check links, find stale claims, and keep track of release work that is easy to get almost right.

Codex is useful around the repository. It helps with structure, narrative, product direction, and the question of whether a phrase like "production-grade" is being earned or just repeated.

I use both, and I reject both often. Their value is not that they are always right. Their value is that they make it easier to inspect the project from several angles before deciding what should change.

Why This Matters For LoraDB​

LoraDB is at an awkward and interesting stage.

It is no longer just a small in-memory graph experiment. It has a query pipeline, a graph store, vectors, snapshots, WAL, checkpointing, streaming, bindings, an HTTP server, and a growing documentation site.

But it is also not the database I want it to become yet.

The direction is a production-grade persistent and concurrent graph database.

That requires precision. It means knowing what the query engine promises, where state lives, how recovery works, which surfaces are stable, and which are still experimental. It also means being clear about where concurrency is real today, where it is conservative, and where it is still future work.

AI helps because it can keep more of that context visible while I work through the next change.

The Risk​

The risk is fluency.

It can explain a feature that does not exist. It can make a limitation sound like an implementation detail. It can blur "we want this" into "we have this." It can turn a database roadmap into a brochure if you let it.

So the rule is simple: the code wins.

If Claude writes a claim, the implementation has to back it. If Codex helps shape a post, the post still has to respect the current product. If something is work in progress, it should be called work in progress.

Where It Helps​

AI is useful for breadth.

LoraDB spans several kinds of work:

• Rust engine design;
• query semantics;
• persistence and recovery;
• concurrency boundaries;
• HTTP behavior;
• language bindings;
• documentation;
• release process;
• product narrative.

A human can reason about all of that, but context switching has a cost. AI helps reduce that cost by making it faster to ask the obvious follow-up questions.

Claude is good at the repository question: where is this in the code?

Codex is good at the product question: what does this mean for the user?

Those two questions catch a lot of weak spots.

What Still Has To Be Decided By Me​

I own the direction.

I own the decision to merge or not merge, to publish or not publish, to call something stable or experimental, to make the next release about a feature or about structure.

That part cannot be outsourced.

AI can speed up parts of the work, but it does not decide what LoraDB should become.

Where LoraDB Is Heading​

The database I want is one that can be trusted when things go wrong.

Not just when a demo query runs, but when a process dies, a WAL has to replay, a checkpoint is stale, two clients write, a stream stays open, or a binding exposes a smaller surface than Rust.

Claude and Codex help by making the project easier to inspect.

They do not make it correct.

They make it harder for me to avoid the places where correctness still needs work.

Why Say This​

Because AI is part of the process, and it is better to be direct about that.

Because the way LoraDB is built affects the kind of project it becomes.

Because there is a serious version of AI-assisted engineering: use the tools, name the tools, verify the tools, and keep responsibility with the person building the system.

LoraDB is being built with Claude and Codex as part of the workflow.

That does not make the database trustworthy. It helps me find the places where the code, docs, and expectations do not line up. LoraDB still has to earn trust through implementation, tests, and boring operational behavior.

LoraDB v0.7 is about how the project is being built.

Claude and Codex are now part of the LoraDB engineering loop. Not as a mascot, not as a replacement team, and not as a way to avoid responsibility. They are used across the project: code review, refactoring, documentation, release work, architecture pressure, and product-direction thinking.

This release says that out loud.

What AI Is Doing In LoraDB​

AI is being used across the full scope of the project:

• reading Rust code and tracing behavior across crates;
• auditing documentation against implementation;
• helping split large ideas into smaller changes;
• reviewing error boundaries and API surfaces;
• drafting and revising release notes;
• checking whether examples still match the code;
• running local validation commands;
• comparing architecture claims against source files;
• helping reason about where persistence and concurrency should go next.

Claude does most of the code work. It inspects the codebase, edits files, runs tests, builds the docs site, and shapes the next change inside the repository.

Codex sits on the other side of the loop, as the reviewer and the documentarian. It checks code changes against intent, audits the docs against the implementation, drafts and revises release notes, and catches the small mismatches that make a database project feel less trustworthy.

Those are different jobs. Both are useful.

What AI Is Not Doing​

AI is not the source of truth.

The source of truth is still the code, the tests, the build, and the judgment of the maintainer.

AI does not decide that a storage model is correct. It can help inspect it.

AI does not make a persistence feature production-grade. It can help reveal where the docs overstate the guarantee.

AI does not own a release. It can help keep the checklist from being sloppy.

AI does not remove the need to understand the database. It raises the cost of not understanding it, because it makes it easier to ask the codebase the same question from several angles.

Why This Matters For A Database​

Databases are promise machines.

They make promises about state, recovery, isolation, durability, query semantics, and failure. If the words around those promises drift away from the implementation, the project becomes dangerous in a quiet way.

That is why using AI here has to be unusually disciplined.

Claude and Codex are both capable of producing confident text about behavior that does not exist. That is the risk. The useful pattern is the opposite: make them search, compare, challenge, and verify.

In LoraDB, AI is valuable when it increases friction around overclaiming.

The Whole Project Scope​

The AI-assisted loop is not limited to documentation.

It touches the whole project:

• the query pipeline, where parser, analyzer, compiler, and executor behavior must line up;
• the graph store, where internal data structures and public semantics should not be confused;
• the database facade, where read/write behavior, transactions, and streams need precise language;
• the WAL and snapshot layers, where recovery claims must be backed by actual code paths;
• the HTTP server and bindings, where each surface exposes a slightly different operational contract;
• the docs site and blog, where user expectations are shaped;
• the release process, where versions, lockfiles, builds, and posts all have to move together.

That breadth is exactly why AI is useful. It can keep a large amount of context warm while the human maintainer decides what should actually change.

Steering Toward Production-Grade Persistence And Concurrency​

LoraDB is not finished.

The direction is clear, though: production-grade persistence and production-grade concurrency.

Persistence means more than "there is a file." It means recovery paths that are boring, WAL behavior that can be inspected, snapshot compatibility that is documented, checkpoint semantics that are clear, and operational surfaces that do not surprise people.

Concurrency means more than "some reads overlap." It means read behavior, write serialization, transaction boundaries, stream lifetimes, and future fine-grained coordination all have to be understandable.

Claude and Codex help with that by forcing more explicit structure. They help turn "this feels right" into "where does the code prove it?"

The Honest Boundary​

This release does not claim that AI makes LoraDB production-grade.

It claims something smaller and more useful: AI is now part of the way LoraDB is being steered toward that goal.

Used badly, AI would make the project sound more complete than it is.

Used well, it makes the project more honest about what is implemented, what is experimental, and what still needs real engineering.

v0.7 is a marker for that working style.

Read Next​

• Why LoraDB
• Limitations
• Snapshots
• WAL and checkpoints
• Graph model

The goal is not to hide AI usage. The goal is to use it plainly, carefully, and in service of a better database.

LoraDB has moved quickly since the public release, so it is worth stepping back from the version numbers and looking at the journey.

The individual posts tell the detail of each release. This one is the map: why the releases landed in this order, what each one proved, and how the current work fits the long arc from "fast local graph engine" to "database people can trust in the product loop."

v0.1: Make The Core Public​

The first public release made the bet visible.

LoraDB shipped as a Rust in-memory graph database with a Cypher-shaped query engine, an HTTP server, and early bindings. The important part was not that every database feature existed. It was that the core pipeline was there and readable:

• parse;
• analyze;
• plan;
• execute;
• store graph values;
• return results through Rust, HTTP, and bindings.

That release set the product tone. LoraDB would earn trust locally before asking anyone to trust a hosted platform.

v0.2: Put Vectors Inside The Graph​

The second release added first-class VECTOR values.

That was not a pivot into being a vector database. It was the opposite: an argument that embeddings are more useful when they live next to labels, properties, and relationships.

Similarity can find candidates. The graph can explain, filter, and rank them with context. v0.2 made that possible in one value model and one Cypher surface, across the bindings.

v0.3: Save The Graph​

v0.3 added manual snapshots.

That sounds small until you look at the trust boundary it creates. Before snapshots, LoraDB was a fast in-memory graph that disappeared with the process. After snapshots, a developer could carry graph state across sessions, ship a seed file, back up a notebook, or restore a service from one artifact.

Snapshots were not marketed as full durability. They were deliberately point-in-time persistence. That honesty mattered because the snapshot contract became the base for checkpoints later.

v0.4: Recover Committed Writes​

v0.4 added the WAL.

This is where persistence became continuous on filesystem-backed surfaces. Committed writes could be replayed after restart, torn log tails could be handled, and the server gained admin routes for checkpointing and WAL management.

The story changed from "save when you decide" to "recover what committed." Snapshots stayed important. They became the thing a WAL can checkpoint against.

v0.5: Stream The Query Path​

v0.5 shifted attention from durability to flow.

The pull-based executor, owned query streams, client stream APIs, property indexes, and memory indexing work all point at the same product feeling: the database should not force large graph work through one oversized materialized response.

That is a necessary step for a local-first graph engine. If LoraDB is going to sit close to applications, it has to hand results to those applications in a shape they can process naturally.

The v0.5 patch releases also tightened WAL persistence edges. That is how trust accumulates: feature, use, fix, repeat.

v0.6: Turn Persistence Into A System​

v0.6 upgraded snapshots into the current columnar LORACOL1 format and connected them more tightly to WAL checkpoints.

This is the release where the persistence staircase became easy to explain:

• in-memory for the fastest local loop;
• snapshots for point-in-time graph artifacts;
• WAL for committed write recovery;
• checkpoint snapshots to bound replay.

The docs were refreshed around that model because old release notes can become dangerous if they teach old API names. The posts now preserve the history while pointing readers at the current shape.

Current Work: Make The Hot Path Concurrent​

The latest commits after v0.6 continue the same thread.

Plan caching reduces repeated parse/analyze/compile work. Lock-free reads via an ArcSwap snapshot store make reads cheaper under concurrency. Arc-wrapped records make snapshot clones less expensive. Optimistic writes, per-record validation, a lock table, mutation write sets, and merge replay move the write path toward finer-grained concurrency.

The refactors that followed are not cosmetic. Splitting large modules in the store, database, WAL, snapshot, parser, analyzer, executor, server, and bindings makes the next round of performance work less risky. A system gets faster when its parts are easier to reason about.

The Pattern​

The release pattern is now visible:

1. Make the developer loop good. In-memory, readable, local, Cypher-shaped.
2. Add the value model people need. Vectors belong in the graph when context matters.
3. Add persistence one honest contract at a time. Snapshot first, WAL second, checkpoints after both are clear.
4. Improve execution flow. Stream rows, index common lookups, avoid unnecessary materialization.
5. Harden concurrency and structure. Make reads cheap, writes safer, and internals easier to change without breaking the product surface.

That pattern matters more than any single feature. It is how LoraDB keeps the product journey coherent while the engine grows quickly.

What Readers Should Take Away​

LoraDB is not trying to jump straight from a public repo to a hosted graph cloud by announcement.

It is building the trust layers in order:

• can I understand it;
• can I query it;
• can I store the values my workload needs;
• can I save and recover it;
• can I stream results;
• can it stay fast under concurrent use;
• can someone else operate it for me later.

That is the journey of LoraDB so far. The next releases should keep making that journey easier to follow, not just longer.

LoraDB v0.6 is a persistence hardening release.

v0.3 introduced snapshots. v0.4 introduced WAL recovery. v0.5 made the engine stream results and tightened container-backed persistence. v0.6 brings those persistence pieces into a cleaner shape: columnar snapshots, managed WAL checkpoints, and binding APIs that describe the same operational model from every runtime.

The headline is simple: the persistence story is no longer "one file" and "one log" as separate ideas. Snapshots are now the checkpoint artifact the WAL can lean on.

What Changed​

The short list:

• the current database snapshot format is now columnar LORACOL1;
• snapshot envelopes carry a BLAKE3 checksum;
• snapshot metadata supports compression and encryption options;
• WAL checkpoints can stamp snapshots with a durable walLsn fence;
• raw-WAL helpers can write managed snapshots after N committed transactions;
• binding APIs were aligned for WAL and snapshot operations;
• historical persistence docs were refreshed so v0.3 and v0.4 readers see the current API names and current guarantees;
• snapshot decoding and checkpoint failure paths were hardened after release.

That last group matters almost as much as the feature list. A database release is only useful if the error paths get clearer as the system grows.

From LORASNAP To LORACOL1​

The original snapshot work proved the operator contract:

• write a full graph to a temporary file;
• fsync;
• rename atomically;
• load by swapping the live graph in one shot;
• report metadata back to the caller.

That contract still stands. v0.6 changes the payload under the envelope. LORACOL1 is the format the current engine writes: a columnar database snapshot with explicit metadata and checksum validation.

The format upgrade is part of the same philosophy as the rest of LoraDB: keep the public boundary small, but make the internals more honest about the work they need to do. A snapshot is not just "some bytes." It is a database artifact that should be validated, described, restored, and used as a recovery point.

Checkpoints Make The Staircase Real​

The persistence staircase now reads cleanly:

1. In-memory. Start fresh. No durability. Fastest loop.
2. Snapshot-only. Save and restore a point-in-time graph.
3. WAL-backed. Replay committed writes after a process restart.
4. Snapshot plus WAL checkpointing. Bound replay by writing snapshots stamped with the WAL fence they represent.

v0.6 strengthens the fourth step.

A checkpoint snapshot is a normal snapshot with a meaningful walLsn. Recovery can load that graph state, then replay committed WAL records newer than the checkpoint. That keeps the log useful without letting replay grow forever.

Managed Commit-Count Snapshots​

Raw-WAL helpers can now write managed snapshots after N committed transactions.

That is intentionally not a full scheduler. There is still no wall-clock checkpoint daemon hidden inside the engine. If a production process wants time-based checkpoints, it should run that policy from the host process, systemd, cron, an operator, or eventually the hosted platform.

The commit-count option covers a different need: "after this many writes, bound recovery again." It is a small operational primitive with a clear contract, and it gives filesystem-backed bindings a practical default path without pretending LoraDB is already a full managed service.

Binding Alignment​

v0.6 also cleaned up the API story across the surfaces:

• Rust exposes the reference checkpoint, snapshot, WAL, and sync-mode controls.
• lora-server keeps the operator-facing admin routes.
• Node, Python, Go, and Ruby can open container-backed named databases or explicit WAL directories.
• WASM remains pathless and snapshot-oriented, using byte/source APIs because the browser has no ordinary filesystem path.

The binding names differ where the host language expects them to differ. The mental model should not.

That is why the v0.3 and v0.4 posts were refreshed instead of left as stale artifacts. They are historical release notes, but readers should not copy an API that the current packages no longer expose.

What Is Still Honest​

v0.6 does not turn LoraDB into a distributed database.

The boundaries remain:

• one process owns the graph;
• the HTTP admin surface still needs your ingress/auth boundary;
• checkpoints are local filesystem artifacts;
• raw-WAL helpers can checkpoint by commit count, not wall-clock time;
• there is no hosted control plane yet;
• WASM snapshots are caller-managed bytes.

Those limits are not a weakness in the release story. They are the reason the story is readable.

How v0.6 Fits The Journey​

v0.1 asked whether a small Rust graph database could feel good to use. v0.2 made AI context a native value, not a bolt-on store. v0.3 made the graph portable. v0.4 made committed writes recoverable. v0.5 made larger query results and binding streams practical.

v0.6 makes the persistence layer feel less like a set of features and more like a system.

That is the journey LoraDB is on: not "ship every database feature at once," but make each boundary stronger before building the next one on top.

Read Next​

• Snapshots
• WAL and checkpoints
• HTTP server quickstart
• HTTP API reference

v0.6 is the release where snapshots stop being only a manual save file and become the checkpoint language of the database.

LoraDB v0.5 is the release where the engine starts to breathe under larger result sets.

The first public releases were about making the model real: an in-memory graph, Cypher-shaped queries, vectors, snapshots, and then a WAL. v0.5 moves a level deeper. It changes how rows move through the executor, how common property lookups avoid scans, and how bindings expose results without requiring every query to become one large JSON payload.

The product promise is still the same: keep the graph close to the application, make the hot path fast, and keep the system small enough to understand. v0.5 makes that promise more practical once the graph stops being a demo-sized toy.

What Changed​

The short version:

• a pull-based streaming executor for query results;
• transactional query streams in the database layer;
• owned query streams that can cross binding boundaries safely;
• client stream APIs for Node, WebAssembly, Python, and Go;
• snapshot helper updates across bindings;
• graph storage property indexes;
• memory indexing improvements;
• stronger container-backed WAL persistence;
• follow-up fixes across v0.5.1 through v0.5.6 for Node handles, WAL working directories, temporary paths, and persistence edge cases.

That patch-release tail matters. v0.5 was not one neat switch. It was a weekend of making the new execution shape work across the surfaces people actually install.

Why Streaming Came Next​

Before v0.5, the natural API shape was "run a query, get the result." That is useful, simple, and exactly right for small graphs. It also has a ceiling: every result has to be produced, stored, converted, and returned before the caller can do anything useful with the first row.

Graph queries make that ceiling show up early. A traversal can discover a large neighborhood even when the application only wants to page, filter, or process rows incrementally. If the executor has to materialize the whole thing at once, memory usage starts to reflect the worst moment of the query instead of the shape the caller actually needs.

v0.5 starts moving the engine toward this model:

MATCH (account:Account)-[:OWNS]->(ticket:Ticket)
WHERE account.id = $account_id
RETURN ticket.id, ticket.status, ticket.priority
ORDER BY ticket.priority DESC

The database should be able to produce rows as the plan is pulled, and the binding should be able to hand those rows to the host runtime without pretending the result has to be one giant object.

What The Pull-Based Executor Means​

The pull executor changes the flow from "plan runs to completion" to "the consumer asks for the next row."

That matters for three reasons.

First, it makes memory behavior easier to reason about. A query can carry the current row, the current traversal state, and the current operator state instead of eagerly building the full output.

Second, it creates a better API boundary for bindings. Node, Python, Go, and WASM all have different ideas about iteration, async work, and backpressure. Owned streams give each runtime a safer handle to wrap.

Third, it is the shape future performance work wants. Once the executor has a pull contract, improvements like paging, cancellation, and more selective operators have a place to attach.

Property Indexes Move The Store Closer To The Query​

v0.5 also adds graph storage property indexes.

The early LoraDB store was deliberately simple. That was the right first move: prove the model, keep the code readable, and only add shortcuts where the query engine has shown the need. By v0.5, a few common query shapes were loud enough:

MATCH (u:User)
WHERE u.id = $id
RETURN u

MATCH (d:Doc)
WHERE d.slug = $slug
RETURN d.title

Those should not feel like whole-graph scans. Property indexes make the storage layer more graph-aware without changing the Cypher surface. The developer still writes the same query; the engine gets a better access path.

That is the LoraDB pattern in miniature: keep the public model steady, then make the internals earn their place.

Binding Streams​

The binding work is part of the release, not an afterthought.

LoraDB is only developer-first if the non-Rust surfaces feel first-class. v0.5 extends the stream story through:

• Node / TypeScript query streams;
• WebAssembly worker streams and snapshot helpers;
• Python sync and async stream surfaces;
• Go streams, transactions, and snapshot byte helpers;
• Rust owned query streams in the database crate.

The details differ by runtime, but the journey is the same: start with a local graph, query it with Cypher, and process results in the shape your application already understands.

Persistence Fixes In The v0.5 Patch Train​

v0.4 introduced WAL-backed persistence. v0.5 made that path more useful and then spent several patches tightening the practical edges.

The patch train covered:

• archive WAL persistence improvements;
• Node multiple-database handle fixes;
• WAL working-directory fixes;
• temporary-path fixes;
• durability updates for container-backed opens.

That is part of the story worth saying plainly. Persistence is not a single checkbox. It becomes trustworthy through boring fixes: paths, handles, flushes, recovery fences, and reopening the same graph the way real applications reopen it.

How v0.5 Fits The Journey​

The first four releases answered "can I model, query, save, and recover the graph?"

v0.5 starts answering "can I keep using it when the result set gets large, the bindings matter, and common lookups need to stay cheap?"

It is a performance release, but not only in the benchmark sense. It is a product-feel release. The graph can be closer to the application because the application does not have to wait for every row before touching the first one.

Read Next​

• Performance
• Node guide
• Python guide
• Go guide
• Snapshots

v0.3 gave LoraDB a file. v0.4 gave it a log. v0.5 gives the query path a stream.

LoraDB v0.4.0 adds a write-ahead log.

The engine is still in-memory and local-first. What changes in this release is the durability boundary: on the surfaces that own a filesystem and process lifecycle, committed writes no longer have to live entirely in RAM between two manual snapshots.

The shortest mental model:

• createDatabase() in Node is still a fresh in-memory graph.
• createDatabase("application", { databaseDir: "./data" }) opens a persistent container-backed graph at ./data/application.loradb.
• Database.create("app", {"database_dir": "./data"}), lora.New("app", lora.Options{DatabaseDir: "./data"}), and LoraRuby::Database.create("app", {"database_dir": "./data"}) do the same thing on Python, Go, and Ruby.
• openWalDatabase({ walDir: "./data/wal" }), Database.open_wal("./data/wal"), lora.OpenWal(...), and LoraRuby::Database.open_wal("./data/wal") open explicit WAL directories; pair them with snapshot directories for managed commit-count checkpoints.
• lora-server --wal-dir /var/lib/lora/wal turns the HTTP server into a WAL-backed process.
• Rust gets the full open, recover, checkpoint, and sync-mode surface.

Snapshots do not go away. They stay the portable file you can back up, ship, and restore elsewhere. v0.4.0 makes them stronger by giving them something to checkpoint against.

What ships in v0.4.0​

That split is intentional. Rust and lora-server expose the full operator surface. Embedded bindings offer two ergonomic shapes: pass a database name plus a directory for a portable .loradb archive, or use the explicit WAL helper when you want to manage the WAL and checkpoint directories yourself. Omit persistence options when you want a fresh in-memory graph.

The Node shape is deliberately explicit​

The Node API is meant to read like the difference between scratch, container-backed, and explicit-WAL storage:

import { createDatabase, openWalDatabase } from '@loradb/lora-node';

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

const walDb = await openWalDatabase({
  walDir: "./data/application.wal",
  snapshotDir: "./data/application.snapshots",
  snapshotEveryCommits: 1000,
  syncMode: "groupSync",
});

await db.execute("CREATE (:Person {name: 'Ada'})");

Reopen the same directory later:

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

const db = await createDatabase("application", { databaseDir: "./data" });
const { rows } = await db.execute(
  "MATCH (p:Person) RETURN p.name AS name",
);

The name is resolved inside databaseDir as a .loradb archive. Relative paths resolve from the current working directory. Archive-backed named databases default to grouped fsync with a 1s interval. Raw WAL helpers default to:

• SyncMode::GroupSync
• 8 MiB target segment size

Node exposes syncMode for container-backed and explicit WAL opens. It does not expose WAL status or truncate helpers yet. If you need that operator surface today, use Rust directly or run lora-server.

What the WAL actually guarantees​

This is not "marketing durability." The contract is concrete:

• Every mutating query is logged before the call returns.
• Read-only queries write nothing to the WAL.
• Recovery replays only committed writes, in commit order.
• A torn tail on the active segment is truncated back to the last valid record.
• A checkpoint writes a snapshot stamped with walLsn, appends a checkpoint marker, and truncates safe WAL history up to that fence.

That means the engine now has a clean recovery staircase:

1. pure in-memory,
2. snapshot-only,
3. WAL-only,
4. snapshot + WAL checkpointing.

The important part is that each step is readable. The release does not blur "we can save a file" together with "we can recover committed writes." Those are different guarantees, and the docs now say so.

lora-server grows into an operator surface​

The HTTP server picks up the real production-adjacent durability knobs:

# Fresh boot with a WAL.
lora-server --wal-dir /var/lib/lora/wal

# Snapshot + WAL recovery.
lora-server \
  --wal-dir /var/lib/lora/wal \
  --snapshot-path /var/lib/lora/graph.bin \
  --restore-from /var/lib/lora/graph.bin

And the admin routes that make the log inspectable and manageable:

• POST /admin/wal/status
• POST /admin/wal/truncate
• POST /admin/checkpoint

WAL durability now uses GroupSync:

The server is still honest about its boundary: one process, one graph, no auth, no TLS, no multi-database routing. The durability story is stronger, but it is still a small local system, not a hosted graph service in disguise.

What did not change​

v0.4.0 is a durability release, not a reinvention of the product:

• LoraDB is still an in-memory engine.
• Snapshots are still manual and explicit.
• There is still no wall-clock checkpoint scheduler. Raw-WAL helpers can write managed snapshots after N committed transactions.
• Full checkpoint, truncate, and status controls still live on Rust and lora-server; Node exposes sync-mode control, while Python, Go, and Ruby keep the raw-WAL helper intentionally small.
• WASM stays snapshot-only and pathless, using saveSnapshot / loadSnapshot.
• The HTTP admin surface is still unauthenticated and meant to live behind your own ingress.

That last point matters. The new admin routes are useful, but only when deployed behind a boundary you control.

The docs changed with the product​

This release also forced a documentation cleanup across the website. The main fixes:

• the embedded-binding docs now state the initialization rule explicitly: no argument means in-memory, name plus directory means .loradb container-backed, and explicit WAL helpers own raw WAL directories;
• the HTTP server and API docs no longer describe a pre-WAL world;
• snapshots are now documented as a standalone primitive that can also act as a checkpoint target;
• there is a dedicated WAL page instead of scattering durability details across unrelated guides.

The result is that the website now answers the operational questions in the same place the release introduces them.

Read next​

• WAL and checkpoints
• Snapshots
• Node guide
• HTTP server quickstart
• HTTP API reference

v0.3 made "save the graph to one file" real. v0.4.0 makes "reopen the process and keep committed writes" real. That is the release.

Most databases I have worked with had a write-ahead log before they had a snapshot story. LoraDB went the other way.

At the time, v0.3 shipped manual point-in-time snapshots and nothing else on the persistence side. No append-only log. No background checkpoint loop. No continuous durability. One file on disk, taken on demand, atomic on rename.

The order is intentional, and it is the kind of decision that is easier to defend before the release than after.

The Default Narrative For "Adding Persistence"​

The default narrative for adding persistence to an in-memory database is some version of:

1. ship a write-ahead log,
2. background checkpoints flush state to disk,
3. on boot, replay the log on top of the latest checkpoint,
4. announce "durable."

That is what mature databases do, eventually. It is also the wrong first step for a project where the data model and the storage tier are both still settling.

A WAL is a long-term commitment to a concrete write path. Every mutation has to know how to serialize itself. Every recovery routine has to dispatch on event type. Every release after the first one inherits the log format, the recovery state machine, and the assumptions baked into both. Get any of that wrong on day one and the project carries the mistake forward — or pays for an expensive migration to fix it.

For a database that is two minor versions old and still figuring out what its read and write paths look like, that is too much surface area to commit to.

What A Snapshot Teaches That A WAL Would Not​

A snapshot is the lowest-risk way to learn the shape of "the graph as a serialized artifact." It forces the project to answer a small set of concrete questions:

• What does the file format look like? v0.3 answered with the original LORASNAP envelope; current releases write LORACOL1, a columnar snapshot payload with a BLAKE3 checksum plus compression and encryption metadata.
• How is the write atomic? <path>.tmp, fsync, rename over the target.
• How is the read atomic? Hold the store mutex, validate, swap the graph in one shot.
• What does the API look like across every binding? save_snapshot, load_snapshot, in_memory_from_snapshot, plus an opt-in HTTP admin surface.
• What does every binding return? A single SnapshotMeta shape with formatVersion, nodeCount, relationshipCount, and a reserved walLsn.
• What does the operator contract look like? --snapshot-path, --restore-from, off-by-default admin endpoints, no auth, behind ingress only.

None of those answers went away when the WAL arrived. A checkpoint, by definition, is a snapshot with a WAL LSN attached. In current releases, pure snapshots report walLsn: null; checkpoint snapshots stamp it with the durable WAL fence, and recovery replays committed records newer than that fence.

In other words, the snapshot work was not throwaway scaffolding. It is the foundation the current log now sits on.

What A Snapshot Is Honest About​

A snapshot is not durability. It is point-in-time persistence. The difference matters.

• A crash between two saves loses every mutation in the window.
• The store mutex is held for the duration of both save and load. Concurrent queries block.
• There is no incremental save. The whole graph serializes each time.
• There is no auto-cadence. Saves happen because someone called save_snapshot or hit the admin endpoint.

That set of caveats is also exactly what makes the primitive useful right now without overcommitting. A single-node service, a notebook, a seeded process, a service with a controlled shutdown window, a backup cron — all of those need the property "the graph as of now, written to one file." None of them need a continuous log to be useful.

The shapes that genuinely need a WAL — multi-node clusters, zero-data-loss writes, mid-second crash recovery — are not the shapes LoraDB is good at today. Building a half-finished log inside a single-process engine ends up with a journal that is less reliable than just snapshotting more often, and worse, with a contract that is harder to read.

Why Honest Boundaries Matter More Than Marketing​

The thing I see most often in databases that overpromised on durability is silent data loss between two undocumented seams. That happens when "persistent" is sold as a complete story before the moving parts have settled — when there is durability marketing language without a clean operator contract underneath.

The contract I want for snapshots is small enough to fit on a card:

• The save renames <path>.tmp over <path>. A crash mid-save can leave the .tmp file behind. It cannot leave a half-written <path>.
• The load swaps the live graph in one shot. Concurrent queries see the old graph or the new one. Never both. Never a partial.
• A crash between two saves loses every mutation in the window. Pick a cadence accordingly.
• The HTTP admin endpoints are off by default. They have no authentication. They are intended to sit behind your ingress.

That is what v0.3 ships. It is the smallest set of guarantees that actually mean what they say. None of them are advertised more aggressively than they are documented.

Where The Persistence Story Goes Next​

Three steps line up against the boundary above, in order.

A write-ahead log. This has since landed. Rust and lora-server expose the full WAL/checkpoint/status/truncate surface; Node, Python, Go, and Ruby expose container-backed opens plus explicit raw-WAL helpers. WAL checkpoints are snapshots with a meaningful walLsn, exactly the shape the snapshot contract prepared for.

Checkpoint automation. Current raw-WAL helpers can write managed snapshots after N committed transactions. The remaining boundary is wall-clock scheduling: if you want time-based checkpoints, run them from the host process, cron, systemd, or an operator loop.

Auth on the admin surface. Token-based auth in front of /admin/* so the endpoints can be enabled on hosts that face a real network without an external reverse proxy. Hosted operations come after that, not before — the moment to charge people to run LoraDB for them is the moment its operator contract is durable enough to charge for.

There is a fourth thread that is less visible but matters more: the contract should stay easy to read while it grows. Each step adds capability without adding ambiguity. A WAL should not turn "durable" into a fuzzy word; it should turn the existing snapshot contract into a strictly stronger one.

How This Fits The Customer Journey​

The persistence staircase mirrors the adoption staircase.

1. Discovery. A developer runs cargo run --bin lora-server and types a query. There is no persistence to think about yet.
2. Local prototype. They want to keep the graph between sessions. --snapshot-path and --restore-from are enough.
3. Internal service. They want graceful-shutdown saves and scheduled backups. POST /admin/snapshot/save from a systemd unit or a cron is enough.
4. Production with tighter SLAs. They need continuous durability — point-in-time recovery to the last committed WAL transaction, not the last manual save. That is where WAL-backed opens and checkpoints now fit.
5. Managed operations. They do not want to operate the engine at all. That is when the hosted platform takes over the snapshot cadence, the WAL config, and the auth boundary.

Each step adds capability the previous step's users do not regress on. That is the point of building from a snapshot up rather than a WAL down.

The Feedback That Will Shape v0.4​

The clearest signal for whether v0.3 lands is concrete:

• how big does your graph get, and how long does save_snapshot take at that size;
• what cadence did you settle on — seconds, minutes, on-shutdown only, every-N-mutations;
• did atomic rename land cleanly on your filesystem (we test on Linux ext4/xfs and macOS APFS);
• which binding did you use, and did the WASM pathless saveSnapshot / loadSnapshot surface fit your storage layer (IndexedDB, OPFS, a backend POST) without extra glue;
• what does your ingress look like for the admin endpoints — reverse proxy, Unix socket, or "not exposed at all";
• where did manual snapshots stop being acceptable for your workload, and what WAL sync/checkpoint cadence did you need?

The answers decide what cadence the WAL has to support, which crash windows we need to harden first, and which surfaces need the auth contract before the rest.

Closing​

LoraDB's persistence story is not "we shipped a quarter of a WAL." It is "we shipped the smallest persistence primitive that means what it says, and the next steps build on top of it without changing what we already promised."

Snapshots before a log is the order I would pick if I had to do this again. The right first step toward durability is not a journal. It is a contract.

Canonical references:

• Snapshots — file format, atomic-rename protocol, binding examples, and the security warning on the admin surface.
• HTTP server quickstart → Snapshots, WAL, and restore — --snapshot-path and --restore-from in context.
• v0.3 release notes — the team-side announcement, the full binding table, and the explicit list of what is still out of scope.

LoraDB v0.3 adds manual point-in-time snapshots.

You can now dump the entire in-memory graph to a single file and restore it later. The save is atomic on rename, the load replaces the live graph in one shot, and the feature is exposed on every surface that the engine talks through — the Rust core, the Python, Node, WASM, Go, and Ruby bindings, the shared C FFI, and the HTTP server as an opt-in admin endpoint.

What this release is not is full persistence. There is no write-ahead log, no background checkpoint loop, no continuous durability. A snapshot is exactly what the name says: a point-in-time dump you take on demand. Data mutated between two saves is lost on crash. That boundary is deliberate — making the explicit, operator- controlled shape work cleanly is the foundation a WAL will sit on, and it closes the "no persistence at all" gap for the workloads that only need occasional checkpoints today (seeded services, notebooks, controlled shutdowns, scheduled backups).

What Changed​

The short list:

• A new single-file snapshot format. v0.3 introduced the original LORASNAP format; current releases write the columnar LORACOL1 format with a BLAKE3 envelope checksum, compression metadata, and optional encryption metadata.
• Atomic saves — writes go to <path>.tmp, are fsync'd, and then renamed over the target. A crashed save never leaves a half-written file at the target path.
• Atomic loads — the store mutex is held for the full restore, so concurrent queries see the old or the new graph, never a partial one.
• A walLsn metadata slot for WAL/checkpoint recovery. Pure snapshots emit it as null; checkpoint snapshots written by WAL-backed surfaces stamp it with a durable fence.
• Forward-compatible reader — formats are dispatched by version, so today's v1 files will keep loading after the next format bump until support is deliberately dropped.
• Snapshot metadata (formatVersion, nodeCount, relationshipCount, walLsn) returned from path-based saves, load calls, and HTTP admin calls. Byte-output save helpers return bytes.

Binding support, using today's API names:

WebAssembly is source/byte-oriented by design — WASM has no filesystem path API, so the caller is responsible for persisting the Uint8Array or web-native wrapper to IndexedDB, OPFS, a backend upload, or wherever their app already stores state.

Why Snapshots Matter​

The v0.1 and v0.2 model was "one process, one in-memory graph, lost on exit." That is fine for notebooks, tests, demos, and embedded read-mostly caches, but it forces every operator into one of two patterns neither of which the engine supported well:

• Reload from source on every boot. Works if the source is cheap, but adds real seeding time on restart and pushes reload logic into every deployment.
• Rebuild a parallel persistence layer. The application writes every mutation to an external store, then replays it on boot. A second data model to maintain, a second consistency story.

Neither is what you want for the shape of workload LoraDB is actually good at: a graph view over data the host process already owns, or a small seeded context that the agent / service accumulates in memory. For those, the right primitive is a file on disk that captures "the graph as of this moment" — cheap to take, cheap to restore, no second data model.

That is what v0.3 ships. The Cypher surface does not change; the storage tier gets one save verb (save_snapshot), one load verb (load_snapshot), and one new file on disk.

What A Snapshot Is Not​

Same list as above, stated as the bright line:

• Not continuous durability by itself. A crash between two saves loses every mutation in the window. Current releases can pair snapshots with WAL-backed recovery when you need committed writes to survive crashes.
• Not a wall-clock checkpoint scheduler. Manual saves happen because the host process, an external cron, or the admin HTTP endpoint calls them. Current raw-WAL helpers can also write managed snapshots after N committed transactions.
• Not a general persistent storage tier. There is no storage backend other than the in-memory graph; the snapshot is a dump of that graph, not a format a different engine writes into.
• Not zero-cost at save time. The store mutex is held for the duration of the save. Concurrent queries wait. Pick a snapshot cadence that leaves headroom.
• Not a boundary for multi-tenancy. One process still holds one graph; each process needs its own snapshot path.

Those are not roadmap omissions hidden behind marketing language. They are what "simple, explicit, operator-controlled" means.

Using Snapshots​

Save and load from Rust​

The reference surface. Every other binding wraps these two methods.

use lora_database::Database;

let db = Database::in_memory();
db.execute("CREATE (:Person {name: 'Ada'})", None)?;

// Dump the full graph to disk.
let meta = db.save_snapshot_to("graph.bin")?;
println!(
    "{} nodes, {} relationships",
    meta.node_count, meta.relationship_count,
);

// Boot a fresh Database directly from the file.
let db2 = Database::in_memory_from_snapshot("graph.bin")?;

// Or restore onto an existing handle (concurrent queries block on the
// store mutex for the duration of the load).
db.load_snapshot_from("graph.bin")?;

Every save and load returns a SnapshotMeta:

{
  "formatVersion": 1,
  "nodeCount": 1024,
  "relationshipCount": 4096,
  "walLsn": null
}

The walLsn field is null for pure snapshots and non-null for checkpoint snapshots written by WAL-backed surfaces.

Save and load from Python​

from lora_python import Database

db = Database.create()
db.execute("CREATE (:Person {name: 'Ada'})")

meta = db.save_snapshot("graph.bin")
print(meta["nodeCount"], meta["relationshipCount"])

db2 = Database.create()
db2.load_snapshot("graph.bin")

The AsyncDatabase wrapper exposes the same two methods as coroutines:

import asyncio
from lora_python import AsyncDatabase

async def main():
    db = await AsyncDatabase.create()
    await db.execute("CREATE (:Person {name: 'Ada'})")
    await db.save_snapshot("graph.bin")

asyncio.run(main())

Both forms run with the GIL released / on a worker thread so the event loop stays free during large saves.

Save and load from Node / TypeScript​

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

const db = await createDatabase();
await db.execute("CREATE (:Person {name: 'Ada'})");

const meta = await db.saveSnapshot('graph.bin');
console.log(meta.nodeCount, meta.relationshipCount);

const db2 = await createDatabase();
await db2.loadSnapshot('graph.bin');

saveSnapshot / loadSnapshot return Promises that resolve to a SnapshotMeta object with the same formatVersion / nodeCount / relationshipCount / walLsn fields as every other binding.

Save and load from WebAssembly​

WASM has no filesystem path API, so the snapshot API is source-in / byte-out:

import { createDatabase } from '@loradb/lora-wasm';

const db = await createDatabase();
await db.execute("CREATE (:Person {name: 'Ada'})");

// Dump the graph to a Uint8Array.
const bytes: Uint8Array = await db.saveSnapshot();

// Persist the bytes wherever you already store state — IndexedDB,
// localStorage, a POST to your backend, `fs.writeFileSync` in Node.
// Later:
const db2 = await createDatabase();
await db2.loadSnapshot(bytes);

saveSnapshot can also return ArrayBuffer, Blob, Response, ReadableStream, or an object URL; loadSnapshot accepts URL, Uint8Array, ArrayBuffer, Blob, Response, or ReadableStream<Uint8Array | ArrayBuffer>. The Worker-backed surface (createWorkerDatabase) exposes the same saveSnapshot / loadSnapshot methods.

Save and load from Go​

import lora "github.com/lora-db/lora/crates/bindings/lora-go"

db, err := lora.New()
if err != nil { log.Fatal(err) }
defer db.Close()

if _, err := db.Execute("CREATE (:Person {name: 'Ada'})", nil); err != nil {
    log.Fatal(err)
}

meta, err := db.SaveSnapshot("graph.bin")
if err != nil { log.Fatal(err) }
fmt.Printf("nodes=%d rels=%d\n", meta.NodeCount, meta.RelationshipCount)

db2, err := lora.New()
if err != nil { log.Fatal(err) }
defer db2.Close()

if _, err := db2.LoadSnapshot("graph.bin"); err != nil {
    log.Fatal(err)
}

The Go FFI header (crates/bindings/lora-go/include/lora_ffi.h) now declares lora_db_save_snapshot / lora_db_load_snapshot alongside a LoraSnapshotMeta struct; the Go wrapper turns that into an idiomatic *SnapshotMeta with a nullable WalLsn pointer.

Restoring And Saving Through The HTTP Server​

lora-server exposes two opt-in admin endpoints for snapshot operations. They do not exist unless the server is started with --snapshot-path:

lora-server \
  --host 127.0.0.1 --port 4747 \
  --snapshot-path /var/lib/lora/db.bin \
  --restore-from  /var/lib/lora/db.bin

• --snapshot-path <PATH> mounts POST /admin/snapshot/save and POST /admin/snapshot/load against this file. Without the flag the routes return 404 — the admin surface is off by default.
• --restore-from <PATH> loads a snapshot at boot before the server accepts queries. A missing file is fine (empty graph, logged); a malformed file is fatal.

Once enabled, saving and restoring is a plain HTTP call:

curl -sX POST http://127.0.0.1:4747/admin/snapshot/save
# => {"formatVersion":1,"nodeCount":1024,"relationshipCount":4096,"walLsn":null,"path":"/var/lib/lora/db.bin"}

curl -sX POST http://127.0.0.1:4747/admin/snapshot/load

Both endpoints accept an optional { "path": "…" } body to override the configured default for a single request — useful for ad-hoc backups to a rotated filename:

curl -sX POST http://127.0.0.1:4747/admin/snapshot/save \
  -H 'content-type: application/json' \
  -d '{"path": "/var/backups/lora/2026-04-24.bin"}'

--restore-from is independent of --snapshot-path. You can restore from a read-only seed and save to a writable runtime path:

lora-server \
  --restore-from  /var/lib/lora/seed.bin \
  --snapshot-path /var/lib/lora/runtime.bin

Why Snapshots Are Useful With Or Without A WAL​

A snapshot is not a replacement for continuous durability, but it closes enough of the gap for many workloads. When paired with WAL, snapshots become the checkpoint artifact that keeps replay bounded:

• Seeded services. Build the graph offline from a cheaper source (SQL exports, a scrape, an ETL job), snapshot it, and ship the snapshot alongside the deployment. Every restart boots in one file-read rather than a multi-minute replay.
• Notebooks and research tooling. Save the graph you've curated at the end of a session; reload it the next morning with one call.
• Agents and LLM context stores. Periodic snapshots of the working graph give you trivial "go back to yesterday's state" without the complexity of a full transactional store.
• HTTP operator loop. ExecStop=curl … /admin/snapshot/save on a systemd unit gives a graceful-shutdown save without any new tooling. Add a --restore-from on boot and you have a durable- enough deployment for a single-node service.
• Scheduled backups. A cron that calls POST /admin/snapshot/save every N minutes, optionally with a rotating {"path": "…"}, is a complete backup policy for small graphs.

The bright line is still the same: a crash between saves loses every mutation in the window. The question to ask is whether that window is narrow enough for your workload. For most of the shapes above, it is.

What's Still Out Of Scope​

Explicitly not in this release, so the feature stays honest about its boundary:

• Snapshots alone are still not a WAL. Current releases have WAL-backed recovery on filesystem-backed surfaces, but a manual snapshot by itself is still only point-in-time persistence.
• No wall-clock scheduler. Manual snapshots run when you call them. Raw-WAL helpers can write managed snapshots after N committed transactions; wall-clock scheduling is still host/operator work.
• No partial / incremental snapshots. A save serializes the whole graph. For v0.3 the expected scale is graphs that fit in memory comfortably and dump in seconds.
• Non-blocking save. The store mutex is held for the full save. Concurrent queries block. Real per-mutation copy-on-write will come with deeper storage-engine work.
• No multi-graph file format. One file, one graph — same one-process model as the rest of the engine.
• No auth on the HTTP admin surface. Opt-in, off by default, and still not safe on a network-reachable host without an ingress.

Those are the things a future release will address. They are not hidden in the implementation — every one of them is a place the docs say so.

Try It​

Get the repo, build, and snapshot:

cargo run --bin lora-server -- \
  --snapshot-path /tmp/loradb.bin \
  --restore-from  /tmp/loradb.bin

Then from a second shell:

curl -sX POST http://127.0.0.1:4747/query \
  -H 'content-type: application/json' \
  -d '{"query":"CREATE (:Person {name:\"Ada\"})"}' > /dev/null

curl -sX POST http://127.0.0.1:4747/admin/snapshot/save
# => {"formatVersion":1,"nodeCount":1,"relationshipCount":0,"walLsn":null,"path":"/tmp/loradb.bin"}

Stop the server, start it again with the same flags, and the graph is still there.

The docs site has a dedicated page for snapshots — the file format, atomicity guarantees, binding examples, and the full HTTP admin surface:

• Snapshots
• HTTP server quickstart → Snapshots, WAL, and restore
• HTTP API → Admin endpoints (opt-in)

What Comes Next​

Three directions stood out after v0.3:

1. A WAL. This has since landed on every filesystem-backed surface, with Rust and lora-server exposing the full operator controls and embedded bindings exposing raw-WAL helpers.
2. Checkpoint automation. Current raw-WAL helpers can write managed snapshots after N committed transactions. Wall-clock scheduling remains a host/operator concern.
3. Auth on the admin surface. Token-based auth in front of /admin/* so the endpoints can be used on network-reachable hosts without an external reverse proxy.

If you try v0.3 with snapshots, the feedback that will shape those is concrete:

• how large does your graph get, and how long does save_snapshot take at that size;
• what cadence did you end up running — seconds, minutes, on shutdown only;
• did the atomic-rename guarantee land cleanly on your filesystem (we've tested on Linux ext4/xfs and macOS APFS);
• what does your ingress look like for the admin endpoints;
• which binding did you use, and did the byte-based WASM surface fit your storage layer (IndexedDB, OPFS, a backend POST) without extra glue.

That is the feedback that will shape v0.4.

LoraDB v0.2 adds first-class VECTOR values.

You can now construct vectors in Cypher, store them as node or relationship properties, pass them in as parameters through every binding, and run exhaustive similarity search against them. The value type, the wire format, the function surface, and the binding helpers all landed together so vectors behave like every other typed value in the engine.

What this release is not is a vector-index product. There is no approximate nearest-neighbour search, no built-in embedding generation, and no plugin compatibility layer. Those are deliberately out of scope for v0.2. The goal here is to make embeddings comfortable inside the graph model — to ship the foundation that an index-backed retrieval path will eventually sit on.

What Changed​

The short list:

• VECTOR is a first-class value type, alongside scalars, lists, maps, temporal values, and spatial points.

• Cast-based vector construction with value::VECTOR<COORD>(DIM).

• Six supported coordinate types:

  • FLOAT / FLOAT64
  • FLOAT32
  • INTEGER / INT / INT64 / INTEGER64
  • INTEGER32 / INT32
  • INTEGER16 / INT16
  • INTEGER8 / INT8

• Storage as node and relationship properties.

• vector.coordinates(v, INTEGER) and vector.coordinates(v, FLOAT) for converting coordinates back to lists.

• vector.dimension(v) and value.size(v) for introspection.

• vector.similarity(a, b) — cosine similarity bounded to [0, 1].

• vector.similarity(a, b, 'euclidean') — Euclidean similarity bounded to [0, 1].

• vector.distance(a, b, metric) — signed distance under one of six metrics.

• vector.norm(v, metric) — Euclidean or Manhattan norm.

• Parameter support through every binding.

• A canonical tagged wire shape:

  {
    "kind": "vector",
    "dimension": 3,
    "coordinateType": "FLOAT32",
    "values": [0.1, 0.2, 0.3]
  }
  

Language support is included in this release for:

• the Rust core;
• Node.js / TypeScript (crates/bindings/lora-node);
• WebAssembly (crates/bindings/lora-wasm);
• Python (crates/bindings/lora-python);
• Go (crates/bindings/lora-go);
• Ruby (crates/bindings/lora-ruby).

Each binding ships a vector(...) helper and an isVector / is_vector / IsVector / vector? guard, so callers do not need to build the tagged object by hand.

Why Vectors In A Graph Database​

A graph database and a vector store usually get treated as two products. The graph stores relationships; the vector store retrieves similar items; the application glues them together.

For most AI workloads that is the wrong shape. You want to retrieve candidates by similarity and use the graph to rank, filter, or explain them. When the embedding lives on a separate service, every query needs a round trip and every piece of context needs a join by hand.

Putting VECTOR into LoraDB as a value type collapses that separation. The embedding is a property on the same node that carries the label, the text, and the relationships. You score with vector.similarity(...) and walk with MATCH in the same Cypher.

That is the whole argument. Similarity finds candidates. The graph explains them.

Using VECTOR Values​

Creating A Vector Property​

CREATE (d:Doc {
  id:        1,
  title:     'Onboarding checklist',
  embedding: [0.1, 0.2, 0.3]::VECTOR<FLOAT32>(3)
})

The coordinate tag and dimension live in the target type: VECTOR<FLOAT32>(3), VECTOR<INTEGER>(384), and so on. CAST(value AS VECTOR<COORD>(DIM)) is the equivalent compatibility form.

Passing A Vector As A Parameter​

Generate the embedding in your application, pass it in with the language helper, and use it like any other parameter:

import { vector } from "@loradb/lora-node";

const query = vector(embedding, 384, "FLOAT32");

await db.execute(
  `MATCH (d:Doc)
   RETURN d.id AS id
   ORDER BY vector.similarity(d.embedding, $q) DESC
   LIMIT 10`,
  { q: query },
);

The same pattern works in Python (vector(values, dimension, coordinate_type)), Go (lora.Vector(values, dimension, coordinateType)), Ruby (LoraRuby.vector(values, dimension, coordinate_type)), and the raw FFI / JSON path used by the C ABI.

Bulk Insert​

The canonical way to load many embeddings is a single UNWIND over a parameter list of rows. Each row is a map with scalar fields and a tagged vector. The engine fans the list into per-row CREATEs without round-tripping each one:

import { vector } from "@loradb/lora-node";

const batch = docs.map((doc) => ({
  id:        doc.id,
  title:     doc.title,
  embedding: vector(doc.embedding, 384, "FLOAT32"),
}));

await db.execute(
  `UNWIND $batch AS row
   CREATE (:Doc {id: row.id, title: row.title, embedding: row.embedding})`,
  { batch },
);

The same shape in Python:

from lora_python import Database, vector

db = Database.create()

batch = [
    {
        "id":        doc["id"],
        "title":     doc["title"],
        "embedding": vector(doc["embedding"], 384, "FLOAT32"),
    }
    for doc in docs
]

db.execute(
    """
    UNWIND $batch AS row
    CREATE (:Doc {id: row.id, title: row.title, embedding: row.embedding})
    """,
    {"batch": batch},
)

Two things are worth knowing about this pattern. First, each vector is stored as its own property on its own node — the batch is a list of maps, not a list of vectors, so the property rule (no lists of vectors) is satisfied by construction. Second, UNWIND runs the whole batch in one query, so the per-row overhead is a map extraction and a CREATE, not a full parse + plan + execute cycle per document.

Exhaustive kNN​

MATCH (d:Doc)
RETURN d.id AS id
ORDER BY vector.similarity(d.embedding, $query) DESC
LIMIT 10

Every MATCH candidate is scored. Cost is O(n) in the number of matched nodes. That is fine for a local dataset, a test, a demo, or a small internal tool. It is not how you would serve a corpus of millions — that is what vector indexes are for, and they are not implemented yet.

Graph-Filtered Retrieval​

The version that actually motivated adding vectors to LoraDB looks like this:

MATCH (d:Doc)
WITH d, vector.similarity(d.embedding, $query) AS score
MATCH (d)-[:MENTIONS]->(e:Entity)
WHERE e.type = $entity_type
RETURN d.id, d.title, score, collect(e.name) AS entities
ORDER BY score DESC
LIMIT 5

The similarity function supplies the candidates. The graph structure (MENTIONS, the entity type filter) explains and constrains them. Both live in one query and one engine.

Storing And Reading Back​

Vectors round-trip through storage unchanged:

CREATE (:Doc {id: 1, embedding: [1, 2, 3]::VECTOR<INTEGER>(3)})
MATCH (d:Doc {id: 1}) SET d.embedding = [0.1, 0.2]::VECTOR<FLOAT32>(2)
MATCH (d:Doc {id: 1}) RETURN d.embedding AS e

A vector is also a legal map value, so a property map containing a vector is stored intact. The one restriction is that a list containing vectors cannot be stored as a property — if you need many embeddings, hang them off separate nodes. The engine rejects the write at property-conversion time instead of silently storing a shape a future vector index could not support.

AI Use Cases​

Vectors in LoraDB are aimed at the workloads that already sit awkwardly between "vector store" and "graph database":

• Agent memory. Embed documents, chunks, observations, or tool calls. Connect them with edges to the sessions, entities, and decisions that reference them. Retrieve by similarity, filter by recency, explain by provenance.
• Semantic document retrieval with context. Find the k closest docs, then expand to the entities, authors, or topics they connect to before returning anything to the application.
• Tool and context selection. Score candidate prompts, tools, or examples by similarity to the current state, then filter by graph constraints (same tenant, same permission scope, same task type).
• Knowledge graph enrichment. Attach embeddings to entities so fuzzy lookups can locate the right node before structural queries run.
• Recommendations with graph guardrails. Cosine similarity produces a long list of candidates; graph relationships (BLOCKED, ALREADY_SEEN, OWNED_BY) filter that list before ranking.
• Internal search over connected product, customer, or support data. Small corpora, high structure, and queries that want both "similar to this ticket" and "in the same account and escalation path."

Every one of those workloads has the same shape: similarity for candidates, structure for the rest.

What Is Not Included Yet​

This release is deliberately narrow. It does not include:

• Vector indexes. All vector functions are exhaustive today.
• Approximate nearest-neighbour search. There is no ANN path.
• Built-in embedding generation. LoraDB does not produce embeddings; bring them in from your application code.
• Hardened public-internet database hosting. The HTTP server is useful for local development and controlled environments. It is not a managed service.

Those are not hidden. They are the roadmap.

Exhaustive similarity is fine for small datasets, tests, demos, local prototypes, and internal workflows. It is not yet a substitute for an index-backed vector search service at scale.

Why This Fits The LoraDB Journey​

LoraDB is developer-first.

That sequencing applies to vectors too. The first version needs the value model, the wire shape, the binding helpers, and the Cypher ergonomics to be right. Those are the parts that user code and tests depend on. A vector index that sits on a broken value model would inherit every problem. Shipping the foundation first, and being honest about the absence of an index, keeps the upgrade path clean.

It also matches how developers actually pick up a new capability. Clone the repo, generate a few embeddings, store them on nodes, write a similarity query, see whether the model fits the problem. Only after that does scale, persistence, and managed operations become worth talking about.

v0.2 makes that first loop work.

Try It​

Get the repo and run the server:

cargo run --bin lora-server

Then try a vector query from curl or any binding:

curl -X POST http://127.0.0.1:4747/query \
  -H 'content-type: application/json' \
  -d '{"query":"RETURN [1,2,3]::VECTOR<INTEGER>(3) AS v"}'

The docs site has a dedicated page for the value type, the coordinate rules, the functions, the storage restrictions, and the exhaustive kNN pattern:

• Data types → Vectors
• Functions → Overview
• Queries → Parameters

Internal notes on the value model and the Cypher support matrix have been updated to match.

What Comes Next​

Three directions stand out after v0.2:

1. A vector index. The Cypher shape stays the same (ORDER BY vector.similarity(...) LIMIT k); the executor starts routing scored candidates through an index instead of a linear scan. The design depends on the workloads people actually bring.
2. More metrics and norms as real usage demands them. The current set (EUCLIDEAN, EUCLIDEAN_SQUARED, MANHATTAN, COSINE, DOT, HAMMING for distance; EUCLIDEAN and MANHATTAN for norm) covers the common cases. Extending is mechanical once a concrete need shows up.
3. The hosted path. Vectors on stored nodes eventually need managed operations to match. That is a separate release, but the value-type work here is what makes it possible without a second data model.

If you try v0.2 with vectors, the most useful feedback is concrete:

• what graph did you load, and what embedding workflow did you pair with it;
• where did exhaustive scan stop being enough;
• what would a vector index need to support for your workload — a specific metric, a specific filter shape, a specific freshness guarantee;
• which binding did you use, and did the tagged shape round-trip cleanly through your application code.

That is the feedback that will shape v0.3.

The conventional advice for AI retrieval is to pick a side.

You pick a vector database if you want similarity. You pick a graph database if you want structure. You bolt them together with glue code when the product inevitably needs both.

That framing has never matched the workloads I actually care about. The interesting systems — agent memory, recommendations, internal search over connected product data, knowledge graphs that feed chat features — do not want a vector store or a graph store. They want to retrieve candidates by similarity, then explain and filter those candidates by relationships. Splitting that into two products splits the query path, the data model, and eventually the team.

LoraDB v0.2 adds VECTOR as a first-class value type. Vectors live directly on nodes and relationships, next to labels, properties, and edges. The argument is not that a graph database should replace a vector database. The argument is that similarity belongs next to the relationships that give it meaning.

Similarity Is Useful, But It Is Not Memory​

Embeddings are good at one thing: finding items that are close to a query in some learned semantic space. That is genuinely useful. A lot of retrieval systems live or die on whether the top ten candidates contain the right answer.

But similarity alone does not preserve the information a product usually needs around that answer:

• Where did this chunk come from?
• Which entities does it mention?
• Which session produced it?
• What depends on it?
• What contradicts it?
• Is it more recent than the other candidates?
• Is it from a trusted source?

A flat list of similar chunks cannot answer those questions. The relationships have to be recorded somewhere, and the system that retrieves embeddings has to reach that somewhere cheaply. When those two things live in different databases, "cheaply" stops being a local property of the query engine.

That is why vectors belong next to the graph, not behind a sidecar.

The Agent Memory Shape​

Think about what an agent actually stores across a session.

It stores documents or chunks, with embeddings so they can be retrieved by similarity. It stores entities extracted from those documents. It stores tool calls and their arguments. It stores decisions, observations, and the context that led to each one. It stores edges between those things: this observation led to that decision; this tool was selected because of that memory; this document mentions those entities.

That is a graph. And it is a graph with embeddings on some of the nodes.

A small version looks like this:

CREATE (d:Doc {
  id:        'doc-17',
  title:     'Onboarding checklist',
  embedding: $embedding::VECTOR<FLOAT32>(384)
})
CREATE (e:Entity {name: 'Alice'})
CREATE (d)-[:MENTIONS]->(e)
CREATE (o:Observation {session: 's1', ts: temporal.now()})
CREATE (o)-[:OBSERVED_IN]->(d)

Later, when the agent needs to retrieve memory, the query is not "find the ten closest chunks." The useful query is "find the ten closest chunks, show which entities they mention, and give me enough structure to rank or filter":

MATCH (d:Doc)
WITH d, vector.similarity(d.embedding, $query) AS score
MATCH (d)-[:MENTIONS]->(e:Entity)
RETURN d.id, d.title, score, collect(e.name) AS entities
ORDER BY score DESC
LIMIT 5

Similarity finds the candidates. The graph explains them.

That shape is easier to build — and easier to debug — when the embedding is a property on the same node that carries the relationships. There is no sync process, no second database, no second query pipeline. There is one model.

Why VECTOR Is A Value Type​

A vector in LoraDB is not a special table or a separate index namespace. It is a value type, like a string or a point or a duration. That design choice has consequences.

A LoraVector has:

• a fixed dimension (1..=4096);
• a typed coordinate choice (FLOAT64, FLOAT32, INTEGER, INTEGER32, INTEGER16, INTEGER8);
• its coordinates stored in a single typed array.

It can appear anywhere a value can appear:

• as a node property: CREATE (:Doc {embedding: [...]::VECTOR<FLOAT32>(384)})
• as a relationship property: CREATE (a)-[:SIM {score: [...]::VECTOR<FLOAT32>(3)}]->(b)
• as a Cypher parameter: pass a binding helper value or cast a list parameter in the query
• inside a RETURN, WITH, ORDER BY, or WHERE clause.

Every binding speaks the same canonical tagged shape:

{
  "kind": "vector",
  "dimension": 3,
  "coordinateType": "FLOAT32",
  "values": [0.1, 0.2, 0.3]
}

This is not only a wire format. It is the thing the Node.js, WASM, Python, Go, and Ruby helpers build. A developer in any of those languages can construct a vector in application code, pass it in as a parameter, store it on a node, read it back, and get the same tagged object on the other side. No bridge code. No JSON schemas to keep in sync.

That value-type framing also forces a property-storage rule worth stating out loud: a vector is fine as a property, but a list of vectors is not. If you want many vectors, hang them off separate nodes with separate embeddings. That restriction is enforced at write time — the engine rejects the property instead of silently storing a shape that future indexing could not support.

Why Exhaustive First​

v0.2 ships vectors, but it does not ship vector indexes. That is a deliberate line.

What works today is exhaustive similarity search. You write a MATCH that produces a candidate set, you score every candidate with vector.similarity(...) or vector.distance(...), you ORDER BY score DESC LIMIT k. The engine scans every matched node.

For a graph of a few hundred thousand embeddings, this is completely fine on a laptop. For millions, you want a proper index. The difference is not in the query language — the ORDER BY … LIMIT k shape is the same either way — it is in what the engine does under the hood.

Shipping exhaustive first lets v0.2 land the parts that are hardest to change later:

• the VECTOR value type and its coordinate rules;
• the tagged wire shape that every binding speaks;
• the property-storage semantics;
• the function surface (vector.similarity, vector.distance, vector.norm, vector.coordinates, vector.dimension, value.size(vector));
• the Cypher ergonomics, including the bare-identifier rewrite that lets you write INTEGER8 and EUCLIDEAN without declaring them as variables.

Those are the decisions that bindings, tests, and user code depend on. If we got any of them wrong, a vector index would inherit the mistake. The order is: value model first, index-backed retrieval later.

It also matches LoraDB's customer journey. The first question is not "can this serve ten million embeddings?" The first question is "does the model fit my problem?" An exhaustive scan over a thousand docs is enough to answer that.

What is explicitly not included in v0.2 is worth stating plainly:

• no vector indexes;
• no approximate nearest-neighbour search;
• no built-in embedding generation;
• no hardened public-internet database hosting.

Generate your embeddings in application code — whatever you already use, whether that is a hosted API, a local model, or a batch job — and pass them in as parameters. The database's job is to store them next to the graph and let you query both in one language.

The Customer Journey For Vectors​

The flow I want for a developer adopting vectors in LoraDB mirrors the one I wanted for adopting LoraDB at all.

1. They have a retrieval problem that is not purely similarity — there is structure around the items they want to find.
2. They generate embeddings in application code and store them on graph nodes with a single CREATE.
3. They run vector.similarity(...) against a small local dataset. The query shape is ordinary Cypher.
4. They add MATCH patterns that filter or explain the results using relationships.
5. They build a prototype, a tool, or a product feature on that combined query.
6. When the dataset grows past what an exhaustive scan can serve, they move to an index-backed variant — without rewriting the application, because the Cypher stays the same.
7. Eventually, managed operations follow.

That is the same staircase as before. Local trust first, persistence and platform later. Vectors fit because they slot into the same model as everything else LoraDB stores.

Closing​

Similarity helps you find candidates. Graphs help you explain them.

Most of the AI systems I care about — agent memory, internal search over connected data, recommendations with guardrails, knowledge graphs that feed chat — need both. The mistake is treating that as two products. LoraDB v0.2 is the argument that it should be one.

The v0.2 release article has the full list of what landed, the functions, the binding support, and the Cypher examples. The short version is that vector is now a value you can put on a node, pass as a parameter, and query with a few small honest functions. The longer version is everything we are not trying to be — a vector-index product, a hosted ANN service, a plugin marketplace — because the first job is to make the graph model comfortable with embeddings sitting on it.

If you try it, the feedback I want is concrete:

• what graph did you load, and what embedding workflow did you pair with it;
• what did the query look like once similarity and structure were in the same Cypher;
• at what size did the exhaustive scan stop being good enough;
• what would a vector index need to support for your workload — a specific metric, a specific filter shape, a specific freshness guarantee?

That is what will shape the next release.

Canonical references:

• Data Types → Vectors — construction, storage, and the list-of-vectors property restriction.
• Functions → Overview — the vector similarity and distance functions used above.
• Queries → Parameters — how each binding passes a VECTOR in.
• Cookbook → Vector-retrieval patterns — top-k and graph-filtered retrieval recipes.
• Limitations → Vectors — flat-scan vector index procedures, no ANN structure, no embedding generation today.

LoraDB is now public.

It is a fast in-memory graph database written in Rust, with a Cypher-shaped query engine, an HTTP API, and bindings for Node.js, WebAssembly, and Python. It is built for developers who need relationship queries close to their application without adopting a large graph database stack on day one.

This release is the beginning of the public journey: source-available core, developer-first adoption, and a path toward a hosted platform for teams that want managed operations later.

What LoraDB Is​

LoraDB is an in-memory property graph database.

It stores:

• nodes with labels and properties;
• relationships with a type, direction, endpoints, and properties;
• scalar values, lists, maps, temporal values, and spatial points;
• query results in row, graph, row-array, and combined formats.

It speaks a Cypher-like query language because Cypher is still one of the best ways to express graph patterns:

MATCH (person:Person)-[:KNOWS]->(friend:Person)
WHERE person.name = $name
RETURN friend.name, friend.age
ORDER BY friend.age DESC
LIMIT 10

Under the hood, LoraDB is split into small Rust crates:

• lora-ast for query syntax structures;
• lora-parser for parsing;
• lora-analyzer for semantic analysis;
• lora-compiler for logical and physical planning;
• lora-executor for running plans;
• lora-store for graph storage;
• lora-database for the database entry point;
• lora-server for the HTTP server;
• lora-node, lora-wasm, and lora-python for language bindings.

The goal is not to hide the database behind a giant internal system. The goal is to make the engine readable enough that developers can understand how a query moves from text to result.

Why It Exists​

LoraDB exists because many graph workloads need to be fast, local, and efficient before they need to be distributed.

Existing graph databases like Neo4j are powerful, but for the workloads that started this project, they felt too heavy. I wanted a database that could live in the application loop, load quickly, run in memory, and make storage costs easy to reason about.

That means LoraDB is optimized for a specific first experience:

1. Clone the repo.
2. Run the server.
3. Load a graph.
4. Write a Cypher query.
5. Understand the result and the code path behind it.

The hosted platform will come later. The core has to earn developer trust first.

What You Can Do Today​

Run the server​

cargo run --bin lora-server

By default, the server listens on 127.0.0.1:4747.

Send a query:

curl -X POST http://127.0.0.1:4747/query \
  -H 'content-type: application/json' \
  -d '{"query":"CREATE (:Person {name: \"Ada\"}) RETURN 1 AS ok"}'

Check health:

curl http://127.0.0.1:4747/health

Use the Rust API​

The Rust API is the most direct way to embed LoraDB in another Rust program:

use lora_database::Database;

let db = Database::new();
let rows = db.execute("MATCH (n) RETURN n LIMIT 10")?;

Use language bindings​

This repository includes package work for:

• Node.js / TypeScript through crates/bindings/lora-node;
• WebAssembly through crates/bindings/lora-wasm;
• Python through crates/bindings/lora-python.

The bindings are part of the same public release because the customer journey should not stop at Rust. Graph workloads show up in web apps, notebooks, automation tools, agent runtimes, and backend services.

Query Support​

This release includes a substantial Cypher-shaped query surface:

• MATCH and OPTIONAL MATCH;
• WHERE;
• RETURN;
• WITH;
• ORDER BY, SKIP, LIMIT, and DISTINCT;
• UNWIND;
• UNION and UNION ALL;
• CREATE;
• SET;
• DELETE and DETACH DELETE;
• REMOVE;
• MERGE with ON CREATE and ON MATCH;
• variable-length paths;
• shortestPath() and allShortestPaths();
• aggregation functions;
• list, string, math, temporal, spatial, conversion, and entity functions.

It also supports parameter binding through the Rust API and typed values for common graph workloads.

Storage And Execution​

The storage layer is intentionally in-memory. That is the point of this first release.

LoraDB is designed around:

• cheap local iteration;
• predictable graph traversal;
• explicit query stages;
• small intermediate representations;
• clear Rust ownership boundaries;
• enough structure to evolve toward persistence without hiding current costs.

The planner and executor are still young, but they already handle meaningful graph patterns, projection, filtering, aggregation, updates, and paths. The project is written so performance work can happen in the open, with the storage and execution model visible to contributors.

Documentation​

The documentation site includes:

• getting started guides for every binding;
• query language pages covering each supported clause;
• function references — string, math, list, aggregation, temporal, spatial;
• data type references — scalars, lists, maps, temporal, spatial, vectors;
• concept docs for the graph model and schema-free behaviour;
• cookbook recipes by domain;
• troubleshooting;
• known limitations.

The root repository also includes architecture, testing, operations, and release documentation for contributors who want to understand or improve the engine.

License​

The LoraDB core is licensed under the Business Source License 1.1.

The license allows:

• development use;
• non-production use;
• internal business use;
• internal production systems;
• reading, modifying, and distributing the source under the BSL terms.

The license does not allow using the core to offer LoraDB as database-as-a-service, a hosted API for third parties, a competing managed database platform, or a hosted resale product.

Each covered release converts to Apache License 2.0 on the Change Date listed in the root LICENSE file. For this release policy, that date is April 19, 2029.

The documentation website under apps/loradb.com is separately MIT licensed.

The goal is simple: developers should be able to adopt and trust the core, while the hosted platform business remains sustainable.

What Is Not Included Yet​

This release was intentionally honest about what it was not. Current releases have since added snapshots and WAL-backed local durability; the rest of this section is the public-launch boundary.

At public launch, LoraDB did not yet include:

• durable disk persistence;
• WAL or snapshots;
• clustering;
• replication;
• authentication;
• TLS termination;
• transactions across concurrent clients;
• property indexes for every workload;
• a managed cloud service.

The HTTP server is useful for local development, internal experiments, and controlled environments. Even with today's opt-in snapshot and WAL admin routes, it is not yet a hardened internet-facing database server.

Those limitations are not hidden. They are the roadmap.

Who Should Try It​

Start with the installation guide and the ten-minute tour to walk through the Cypher surface.

Try LoraDB if you are:

• building an internal tool with relationship-heavy data;
• experimenting with graph memory for agents;
• prototyping a knowledge graph;
• looking for a Rust graph database engine you can read;
• evaluating whether Cypher-shaped queries fit your product;
• tired of starting with a large graph stack before you know the model works.

Do not choose LoraDB yet if you need mature distributed operations, long-term durability, multi-region replication, or hardened public database hosting today.

What Comes Next​

The next phase has three tracks.

1. Core database maturity​

More planner work, better indexing, tighter memory usage, clearer error messages, and deeper test coverage for Cypher behavior.

2. Persistence​

The in-memory engine is the foundation. The next durable layer should preserve the simplicity of the current store while adding snapshots, recovery, and a path toward production workloads that outlive a process.

3. Hosted platform​

The long-term product is a hosted LoraDB platform for teams that want the graph model without operating the database themselves. That means managed projects, backups, metrics, auth, scaling, and support.

The public core and the hosted product are not in conflict. The core creates developer adoption. The hosted platform turns that adoption into a sustainable business.

Closing​

LoraDB started from a practical frustration: I needed a graph database that was fast enough to live in memory, efficient enough to trust, and small enough to understand.

This public release is the first serious step toward that goal.

If you try it, the most useful feedback is concrete:

• what graph did you load;
• which query did you expect to be easy;
• where did performance surprise you;
• which limitation blocked you;
• which docs page did you wish existed.

That feedback will shape the next release.

Welcome to LoraDB.

The easiest way to misunderstand LoraDB is to see the open core and the hosted platform as separate ideas.

They are the same journey.

The core database has to be developer-first because graph databases ask for a lot of trust. You are not just storing records. You are putting relationships, paths, and product logic into a system that needs to be correct and fast. If a developer cannot run it locally, inspect it, and build confidence in the query engine, the hosted product has no foundation.

Trust Starts Before Production​

The first customer is usually not a procurement team. It is one developer with a problem that keeps resisting simpler models.

They have a set of entities. The relationships matter. SQL joins are becoming awkward. A document model hides too much structure. A vector database retrieves similar things, but it does not explain how they connect.

That developer does not want a sales call first. They want to try the thing.

For LoraDB, the first trust moment should look like this:

cargo run --bin lora-server

Then a query:

MATCH (a:Account)-[:OWNS]->(p:Project)-[:DEPENDS_ON]->(s:Service)
WHERE a.id = $account
RETURN p.name, collect(s.name) AS services

Then a reaction: "This is the shape of my problem."

Everything before that moment is friction.

Why Source-Available Core Matters​

For infrastructure, source availability is not only about ideology. It is a trust tool.

Developers can inspect the parser. They can read the planner. They can see where values are represented. They can understand limitations without waiting for marketing language to become documentation.

That is especially important for a young database. LoraDB should not ask people to believe that every edge case is solved. It should show the work:

• here is the AST;
• here is semantic analysis;
• here is logical planning;
• here is physical execution;
• here is the in-memory store;
• here are the tests.

That transparency is part of the product.

Why Not Fully Open For Hosted Resale​

The other side of the strategy is the BSL license.

The goal is not to stop developers from using LoraDB. The goal is to stop the core engine from being repackaged immediately as a competing hosted database service by someone who did not build or maintain it.

That boundary is important because database companies need long time horizons. The hard work is not only writing a parser or a store. It is maintaining the engine, supporting users, improving performance, documenting behavior, and building the operational platform around it.

The BSL lets LoraDB be open enough for adoption while protecting the hosted business model:

• internal business use is allowed;
• development and non-production use are allowed;
• source reading and modification are allowed;
• hosted database-as-a-service for third parties is restricted;
• each version converts to Apache 2.0 after the Change Date.

That is the intended balance.

The Journey In Four Stages​

The customer journey I want is deliberately simple.

1. Discovery​

A developer finds LoraDB because they need a graph, not because they want a platform. They read the docs, run examples, and try the query model.

The goal here is clarity. The website should explain what LoraDB is and what it is not. The repo should be readable. The license should be explicit.

2. Local Adoption​

The developer builds a prototype with local data. They care about:

• quick setup;
• familiar Cypher-shaped queries;
• predictable performance;
• useful errors;
• enough documentation to keep moving.

This is where an in-memory engine shines. No cluster. No hosted account. No waiting for infrastructure.

3. Internal Production​

The team starts using LoraDB in an internal tool, agent memory system, workflow engine, or product feature where the graph is close to the application.

They care about reliability, performance, and whether limitations are honest. This is why docs, tests, and release notes matter as much as features.

4. Managed Operations​

Eventually, some teams do not want to operate the database themselves. They need persistence, backups, monitoring, auth, scaling, and support.

That is where the hosted platform belongs. It should not replace developer adoption. It should follow it.

Why This Matters For Product Quality​

A hosted-first database can accidentally optimize for the buyer before the builder. LoraDB should optimize for the builder first.

That affects product decisions:

• keep the core small enough to understand;
• make docs practical, not ornamental;
• publish limitations clearly;
• make release notes explain why changes matter;
• keep local development fast;
• protect the hosted business without making the core feel closed.

The hosted platform becomes credible only if the core earns trust.

What I Want LoraDB To Feel Like​

I want LoraDB to feel like a database you can pick up in an afternoon and still respect after a month.

Small enough to understand. Fast enough to stay close to the application. Efficient enough that the business model does not depend on waste. Clear enough that a developer can explain it to a teammate.

That is the bridge from developer trust to hosted platform.

The final post in this series is the public release announcement: what LoraDB is today, what is included, what is intentionally not included yet, and where the project goes next.

When people talk about graph databases, they usually talk about query languages, visualizations, and relationship modeling. All of that matters. But for the kind of database I wanted, the deeper product question was storage.

If the database is in memory, storage efficiency is not an implementation detail. It is the product boundary.

Every extra allocation is less graph. Every unnecessary clone is less fan-out. Every vague data structure is a future performance mystery. A graph database can have a beautiful query language and still feel wrong if the storage layer wastes the machine.

The Real Cost Of A Graph​

Graphs are expensive in a specific way.

A node is not just a row. It has labels, properties, and identity. A relationship is not just a foreign key. It has direction, type, endpoints, and often properties of its own. A traversal needs to find the next relationships quickly, then carry enough state to avoid incorrect paths, cycles, or duplicate rows.

That means the storage layer needs to answer several questions cheaply:

• Which nodes have this label?
• Which relationships leave this node?
• Which relationships enter this node?
• Which relationships have this type?
• What properties are needed for this query?
• Can the executor avoid materializing more than it returns?

If the answer to all of those questions is "scan and allocate," the database may still be simple, but it will not be efficient.

What Bothered Me About Existing Options​

This is where my frustration with existing graph databases became concrete.

I liked the graph model. I liked Cypher. I liked being able to express a path in a way that looked like the domain. What I did not like was the cost profile around many systems: too much memory overhead for small graphs, too much operational weight for local workloads, too much indirection when the graph was supposed to be close to the application.

Many graph databases are built for broad, durable, server-side workloads. That comes with real strengths. It also means they carry machinery that a fast embedded or in-process graph engine may not need.

LoraDB starts from a different question:

If the working set is in memory, what is the smallest honest storage model that can support expressive graph queries?

That question shaped the project more than any single feature.

Storage Has To Match The Query Engine​

The easiest way to build a database is to keep storage generic and make the executor compensate. The executor can scan, filter, clone, sort, and project until the result is correct.

Correct is not enough.

The storage layer and query engine have to meet in the middle. If a query only needs n.name, storage should not force the executor to materialize the whole node. If a pattern expands out from a known node, the executor should be able to ask for outgoing relationships directly. If a label narrows the candidate set, the planner should be able to use that fact.

That is why LoraDB is split into small crates. Storage, analyzer, compiler, and executor each have a narrow job, but the boundaries are designed so efficiency can move through the pipeline.

The planner can preserve useful shape. The executor can request the values it needs. The store can provide graph-oriented access paths instead of pretending everything is a table.

Memory Is A Budget, Not A Pool​

An in-memory database makes memory visible. That is good.

Disk-first systems can sometimes hide inefficient intermediate structures behind page caches, background work, or larger machines. In-memory systems do not get that luxury. If a query creates too many rows or keeps too many values alive, you feel it quickly.

That pressure leads to better engineering:

• prefer stable identifiers over copying whole entities;
• project only what the query asks for;
• keep intermediate rows narrow;
• make path expansion explicit;
• choose data structures whose cost can be explained;
• avoid turning every operation into a serialization boundary.

The result is not just better performance. It is better developer experience, because the system becomes easier to reason about.

Efficient Storage Changes The Customer Journey​

Storage efficiency is not only about serving large users. It helps the first user too.

A developer evaluating LoraDB should be able to start with a laptop and a real slice of data. They should not need to provision an oversized machine because the graph representation is bloated. They should not need to design a caching strategy before writing the first useful query.

Efficient storage makes the journey smoother:

1. The local prototype feels fast.
2. The first internal workload stays cheap.
3. The team trusts that performance comes from the engine, not from accident.
4. The hosted platform later has a strong unit economics base.

That last point matters. A hosted database company lives or dies on efficiency. If the core engine wastes memory, the cloud product either becomes expensive or slow. LoraDB's business strategy depends on the same thing the developer experience depends on: doing more with less.

What "Efficient" Means For LoraDB​

For LoraDB, efficient storage means:

• graph-native access to nodes and relationships;
• predictable in-memory structures;
• cheap directional traversal;
• clear ownership and borrowing in Rust;
• minimal materialization between query stages;
• APIs that can evolve toward persistence without hiding current costs.

It does not mean the first version is finished. It means the system is built around the right constraint.

I would rather have a smaller database with a storage model I can explain than a larger database that only feels fast in benchmark slides.

The Standard I Want​

The standard for LoraDB is simple:

When a developer asks why a query used the memory it used, we should be able to answer.

When a customer asks why hosted LoraDB can be cost-effective, the answer should start in the storage engine, not in pricing tricks.

When a contributor opens the code, the core data structures should be legible.

That is why efficient storage is not a hidden concern. It is the product.

The next post is about trust: how a developer-first graph database becomes a real customer journey instead of just a repository with good intentions.

The phrase "in-memory database" can sound like a performance trick. For LoraDB, it is more basic than that. The product I wanted to build did not make sense if the graph was slow to touch.

Graphs are not like simple key-value lookups. The interesting queries walk. They expand. They branch. They filter while moving through relationships. A single product interaction can turn into a set of small traversals that need to feel instant.

If the graph is on the hot path, latency is not an optimization. It is the product.

The Moment A Graph Becomes Product Logic​

The first version of a graph workload is often a background report:

MATCH (a)-[:CONNECTED_TO*1..3]->(b)
RETURN a, b
LIMIT 100

That can be slow and still useful. Someone waits, gets an answer, and learns something.

But the workloads I cared about moved closer to the user:

• Which related entities should appear while someone is typing?
• Which memories should an agent read before choosing a tool?
• Which product, document, or event is connected enough to matter now?
• Which path explains why two things are related?

Those are not nightly jobs. Those are interaction-time questions.

Once a graph query becomes product logic, a few milliseconds change the shape of what you can build. You stop treating the graph as a separate analytics system and start treating it as part of the application runtime.

That is where in-memory starts to matter.

Why A Remote Database Often Felt Wrong​

Remote databases are powerful. They centralize state. They add durability, access control, replication, backup, and operational boundaries.

They also add distance.

For a graph workload, that distance can be painful because the query engine is already doing pointer-heavy work. Relationship expansion is not one lookup; it is a sequence of dependent reads. If the system has to cross process, network, serialization, and storage boundaries for every meaningful step, the database may still be correct, but the product no longer feels direct.

With LoraDB, I wanted the first experience to be different:

• the graph lives next to the code;
• the query engine runs in the same machine;
• the storage layout is optimized for traversal;
• the cost of experimenting is low;
• tests can spin up a database without infrastructure.

That is not the only valid architecture. It is the right first architecture for the customer journey I wanted.

Fast Is Not Just Benchmarks​

I care about benchmarks, but benchmarks are not the whole story.

For a developer trying a database, "fast" means:

• the server starts quickly;
• small graphs load quickly;
• common queries complete without surprise;
• the API does not force unnecessary data conversion;
• the result shape is predictable;
• the failure mode is understandable.

A graph database can post impressive numbers and still feel slow if every interaction requires operational setup. It can also feel unreliable if a query allocates aggressively, materializes too much, or hides planner choices.

LoraDB's first design goal was to make the happy path cheap:

MATCH (u:User)-[:LIKES]->(topic:Topic)
WHERE u.id = $user_id
RETURN topic.name
ORDER BY topic.score DESC
LIMIT 10

That kind of query should not feel like an analytics job. It should feel like ordinary application code.

Why Cypher Still Matters​

If speed were the only goal, the easiest answer would be a custom Rust API with hand-written traversal functions. That would be faster to implement and easier to optimize in the narrow case.

But it would make the customer journey worse.

Cypher gives the database a shared language. A developer can look at a query and understand the shape of the graph. A teammate can review it. A user moving from another graph system does not have to learn an entirely new model before getting value.

The tradeoff is implementation cost. A real query language means parser, semantic analysis, planning, execution, projection, aggregation, paths, functions, errors, and documentation.

I accepted that cost because the goal was not just "fast graph operations." The goal was a database.

Why In-Memory Does Not Mean Toy​

There is a common assumption that in-memory means temporary, toy, or non-serious. I think that assumption comes from confusing deployment model with engineering quality.

An in-memory graph database can still have:

• a real query language;
• a real planner;
• typed values;
• path semantics;
• deterministic tests;
• production use for internal workloads;
• clear boundaries for future persistence.

Starting in memory makes the first version more honest. It forces the core engine to be useful before the system grows persistence, clustering, and managed operations around it.

For LoraDB, that was important. I did not want to hide inefficiency behind hardware. I wanted the engine to be small enough that performance problems had nowhere to hide.

The Product Feeling​

The product feeling I wanted is this:

You clone the repo. You run the server. You send a Cypher query. You get a result. You can read the code path from HTTP request to query plan to graph storage without losing the thread.

That feeling builds trust.

Trust is what turns a curious developer into an adopter. Adoption is what makes a hosted platform possible later. The hosted product can add persistence, backups, scaling, dashboards, auth, and operational guarantees, but the core has to feel right first.

That is why LoraDB begins in memory.

The next post is about the second constraint: storage efficiency. Because a fast in-memory graph database is only useful if it uses memory carefully.

I did not start LoraDB because the world was missing another database with a logo and a query language. I started it because I kept reaching for a graph database in places where the existing choices felt too heavy for the job.

The shape of the problem was clear: I needed a really fast in-memory graph database. Not a graph feature bolted onto a document store. Not a large server that needed its own operational plan before I could answer a product question. Not a database that looked elegant in a demo but became expensive once the working set, query fan-out, and deployment model got real.

I needed something smaller, sharper, and more efficient.

The Workload That Kept Coming Back​

The same workload showed up in different clothes:

• entities connected by typed relationships;
• metadata that mattered at query time;
• short multi-hop traversals;
• ranking, filtering, and projection over neighborhoods;
• state that should be close to the application, not across a slow boundary.

Sometimes the domain was product data. Sometimes it was memory for agents. Sometimes it was internal tooling. The model kept becoming a graph because the real world kept refusing to be a table.

The annoying part was not the graph model. The graph model was the relief. The annoying part was the machinery around it.

I wanted to ask questions like:

MATCH (u:User)-[:WORKED_ON]->(p:Project)-[:USES]->(t:Technology)
WHERE u.id = $user_id
RETURN t.name, count(*) AS weight
ORDER BY weight DESC
LIMIT 20

And I wanted that query to be cheap enough that I did not have to build a cache around the database on day one.

Respect For Existing Systems, Frustration With The Fit​

Neo4j did a lot for the graph database category. It made Cypher feel normal. It made graph queries approachable. It gave developers a mental model that is still useful.

But for the systems I wanted to build, I did not like the efficiency tradeoff. The operational footprint was bigger than the product surface I needed. The runtime model was not shaped around embedding. The storage model was not something I could easily reason about from inside a small application. Other graph databases had their own strengths, but I kept seeing the same tension: great ideas wrapped in systems that were too large, too remote, or too costly for the hot path.

That does not make those systems bad. It means they were solving a broader problem than mine.

My problem was narrower:

Give me a graph database I can understand, run locally, keep in memory, query with a familiar language, and make efficient enough that I trust it in the product loop.

LoraDB started there.

Why In-Memory First​

In-memory is not a shortcut. It is a product decision.

A database that begins in memory can optimize for a different feeling:

• startup should be quick;
• tests should be cheap;
• queries should be predictable;
• the storage layout should be easy to inspect;
• the developer should not need a cluster before they have a prototype.

For the first version of LoraDB, persistence was less important than making the core query engine honest. If the parser, analyzer, planner, executor, and graph store are clean in memory, then durability can be added from a strong base. If the core is slow or unclear, persistence only preserves the wrong shape.

The first principle was speed in the loop. Can you model a graph, load it, run queries, and understand what happened without ceremony?

That is what I wanted as a developer. That is also what I think creates the right customer journey: adopt locally, trust the engine, then choose hosted operations when the product deserves it.

The Customer Journey I Wanted​

Most infrastructure products ask for trust too early.

They ask you to sign up, provision, configure, connect, migrate, monitor, and only then discover whether the data model even fits your problem. For a graph database, that is backwards. Developers need to feel the model first.

The journey should be:

1. Run LoraDB locally.
2. Load a small graph.
3. Write a Cypher query that feels like the problem.
4. See that it is fast enough to stay in the application path.
5. Build something real.
6. Move to managed infrastructure when operations become the expensive part.

That is the company model behind LoraDB: developer-first core, hosted platform later. The database has to earn adoption before the platform can earn revenue.

What I Refused To Hide​

The first versions of LoraDB are intentionally explicit about limitations. It is in-memory. It does not pretend to be a distributed system. It does not hide missing pieces behind enterprise language. It is a graph database engine with a clear query pipeline and a storage model that can be read.

That matters because efficiency is not only a benchmark result. Efficiency is also whether a developer can answer:

• Where did this allocation come from?
• Why did the planner choose this direction?
• How many rows does this operation materialize?
• What does this value look like in storage?
• Can I debug this without becoming an archaeologist?

I started LoraDB because I wanted those answers to be reachable.

The Bet​

The bet is that there is room for a graph database that is smaller, faster to adopt, easier to embed, and honest about the path from open development to a hosted business.

Not every workload needs LoraDB. Some need a mature cluster with years of operational tooling. Some need disk-first durability from the first write. Some need distributed graph processing.

But many teams need a fast graph engine close to the application. Many agent systems need structured memory. Many products need relationship queries before they need a database department.

That is why I started LoraDB.

The next post is about the first technical constraint that shaped everything: the database had to be fast enough to live in memory without becoming wasteful.