Deeply buried 16-year-old SQLite bug caused last year's Tailscale outages
- ID
- 13779
- Status
- summarized
- Published
- 13 Aug 2026, 5:29 AM
- Fetched
- 13 Aug 2026, 4:21 PM
- Provider
- The Register
- Category
- technology
- Original URL
- https://www.theregister.com/databases/2026/08/12/deeply-buried-16-year-old-sqlite-bug-caused-last-years-tailscale-outages/5287004
- Source URL
- https://www.theregister.com/headlines.atom
Summary
- Score
- 6.5
- Created
- 13 Aug 2026, 4:22 PM
- Tags
- Audience
- developersdatabase_learners
What happened
A 16-year-old SQLite write-ahead log (WAL) checkpointing bug caused recurring database corruption in Tailscale's tailnet infrastructure starting August 2025, taking six months to diagnose. Tailscale funded SQLite maintainers to build a new virtual file system logging tool to reproduce the issue, which engineer Alex Chan described as resisting all initial debugging attempts including checks on POSIX locks, memory management, and thread safety.
Why it matters
If you ship SQLite as a primary database under continuous backup snapshots, this postmortem is a concrete lesson in how deep storage-layer bugs can masquerade as application-level corruption for months. The debugging methodology—systematically ruling out POSIX lock, memory, and threading theories before isolating checkpointing—is worth studying before you hit a similar wall. The fact that SQLite maintainers themselves had to write new tooling to reproduce it should reset expectations about how 'reliable and well-known' doesn't mean 'bug-free' for critical infrastructure.
Discussion angle
What does it mean for your architecture when the database you chose for reliability has a 16-year-old bug that requires funding upstream maintainers to build new tooling just to reproduce—and how do you set up earlier detection for silent corruption in snapshot-based backup pipelines?