Tracking down the 16-year-old WAL-reset SQLite bug
- ID
- 13594
- Status
- summarized
- Published
- 12 Aug 2026, 10:22 PM
- Fetched
- 14 Aug 2026, 5:17 PM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://tailscale.com/blog/sqlite-wal-reset-bug
- Source URL
- https://hnrss.org/best
Summary
- Score
- 7.5
- Created
- 14 Aug 2026, 5:18 PM
- Tags
- Audience
- developersdatabase_learnerssaas_founders
What happened
Tailscale experienced 19 separate SQLite database corruption incidents over six months, traced to a 16-year-old WAL-reset bug deep in SQLite. Their architecture uses one SQLite database per shard with a single Go writer, and their backup pipeline snapshots the full DB file to S3 every few minutes—corruption was first detected when a downstream data pipeline reading those S3 backups reported an error.
Why it matters
If you run SQLite in production and take file-level backups or snapshots (especially with WAL mode), you should run PRAGMA integrity_check against your backups routinely—Tailscale's corruption was invisible to the live writer and only surfaced from the backup consumer. Anyone shipping SQLite-backed services should review whether their backup method correctly handles WAL state.
Discussion angle
How do you validate SQLite backup integrity in practice—do you run integrity_check on every snapshot, and what does it cost at Tailscale's scale of snapshotting every few minutes?