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 archive-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.
• 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. The embedded bindings get the smallest ergonomic thing that is useful for local apps: pass a database name plus a directory when you want persistence, omit the directory when you want a fresh in-memory graph.

The Node shape is deliberately simple​

The new Node API is meant to read like the difference between a scratch database and a durable one:

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

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

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. The first slice uses the engine defaults:

• SyncMode::PerCommit
• 8 MiB target segment size

Node does not expose WAL status, checkpoint, truncate, or sync-mode knobs 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

There are also sync modes now:

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 automatic checkpoint loop.
• Node, Python, Go, and Ruby still expose the simple archive-backed open path only; full checkpoint, truncate, status, and sync-mode controls still live on Rust and lora-server.
• WASM stays snapshot-only for now.
• 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, and name plus directory means persistent;
• 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.

v0.3 ships 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? LORASNAP magic, format version, reserved header bits, bincode payload, CRC32 footer.
• 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 go away when a WAL eventually arrives. A checkpoint, by definition, is a snapshot with a WAL LSN attached. The header already reserves the slot. The reader already accepts files where the flag is set. The day the WAL ships, the file format does not change — the LSN field stops being null, and the recovery logic learns to replay from the log past it.

In other words, the snapshot work is not throwaway scaffolding. It is the foundation a future log 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. The snapshot header already reserves the LSN. The mutation event vocabulary already exists in lora-store — MutationRecorder is a no-op observer today, and the MutationEvent enum carries one variant per GraphStorageMut method. That is the vocabulary the log will append to. When it ships, the snapshot file format does not change; the reader keeps loading today's v1 files. A checkpoint becomes "a snapshot with a meaningful walLsn," exactly the shape the reader was written for.

A checkpoint loop. Once the log exists, the engine can fold snapshots and the log together in the background. The operator stops having to time saves themselves. The trigger should be throughput-aware, not wall-clock — saving a graph that has barely changed is wasted I/O.

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 second, not the last save. That is when the WAL lands.
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 byte-oriented 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 the lack of a WAL stop being acceptable for your workload?

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.

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 (LORASNAP magic, format version 1, bincode-serialized payload, CRC32 footer).
• 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.
• Reserved header space for a future WAL/checkpoint hybrid (walLsn / has_wal_lsn); pure snapshots emit it as null today.
• 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 every save and load.

Binding support that actually exists in v0.3:

WebAssembly is byte-oriented by design — WASM has no filesystem, so the caller is responsible for persisting the Uint8Array to IndexedDB, localStorage, fs.writeFileSync, 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 Lan 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 new verb (save_snapshot), one new verse (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. A crash between two saves loses every mutation in the window. If you need zero data loss, you need a WAL; LoraDB does not have one yet.
• Not a checkpoint loop. Nothing schedules saves for you. The host process, an external cron, or the admin HTTP endpoint decides when a save happens.
• 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 reserved for the future WAL/checkpoint hybrid and is always null for today's pure snapshots.

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, so the snapshot API is byte-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.saveSnapshotToBytes();

// 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.loadSnapshotFromBytes(bytes);

The Worker-backed surface (createWorkerDatabase) does not yet plumb snapshots through the worker protocol — for snapshotting from a browser worker today, call saveSnapshotToBytes in-process in the worker and post the bytes back to the main thread yourself. In-process WASM (createDatabase) supports snapshots on both the Node and bundler targets.

Save and load from Go​

import lora "github.com/lora-db/lora/crates/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/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 Even Without A WAL​

A snapshot is not a replacement for continuous durability, but it closes enough of the gap for the workloads LoraDB currently serves:

• 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:

• No WAL / checkpoint loop. The header reserves space for a WAL LSN, but the engine does not yet write one. A future release will turn checkpoints into "snapshots with a meaningful walLsn" — the reader already accepts the flag.
• No automatic persistence. Snapshots are always manual. Nothing runs them on a schedule unless you do.
• 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 the WAL 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 stand out after v0.3:

1. A WAL. The snapshot header already reserves the slot; the missing piece is the append-only log that checkpoints refer to. That unlocks continuous durability, which in turn unblocks multi- minute crash-recovery windows.
2. A checkpoint loop. Once there is a WAL, the engine can fold snapshots and the log together in the background — the operator stops having to decide when to save.
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.

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.

• A new vector(value, dimension, coordinateType) constructor.

• Six supported coordinate types:

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

• Storage as node and relationship properties.

• toIntegerList(v) and toFloatList(v) for converting coordinates back to lists.

• vector_dimension_count(v) and size(v) for introspection.

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

• vector.similarity.euclidean(a, b) — 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/lora-node);
• WebAssembly (crates/lora-wasm);
• Python (crates/lora-python);
• Go (crates/lora-go);
• Ruby (crates/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.cosine(...) 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: vector([0.1, 0.2, 0.3], 3, FLOAT32)
})

The third argument can be a bare identifier (INTEGER, FLOAT32, INT8) or a string literal ('INTEGER', 'SIGNED INTEGER'). Bare identifiers are rewritten to string literals by the analyzer only in this specific argument position, so normal variable resolution is unaffected elsewhere in the query.

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.cosine(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.cosine(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.cosine(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: vector([1, 2, 3], 3, INTEGER)})
MATCH (d:Doc {id: 1}) SET d.embedding = vector([0.1, 0.2], 2, FLOAT32)
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 vector([1,2,3], 3, INTEGER) 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.

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: vector($embedding, 384, FLOAT32)
})
CREATE (e:Entity {name: 'Alice'})
CREATE (d)-[:MENTIONS]->(e)
CREATE (o:Observation {session: 's1', ts: datetime()})
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.cosine(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([...], 384, FLOAT32)})
• as a relationship property: CREATE (a)-[:SIM {score: vector([...], 3, FLOAT32)}]->(b)
• as a Cypher parameter: vector(value, dimension, coordinateType)
• 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.cosine(...) or vector.similarity.euclidean(...), 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, toIntegerList, toFloatList, vector_dimension_count, 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.cosine(...) 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 — no indexes, no ANN, no embedding generation today.

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/lora-node;
• WebAssembly through crates/lora-wasm;
• Python through crates/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 is intentionally honest about what it is not.

LoraDB does 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. 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.

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.

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.

Neo4j and other 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.

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.

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.