WALAutopsy

Who it's for

Indie/SMB engineering teams (1-20 people) with paying-customer data in production SQLite via Litestream replicas, Turso, PocketBase, or Rails 8 defaults; today they cope with blind faith in replicas plus an occasional manual `PRAGMA integrity_check` on the live DB, which is exactly the setup the Tailscale post showed can silently replicate corruption for months.

The problem

Time and payment: silent WAL-reset corruption is discovered months late, then costs 1-3 engineer-weeks of hand-inspecting pages with no answer to the only question that matters — which backup is the last clean one — and if the poisoned rows were orders or subscriptions, that's direct revenue loss plus refund/support debt.

How to build it

CLI + GitHub Action + small hosted dashboard. Inputs: local DB+WAL files, a Litestream replica URL (S3/R2/GCS), or a Turso snapshot. Outputs: markdown/PDF autopsy report naming corrupt pages/tables and the detected corruption signature, an earliest-clean-generation pointer, and Slack/email alerts when a previously-clean chain turns corrupt.

How it makes money

Panic-driven one-time autopsies at ~$99 (data-recovery pricing is proven), and teams with paying-customer data in SQLite pay $29/mo for continuous per-generation verification, because the free option (PRAGMA integrity_check) only checks the live DB, can't attribute corruption to a snapshot generation, and nobody on a 2-person team wants to learn WAL frame headers to build it themselves.

Why it doesn't exist yet

Incumbents skip it: Turso/cloud vendors won't ship a 'your replicated backups may be poisoned' detector because it implicates their own replication, and SQLite core moves slowly on anything outside the engine itself. The indie gap: Tailscale's 710-point post just published the exact WAL-reset failure signature and their forensic method, so an unaffiliated builder with no reputation to protect can turn that recipe into a scanner and per-generation chain walker in weeks while vendors deliberate.

First users

The HN thread is full of 'we run Litestream in prod' operators who are nervous this week; a Show HN ('we turned Tailscale's forensic steps into a one-command scanner') converts them directly, plus the Rails 8 Solid Queue and PocketBase communities already anxious about single-file durability.

Build size

2 people x 8 weeks. Includes: SQLite page/WAL parser, corruption-signature detector (incl. the WAL-reset frame-misattribution pattern), Litestream generation-chain walker with S3/R2/local connectors, report generator, cron/GitHub Action alerting. Excludes: GUI data repair, MySQL/Postgres support, hosted backup storage.

Biggest risk

SQLite or Litestream ships native per-generation verification (an official integrity mode or checksums-per-generation release) within 6 months, or the bug proves rare enough that the panic fades before a paid habit forms.

Conditions for a hit (all 3 required)

• Given a SQLite database file or Litestream replica URL, produces a report naming the corrupt pages/tables and the specific corruption signature detected (including WAL frame-misattribution), completing in under 10 minutes for a 5GB database
• Walks a Litestream replica chain and outputs the earliest snapshot generation verified clean — a concrete generation number/timestamp the user can restore from
• Ships a scheduled mode (GitHub Action or cron) that re-scans new snapshots and opens a GitHub issue or Slack alert when a previously-clean chain turns corrupt

How it's judged (in 6 months)

GitHub repo matching the shape with >=1,000 stars, or a Show HN with >=300 points or Product Hunt daily top 5 for such a scanner(judgment date 2027-02-13)

AI self-confidence 50/100 — self-reported likelihood of meeting the criterion, not a business success rate