kv
the proofThe ordered key-value core, usable directly. A durable, ordered, string-keyed map — the thinnest possible lens.
How LibreDB works: one ordered byte key-value kernel with thin kv/document/relational lenses on top (FoundationDB pattern). The file boundary is the trust boundary, and the write-ahead log is the database.
SELECT layer, role FROM architecture;LibreDB follows the FoundationDB pattern: one small ordered key-value core, with thin model lenses on top.
The ordered key-value core, usable directly. A durable, ordered, string-keyed map — the thinnest possible lens.
Collections of JSON documents under string ids, with by-id CRUD and an in-engine find() predicate.
Schema-validated typed tables with where / select / join — a relational view, deliberately not a SQL engine.
kv document relational ← lenses (open edge)
\ | /
\ | /
+--------+----------+
| one narrow transact() port
============|===================== TRUST BOUNDARY
|
core.ts ← the kernel (guarded)
ordered KV · txns · WAL · recovery
|
FileSystem seam (node:fs, or SimFS for crash tests)core.ts is where data can be corrupted, so every line passes heavy review and deterministic crash tests. It stays small because it is genuinely minimal.
Lenses, query surface, and catalog are open and fast to contribute to — the worst a bug can do is present a bad view; it reaches the store only through one narrow port.
Most databases keep a write-ahead log separate from data files. LibreDB does not: the file you openis the sequence of every committed transaction, replayed into an in-memory sorted array on open. No separate data file, no buffer pool — the same lineage as Redis AOF mode. Two boxes instead of three, which is how the kernel stays small enough to understand.
LibreDB is early (0.0.x). The architecture is in place and every line of the core is tested, but the API may still change and it is not yet meant for production data. Star it, follow along, and help shape it.