Related. Others?

How to Corrupt an SQLite Database File - https://news.ycombinator.com/item?id=41846796 - Oct 2024 (1 comment)

How to Corrupt an SQLite Database File - https://news.ycombinator.com/item?id=33503555 - Nov 2022 (1 comment)

How to Corrupt an SQLite Database File - https://news.ycombinator.com/item?id=31214131 - April 2022 (139 comments)

How to Corrupt an SQLite Database File - https://news.ycombinator.com/item?id=16579986 - March 2018 (10 comments)

How to Corrupt an SQLite Database File - https://news.ycombinator.com/item?id=6502229 - Oct 2013 (63 comments)

> Multiple copies of SQLite linked into the same application

I had recent SQLite corruption, and I suspect it was this - I was accessing an SQLite database from the same python process using both the builtin sqlite3 package, and also the third party apsw library

> One example of this occurred circa 2013-08-30 on the canonical repository for the Fossil DVCS. In that event, file descriptor 2 (standard error) was being erroneously closed (by stunnel, we suspect) prior to sqlite3_open_v2() so that the file descriptor used for the repository database file was 2. Later, an application bug caused an assert() statement to emit an error message by invoking write(2,...). But since file descriptor 2 was now connected to a database file, the error message overwrote part of the database.

Kind of crazy that this is an issue in modern operating systems. There are just so many ways to avoid this obvious footgun of an API design. stdin/out/err should be reserved file descriptors. In fact, why reuse file descriptors at all? Just count up.

Interesting that it doesn't specifically call out Anti-Virus scanning (which does occasionally result in at least one of these scenarios). I've seen many SQLite database become corrupted and the best you can do is have a backup.

I've never corrupted an SQLite database _file_, but an FTS5 index is remarkably easy to mess up if you don't read and understand the docs to the letter and which parts of them apply to your exact use case. When you do a thing wrong with FTS5, you either get a generic ambiguous error, or silent corruption of the index. It's not a black-box extension to you can just enable with no understanding of how it works under the hood, I learned that the hard way.

To make the corruption more efficient, store the file on a RAID.

I just finished building an open-source project using SQLite, and this makes me a little nervous. Is SQLite generally considered a reliable system? I've only had one experience with the DB becoming corrupted and that was because I used the Task Manager to force kill the process while it was running under a heavy load, and I felt that was understandable.

Interesting title for official SQLite documentation :)

The whole sqlite documentation is full of gold gems and other curious documents mostly to appease bureocrats and big companies. It doubles as a fun read other than being incredibly useful.

See, for example: "Defense about the dark arts" (https://sqlite.org/security.Html) and "Why in C?" saying "Because C is best."

Title's "security.Html" not "security.html" — caps html actually 404s for me, lowercase works. Small thing but funny given whole page mocks bureaucratic pedantry. Still, "why in C" doc is genuinely great, richardhipp doesn't hedge at all.

It’s impressive. To admit fallibility is to be honest. It represents confidence.

Oracle used to bury this stuff in support docs you needed a login for. Sybase too. D. Richard Hipp just puts it on the public site with a straight face. Not confidence exactly, more like he's been burned by every one of these bugs personally and wants you warned.

Honest, sure, but has anyone checked whether this page actually changes behavior? Docs admitting failure modes is nice, but I'd want to know if it changes how many people bother with WAL mode or fsync settings, or if it's just read for entertainment.

So is the official pronunciation of SQLite spelling out the letters then? I’d expect “a” not “an”…

I had so much trouble doing this took ages to find a way to do it and it wasn't even foolproof (for engineering self repair procedures). Still can't understand how it's happening in prod.

Article date is Jan 2022. This changes when SQLite runs as WASM in a browser — a context that only became properly viable with OPFS synchronous access handles in mid-2022.

The January 6, 2022 date at the bottom of the page is not the date the page was last updated. It is the date problem 8.9 (Boundary value error in the secondary journals used by nested transactions) directly above it was fixed. The date at the very bottom of the screen in the middle says the page itself was last updated on 2026-04-13.

Before OPFS sync access handles, every write went through async postMessage round trips to the main thread, so a real WASM SQLite DB in-browser was unusably slow for anything beyond toy demos. With sync handles you get near-native file I/O in a worker, which is why projects like wa-sqlite and absurd-sql only became production-viable after mid-2022.

What changes?

Most "mystery corruption" reports I've seen trace back to app code violating SQLite's threading or locking assumptions, not the exotic hardware/VFS scenarios this doc dwells on. The list reads like it's letting careless integrators off the hook.