Tailscale Detects Bug Hidden in SQLite for 16 Years

Summary

Tailscale identified the root cause of months of intermittent database corruption as a rare data race in SQLite's WAL checkpoint process. Collaborating with the SQLite team to fix this bug, which is estimated to have remained hidden for 16 years, the fix was released in version 3.53.0.

Why it matters

SQLite underpins a vast majority of embedded and application-level databases, meaning this silent data loss error in the checkpoint path has implications far beyond Tailscale's control plane. The incident also highlights the risks of deviating from standard usage patterns (specifically, manual and aggressive checkpoint triggering) in a widely trusted engine. The multi-stage remediation process—retracting version 3.52.0, offering 3.51.3 as a temporary fix, and subsequently releasing 3.53.0—underscores that even mature projects can ship with incomplete patches.

Highlights

• Root cause: A rare race condition between a WAL checkpoint and a concurrent write operation caused committed data to disappear in subsequent reads.
• Tailscale's non-standard practice of manually and aggressively triggering checkpoints made the company a repeated victim of this extremely rare bug.
• A custom VFS layer ('tmstmpvfs') deployed to production finally captured the trace that allowed the SQLite team to detect and resolve the race condition.

Critical take

The 16-year figure is an estimate, and the bug was only triggered by Tailscale's conscious deviation from default checkpoint behavior. Consequently, the practical impact scope for typical SQLite users is likely much narrower than the headline implies. Furthermore, GIGAZINE's report is a direct repetition of Tailscale's own blog post, lacking independent verification or additional technical depth.