Tailscale spent months chasing database corruption before tracing it to a data race that had lived inside SQLite since 2010. The fix was straightforward. The lessons are not.
Late last year, Tailscale's uptime started to wobble. Outages hit their control plane, the service that coordinates every device on a Tailscale network. The instability stretched into early 2026, and the culprit turned out to be something nobody expected: a bug buried deep in SQLite's Write-Ahead Logging code that had gone undetected for roughly 16 years. Tailscale published a detailed account of the investigation on August 12, describing months of forensic debugging that ultimately surfaced not one but two distinct SQLite bugs.
The story is a case study in how "boring technology" can harbor surprises, and why the trust developers place in battle-tested software deserves periodic scrutiny.
How Tailscale Uses SQLite, and Why It Broke
Tailscale's architecture splits its control plane into internal coordination servers, or shards. Each shard runs a single Go process with exclusive access to its own SQLite database, holding all the information about the tailnets assigned to that shard. As the company describes in its blog post, this single-writer design is "exactly how SQLite is meant to be used."
Tailscale adopted SQLite as its primary database in 2022, choosing it for the reasons most teams do: it's well-known, reliable, and qualifies as what the industry calls "boring technology" — software so mature that you don't expect it to surprise you (Switching from etcd to SQLite: A Database Migration Story). For years, it didn't.
Then corruption started appearing. Databases would silently degrade, producing incorrect query results or outright failures. The symptoms were maddening because they were intermittent and didn't map cleanly onto any known failure mode. Tailscale's account describes months of intense forensics before the team isolated the root cause: a data race in SQLite's WAL-reset logic.
WAL, or Write-Ahead Logging, is the journaling mode most production SQLite deployments use. Instead of writing changes directly to the main database file, SQLite appends them to a separate log. Periodically, those changes get "checkpointed" back into the main file. The bug lived in the transition between these states: a race condition that could corrupt data under specific timing conditions. It had been introduced around 2010 and survived undetected through billions of deployments (How To Corrupt An SQLite Database File).
The investigation also turned up a second, separate bug involving stale expression indexes. In short: one bug (the WAL-reset race) corrupted data through mistimed checkpoint transitions, while the other caused queries to return stale results because cached expression indexes weren't properly invalidated. Two bugs, one investigation, both fixed upstream.
Why This Bug Hid for 16 Years
Sixteen years is a long time for a bug to survive in one of the most widely deployed software libraries on the planet. SQLite ships inside every iPhone, every Android device, every major web browser, and countless embedded systems (How It Works). By some estimates, it's the most deployed database engine in history (About SQLite).
The WAL-reset race condition survived because it required a narrow set of conditions to trigger. Most SQLite users run single-threaded or use the database in read-heavy patterns where the specific timing window never opens. Tailscale's workload, with its particular mix of write patterns and checkpoint behavior across sharded coordination servers, happened to hit the sweet spot.
This is a pattern familiar to anyone who's worked in systems engineering. Bugs in concurrency code can lie dormant for years, surfacing only when a new workload applies pressure in exactly the wrong place. The code isn't wrong in the way a typo is wrong. It's wrong in the way that only manifests under specific interleavings of operations that real-world usage rarely produces — until it does.
SQLite's Expanding Role Makes This Matter More
The timing of this discovery is notable because SQLite's role in production infrastructure has been expanding well beyond its traditional use as an embedded local database.
Tailscale is far from the only company running SQLite as a primary production database. Tools like Litestream enable streaming replication of SQLite to object storage, and projects like LiteFS have pushed SQLite into distributed application architectures. As Obelisk's engineering blog argues in a recent post, SQLite can serve as the foundation for durable workflow execution — replacing the need for a separate database service by keeping workflow state in a local file backed up asynchronously to S3-compatible storage.
This model is attractive: no network hop, no extra control plane, no operational overhead from managing a separate database tier. It's especially appealing for AI agent workflows, where Obelisk notes that a local SQLite file can be used for replay, debugging, and understanding what an agent actually did. But as the Tailscale incident demonstrates, pushing SQLite into roles where data integrity is critical means inheriting the full surface area of its codebase — including bugs that simpler usage patterns never exercised.
The broader trend is clear. SQLite is moving up the stack from "convenient local store" to production database for real services. That shift changes the risk calculus.
The Separate Problem of Phantom Vulnerabilities: Fake SQLite CVEs
While Tailscale wrestled with a real, verified bug, the SQLite ecosystem faced a different kind of threat this summer: fabricated vulnerability reports. JFrog's security research team documented a wave of fabricated vulnerability reports targeting SQLite, published through a newly created GitHub repository. NVD initially flagged these as critical, and CISA's ADP concurred, JFrog found. But when its researchers investigated, the claims fell apart.
One reported vulnerability, CVE-2026-51302, was initially assigned a 10.0 Critical severity score by Red Hat before being downgraded. JFrog found that the function cited in the advisory — exprComputeOperands() — didn't even exist in the SQLite version the report referenced. It was added in mid-2025. The alleged heap use-after-free was impossible by design, since the relevant function (sqlite3ReleaseTempReg()) recycles register indices into an array rather than performing heap deallocation (SQLite source artifact).
JFrog's assessment was blunt: combining all the advisories into a single file triggered AI-generated content warnings. The team concluded these CVEs were likely "LLM slop" — fabricated vulnerability reports generated by language models and submitted at scale.
This creates a compounding problem for developers relying on SQLite. Real bugs like the WAL-reset race are hard enough to find and assess. When the vulnerability database is simultaneously flooded with AI-generated phantom CVEs, security teams waste cycles triaging fiction. The signal-to-noise ratio degrades precisely when trust matters most.
What Developers Should Take Away
The Tailscale WAL-reset saga isn't an argument against using SQLite. It's an argument for understanding what you're signing up for when you adopt any foundational dependency, especially one you're using in ways that push beyond its most common patterns.
Test your actual workload, not the typical one. SQLite's test suite is legendarily comprehensive, but no test suite can cover every possible interleaving of operations under every possible workload (SQLite User Forum). If your usage pattern is unusual — high write concurrency, aggressive checkpointing, sharded deployments — you're exploring territory that may not be well-exercised.
Monitor for corruption, don't just trust. Tailscale's outages were the symptom that eventually led to the root cause. Silent corruption is worse than a crash. Integrity checks, checksums, and application-level validation matter more when your database is a single file rather than a managed service with its own monitoring stack.
Vet your vulnerability reports. As the JFrog investigation shows, not every CVE is real. Automated scanning tools that flag CVEs without human verification can generate false urgency. Cross-reference advisories against the actual source code before escalating.
Watch the WAL. If you're running SQLite in WAL mode in production — and you probably should be — make sure you're running a version that includes the fix for this bug. The upstream patch is available, and Tailscale's confirmation of the fix, detailed in their blog post, states the company is confident the issue is resolved.
As we explored in our coverage of Apple Intelligence's developer tools, the gap between what a platform promises and what it delivers in practice often only becomes visible when you build something real on top of it. SQLite's promise of simplicity and reliability is genuine. But simplicity doesn't mean absence of risk — it means the risk lives in different places than you might expect.
The WAL-reset bug is fixed. The next one is still hiding somewhere, waiting for the right workload to find it.
