Project status

bakelite is new — 0.1.0 is the first public release. I've tested the correctness-critical paths hard, but it hasn't got the years-in-production mileage that real trust takes. I should be straight with you too: bakelite started as my own itch. So — should you trust it yet? Here's where it actually stands.

What's solid

I've leaned hard on the correctness-critical paths, and the tests reproduce real failure modes:

• A durability torture harness. A self-checking workload records a ground-truth commit history, then checks that each restore — latest or any point-in-time — reconstructs a gap-free, content-exact committed state, under injected backend faults and process crashes (including a real bakelite daemon killed with SIGKILL mid-write).
• A restore you can check end-to-end. bakelite verify --deep performs a full restore into a temp file and runs PRAGMA integrity_check. Run it on a schedule and a non-zero exit tells you a backup won't restore while there's still time to fix it.
• Cross-backend conformance. One parameterized suite runs the full backend contract against MinIO and LocalStack on every change, and opt-in against real AWS S3, Cloudflare R2, and Backblaze B2 — because "S3-compatible" covers a range of behaviors, and an emulator can pass a contract that a real provider fails.
• Layered integrity on every object (CRC-32C + BLAKE3 object hash + a BLAKE3 lineage chain), so a missing, reordered, or substituted object is caught at restore time rather than applied as if valid.

What to keep in mind

• Pre-1.0. Until 1.0, a minor bump (0.1 → 0.2) may change config or behavior; your backups stay restorable across upgrades, and a version that can't read a replica says so plainly rather than guessing — see Versioning & compatibility.
• Limited production mileage. The novel failure modes a tool only meets at scale (odd S3 latency tails, exotic filesystems, unusual workloads) haven't all been met yet.
• Scope is deliberately focused. SQLite on Unix (Linux, macOS) — backup and point-in-time replication, not a live read-replica you can query. Local disk and S3-compatible storage are the proven paths; GCS, Azure Blob, and SFTP ride the same object-store layer and cross-backend conformance suite but have less production mileage (backends). If you need a queryable hot standby, bakelite isn't the right fit.

How to validate it for yourself

Before you rely on bakelite, check it against your own data and backend. A sensible on-ramp:

1. Run it alongside your current tool for a few weeks rather than cutting over cold — bakelite never touches your live database, so it's safe to run in parallel. The one exception: don't run two WAL-controlling backup tools on the same database at once.
2. Schedule verify --deep daily and alert on the non-zero exit. Of the steps here, it's the one I'd set up first.
3. Do a real restore drill against your own database sizes and backend, and confirm the restored copy is what you expect (PRAGMA integrity_check, row counts, an app smoke test).
4. Watch bakelite status (or the Prometheus /metrics endpoint) so a stalled or backing-off daemon is visible, not silent.

If something is wrong, open an issue — a reproducible report helps a lot while the tool is still young.