I wouldn't expect much difference in performance. "The on-disk format for the table data is the same."

I would expect the additional checks on writes to be negligible in most cases (dwarfed by other bookkeeping and I/O). I imagine that strict mode could enable some optimizations for read queries, but I can't see those being huge wins.

> but I can't see those being huge wins.

I agree from an algorithmic perspective but in the real world, it really depends. The size of a non-text/binary cell within a column is now fixed, meaning guaranteed to never need to resize/reallocate when streaming results. That could translate to non-negligible improvements (multiple percentage point speed up) if it’s implemented separately from the existing code path.

> The size of a non-text/binary cell within a column is now fixed

I think this is not true since the on-disk format didn't change, ie, ints are still variable-size whether strict or not.

The format/spec doesn’t change, the implementation does. “This field can be variably sized” vs “but in practice since this is a strict table it will always be exactly n bytes”

It’s really no more than an additional (hyper optimized) check constraint on the type; with branch prediction it’s probably ~free.

The SQLite dev's internal performance testing using cachegrind shows that STRICT mode uses about 0.34% more CPU cycles. So STRICT is slightly slower, but not enough that you could measure the difference reliably in a real-world system.