Engineering journal
Engineering notes, architecture pieces, release notes, and design writing from the LoraDB team.
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.
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."
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.
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.
LoraDB v0.4.0 adds a write-ahead log.
This release note has been updated with the current binding names. The
v0.4.0 release introduced WAL-backed persistence; current builds also
expose explicit raw-WAL helpers (openWalDatabase, open_wal,
OpenWal) and managed commit-count snapshots on the filesystem-backed
bindings.
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.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.
Most databases I have worked with had a write-ahead log before they had a snapshot story. LoraDB went the other way.
This founder note is historical. The WAL has since landed on every
filesystem-backed surface, snapshots now write the columnar LORACOL1
format with compression/encryption support, and WASM uses
saveSnapshot / loadSnapshot instead of the older byte-specific
method names.
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.
LoraDB v0.3 adds manual point-in-time snapshots.
This release note is historical, but the snippets below have been
updated to the current snapshot API. Current releases write the
columnar LORACOL1 database snapshot format, support compression and
encryption options, expose WASM snapshots through saveSnapshot /
loadSnapshot, and can pair snapshots with WAL-backed checkpoints.
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).
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.
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.
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.