This is a bug in the affinity behavior, more succinctly demonstrated by the following test script: > ~~~ CREATE TABLE t1(a TEXT, b TEXT); INSERT INTO t1 VALUES(null,10),(0,10),(10,10); CREATE INDEX t1ab ON t1(a,b); .print -------- expect one row -------- SELECT * FROM t1 WHERE b in (SELECT a FROM t1) AND a=0; ~~~ All of the data is text (because of the TEXT types on all columns). So if you change the final comparison from "a=0" to "a='0'" it works. And that is what most applications would do. So this is not a serious bug. But it is still a bug and will be fixed shortly. A [bisects][1] shows that the problem originated with the new "IN-early-out" optimization on the IN operator that is described by [item 3b of the version 3.25.0 change-log][2]. [1]: https://sqlite.org/src/timeline?bid=nbce2ea393ana26b6597e3nc20a353364y9501e22dfen5a38d9281by70d304dcbay5bd99abc10na4663f09c9n320fa69e6aya10662aa91n793e942205n99057383acy83a60ff056ybb87c054b1n09fffbdf9f [2]: https://sqlite.org/releaselog/3_25_0.html