This case is particularly tough with sqlite because there’s never a guarantee that column values will be of any one specific type, which is often leveraged when using sqlite and just putting values of whatever you want in columns. So in SQLite.jl, we were originally much stronger typed, but it kept biting people and it was more frustrating to have queries error than just be slower.
Adding the strict mode should have helped somewhat, but I imagine there’s still room for improvement. The first step to improving things is to have a nice, small, reproducible benchmark we can start from. If you don’t mind opening an issue at the SQLite.jl repo, with some code that builds a table and queries, I can find some time to help look into what we can do. One idea off the top of my head is that we could do better about manually “unrolling” the most common types so we can avoid the dynamic dispatch, even in the non-strict case. This would most likely be in SQLite.getvalue and we’d just include a bit if-elseif-else block to check for the most common types. This sort of approach has worked really well in other data packages. If anyone’s up for giving a PR a shot, I’d be happy to review and help push things forward.