Most software bugs are not patient. They crash, complain, or fling an error message across the room. One SQLite bug preferred choreography. It waited for a checkpoint to finish, another checkpoint to begin, and a separate writer to reset the log. Then one small bookkeeping value could tell the database that fresh work was already safely home when it was not.
The flaw lived in SQLite’s write-ahead logging code from version 3.7.0 in July 2010 until it was fixed in March 2026—about 15 years and eight months, rounded here to 16 years. SQLite describes the race as extraordinarily rare, not as an everyday corruption epidemic. That distinction is important. So is the update.
A bug waiting for a coincidence
SQLite is the tiny database engine hiding inside phones, browsers, desktop apps, appliances, and programs that never announce they contain a database at all. Its WAL mode—short for write-ahead log—lets readers keep reading while a writer appends changes to a separate log. A checkpoint later copies those changes into the main database file. It is a practical arrangement: the writer uses the side door, and housekeeping catches up.
The newly documented flaw did not appear merely because WAL mode was enabled. It needed at least two connections in separate threads or processes, with a writer and checkpoint operating at just the wrong moments. SQLite’s developers say ordinary testing could not reproduce it reliably; they needed a special test-control mechanism to pause the code at the dangerous boundaries. This was less “trip over a cable” and more “three people reach for one light switch between drumbeats.”
The WAL is a side notebook
Imagine the main database as a carefully bound ledger and the WAL as a notebook beside it. New transactions first enter the notebook. A checkpoint copies completed entries into the ledger. Inside a shared WAL-index, a field named nBackfill records how many WAL frames have already been transferred. It occupies four bytes, but it carries a large promise: everything up to this point is safely in the main file.
When every frame has been checkpointed and no reader still needs the old log, a writer may reset the WAL and begin again from the front. Resetting the notebook and updating the “copied through here” marker must happen in the right order under the right locks. The bug lived in the handoff.
Six steps, one very bad handoff
SQLite’s own account reads like a heist plan designed by a committee of clocks. First, one checkpoint finishes. Second, another checkpoint starts. Third, while that second checkpoint is in motion, a different connection resets the WAL and writes fresh content. Fourth, the checkpoint misses the reset and leaves nBackfill describing the old log rather than the new one. Fifth, later transactions make the WAL grow beyond that stale number. Sixth, a later checkpoint trusts the counter and skips fresh frames that were never copied into the main database.
That last step is where a bookkeeping error becomes real corruption. The program does not need to explode. It can continue with a database file missing committed material because the index has confidently stamped it “already handled.” Confidence, as every filing cabinet eventually teaches us, is not the same as correctness.
The lie was only four bytes wide
The most unsettling software failures are often not grand algorithmic disasters. They are stale state: one value survives a transition it was supposed to notice. Here, nBackfill could carry yesterday’s truth into today’s WAL. Its size was ordinary; its authority was not.
This also explains why the flaw could remain hidden for so long. Each individual operation—checkpoint, reset, write, checkpoint again—was normal. The error emerged only from their timing and shared memory bookkeeping. Test each dancer alone and everyone knows the steps. Put them onstage together for one microscopic beat, and the ledger loses a page.
Rare does not mean imaginary
SQLite says it found no reason for an emergency response and estimates that the likelihood of this exact race is no greater than data loss from hardware failures such as an SSD malfunction or a cosmic-ray bit flip. That comparison belongs to SQLite, not to a measured incident count. The project also says the team was unable to produce the failure organically, even in testing, without deliberately controlling execution timing.
None of that turns the bug into folklore. The conditions were understood, the sequence was demonstrated, and the code was fixed. “Rare” describes probability; it does not reverse consequence. If an application uses WAL mode and permits concurrent connections, the sensible response is neither panic nor poetry about cosmic rays. It is dependency inventory, an upgrade, and the usual backup discipline databases deserved before this story arrived.
The fix is pleasantly boring
The vulnerable window runs from SQLite 3.7.0 through 3.51.2. The correction shipped in 3.51.3, with fixes also available in 3.50.7 and 3.44.6; newer releases carry it as well. Applications frequently embed SQLite rather than asking users to install it separately, so the visible app version may not reveal the library version inside. Developers should check the SQLite build their software actually ships.
There is no clever user ritual that improves on patched code. Do not disable journaling at random, rewrite an application around a headline, or assume a database is current because the operating system is current. Find the embedded version, update through the application or dependency chain, run integrity and regression checks appropriate to the product, and keep tested backups. After nearly 16 years of exquisite timing, the remedy is reassuringly dull.