Rindle is an LLM-assisted port of Zero’s query engine from TypeScript to Rust. Zero has been in production for two years, and it was already a database in all but name, with storage, indexes, a query optimizer, and replicas. What it lacked was authority: Zero always follows some other upstream database. Rindle adds that, so it can be the source of truth itself.
Correctness is tested in depth. Rindle runs its own unit and integration suite and Zero’s original one, but the main defense is a single contract: the changes a subscriber receives, applied in order, always equal running the query from scratch. A SQLite-based oracle and a differential fuzzer check that contract across generated queries, and regular runs add deeper fuzz sweeps and TLA+ model checks of the replication protocols.
What’s left: the last sixty seconds of durability
Most of the authority work is built: a write-master with multi-writer transactions and snapshot isolation, a journal that read followers replicate from, fencing so a stale master can’t write, and backup and point-in-time restore to S3.
The main thing that’s left is the last sixty seconds of durability. As a replica, Zero never needed it: it has a single writer, the replication stream, and if it exits before a write is durable, it picks the write up again from the stream on reboot. Rindle’s master has no stream to fall back on. It ships its journal to S3 every 60 seconds, so a machine lost inside that window loses acknowledged writes. A process crash loses nothing, because the writes are on local disk. But a lost machine can, and that is not acceptable for a database.
Fixing this is a well-understood problem with at least two well-known solutions: group-commit the log tail to the object store before acknowledging, like Turso, or hold the tail in a small replicated hot store, like Neon.