Tailscale SQLite bug outages traced to 16-year-old WAL race condition
Tailscale says 19 database-corruption incidents over six months stemmed from a rare SQLite race, disrupting affected control-plane shards.
By Dominic Okoye · Staff Writer
· 3 min read
Tailscale says many of its late-2025 and early-2026 outages were caused by a 16-year-old SQLite defect, closing a six-month investigation into repeated database corruption on parts of its control plane. The company reported 19 corruption incidents over six months and said it has now found, understood and fixed the issue; it did not disclose a customer count or aggregate downtime.
In an August 12 postmortem, Tailscale said the sequence began when a data pipeline detected corruption in an S3 backup in August 2025. The company confirmed the problem with SQLite’s integrity check, but initially found no consistent connection among the affected shard, customer, tailnet feature, time of day or load.
Tailscale attributed the failures to what it calls the SQLite WAL-Reset bug, a rare race condition between a database checkpoint and a write transaction. SQLite’s write-ahead log, or WAL, holds changes before they are incorporated into the main database file. Under a narrow timing condition, Tailscale said, a checkpoint could treat pages as copied even though they had not been written to the primary file. References to those missing pages could still be committed, leaving the database corrupted.
What did the Tailscale SQLite bug outages affect?
Tailscale divides its coordination service into internal shards, with each tailnet assigned to one shard at a time. Each shard’s SQLite database stores tailnet and device configuration metadata and is accessed exclusively by one Go process, according to the company.
When a database was corrupted, Tailscale had to stop the control-plane process for that shard while it repaired or restored the database. Tailnets on that shard temporarily could not use the web admin console or API, and devices coming online could not obtain the peer information needed to make new connections. Existing peer-to-peer connections stayed up, but could not receive network changes while the shard was offline, Tailscale said.
The company said the databases did not hold customers’ private encryption keys or network traffic. In early incidents, it said, a small number of newly added devices or configuration changes failed to persist and some metadata had to be entered again. Most shards and tailnets were never involved in a corruption incident, though Tailscale posted global status notices for the events.
Why did a long-standing SQLite flaw surface at Tailscale?
Tailscale had used SQLite as its primary database since 2022 and had run its backup process without incident since early 2023. Its process took full database snapshots every few minutes and uploaded them to S3. The company said it took manual control of checkpointing to support frequent, consistent backups, an operating pattern outside SQLite’s usual path.
Because the incidents arrived irregularly and could not be recreated in a test environment, Tailscale said it deployed passive production telemetry and hired SQLite developers through a professional support contract. The Register reported that SQLite maintainers believe the flaw dates to SQLite 3.7.0, released in July 2010, and recommend users update to a fixed release, though neither report supplied a version number.
The episode is narrower than a general warning about SQLite deployments. The reported trigger required WAL mode, multiple connections to the same database file and a particular checkpoint-write overlap. Tailscale’s account places its frequent manual checkpointing at the center of why that rare condition became an operational problem.
This story draws on original reporting from The Register.
