This problem should be fixed by [check-in c21bc5a2353e660f][1]. [1]: src:/info/c21bc5a2353e660f The following description of the problem is for the historical record: A WITHOUT ROWID table is implemented using an index-btree with extra columns appended for the table columns that are not part of the PRIMARY KEY. Unlike all other index-btrees, the appended columns are *not* ordered. Therefore, the appended columns (column V2 in the example above) should not be used to help look up the desired row. Only the index-btree that implements a WITHOUT ROWID table works this way - all other index-btrees in SQLite have all columns ordered. But the query planner was not taking this exception into account and would (rarely) try to use the additional columns on a WITHOUT ROWID index-btree to help narrow down the search. You could see this by doing an EXPLAIN QUERY PLAN on the SELECT statement that was malfunctioning. Before the fix, that query plan output contained a line: > SEARCH v0 USING PRIMARY KEY (v1=? AND v2=?) This is incorrect since the V2 column is unordered in the index-btree that implements the WITHOUT ROWID table and so cannot be used as part of a binary search. After the [check-in c21bc5a2353e660f fix][1], the EXPLAIN QUERY PLAN output shows the correct search condition: > SEARCH v0 USING PRIMARY KEY (v1=?)