Litelink

Reads span all three tiers and the catalog is a SQLite file rather than a service, so no read on the hot path touches the network. Every other machine reads the archive instead, with any Iceberg engine and nothing from litelink.

It exists because doing this by hand goes wrong the same way every time: one production capture system had 125,884 objects, 62.5% of them under 16 KiB, Parquet files at 2 rows each, a compaction routine nothing ever scheduled, and an in-memory buffer a SIGKILL emptied.

Status: early. All three tiers work, and a log survives losing its machine. Read what it is not and not implemented yet first.

Nothing else is required — no producer, no credentials, no maintainer process, no container. Object storage, WAL replication and cross-machine reads are all opt-in, and each is one call.

Wheels for Linux and macOS on x86-64 and arm64 carry a checksum-verified litestream and the DuckDB extensions litelink loads, so a box with no egress still reads, writes and restores. That costs ~124 MB. Run python -m litelink to check a machine before you rely on it; see docs/RUNTIME.md for anywhere else.

Clone the repo for these; just bootstrap sets up the toolchain.