> Your claim is that SQLite, while reading the whole record, only checks the fields which appear in the WHERE clause. That's my claim and (without having looked at the code) that's the behaviour reflected by the "changes" demonstration shown upthread. > UPDATE t SET b = 5 WHERE a = 1; Keeping in mind that that update might have 100 fields which would need to be compared. sqlite has a compile-time limit on the number of columns, [defaulting to 2000][limits]. Though that may seem excessive, software-generated databases with 100+ columns are not unknown. [limits]: https://www.sqlite.org/limits.html > only checks field a for comparing it to 1, and because that is true for one row, it would cause a physical WRITE operation, no matter the fact the value of b is already 5? That's what the current behaviour unambiguously implies (keeping in mind that it might not just be 1 field to compare, but might be 47 of them, 30 of which may contain multi-MB blobs and/or data with custom collations).