4 posts tagged with "Operations"

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

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.

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).