Not very unusual I would say, that patterns I am seeing are most transactions being read/write or pure write, while pure reads are one offs. This is in part due to web frameworks auto-wrapping writes in transactions and not doing the same for reads. I understand the effect on concurrency, but what concerns me more is bubbling up the locked database errors to the client code and letting it deal with exceptions not related to the business logic. Trying to solve by running after queries and trying to convert begin to being immediate is not optimal and error prone. But regardless of my use case, I believe that controlling the default behavior is something desirable on its own, not all use cases are born equal and this particular aspect of the SQLite library is a very important lever when one is balancing concurrency vs simplicity. And let me throw that in for good measure: make sure the begin_concurrent branch supports adding "concurrent" as a default transaction option. Something I myself will also benefit from in a different context, so as others might do.