- Author
- Not stated (SQLite project documentation)
- Published
- Last updated 13 April 2026
- Kind
- Official project documentation page
- Original
- www.sqlite.org/howtocorrupt.html
- Subject
- Databases and storage
- Themes
- How things break
What it is
The SQLite project documents how its own database files get damaged. The page aims to list the known ways a database can go corrupt.
What it says
- The page says SQLite resists corruption, but it is not immune.
- Any process can overwrite a database file, and the library cannot defend against that.
- The page warns that raw close() calls outside SQLite cancel other threads' locks.
- Journal and WAL files must stay paired with their database file, or recovery can fail.
- The page says most consumer drives and USB sticks misreport that writes are safely stored.
- Setting PRAGMA synchronous=OFF can corrupt a database after an OS crash or power failure.
- The page lists the WAL-reset race bug, present in versions 3.7.0 through 3.51.2.
What evidence it gives
The page offers no benchmarks. It relies on named incidents, such as a Fossil repository and a Tcl/Tk wiki. It also gives dated bug histories with fix versions.
Interests and limits
The authors are the SQLite maintainers, who have an interest in SQLite's reputation. They say bug-caused corruption is rare. The page does not give rates for any cause. Some entries rest on reports the authors only heard second hand.