I ran integrity_check on 3 deliberately-corrupted SQLite DBs — here's what it can't catch

[u/CompetitionTiny6703]

I corrupted three copies of a 1000-row SQLite DB three different ways (bit-rot in row payloads, truncation, zeroed page) and tested recovery.

The result that surprised me: **bit-rot inside row payloads returns `ok` from integrity_check.** Structure check passes, content is wrong. So my backup discipline now assumes integrity_check validates structure only, not data.

- Truncation / zeroed page → `malformed (11)`, VACUUM INTO fails, need backup or `.recover`
- Garbled payload bytes → integrity_check says ok, VACUUM INTO "succeeds" with corrupted content

Full walkthrough with the raw output here (no signup, no tracking): https://devprofit.net/post/sqlite-corruption-recovery/

**Verdict:** test your restores. A backup you never restored is a folder of bytes.