Yes it is substantially worse to use multiple connections vs a single connection. This is fairly easy to test in a few lines of code.
We need to remember that opening a connection to SQLite is like opening a file on disk. Creating/destroying file handles requires far more resources and ceremony than taking out a mutex on a file that is never closed.
That doesn't sound right. SQLite's lock for writes is not the best, but it is still pthread mutex under the hood. Are you sure your compilation options for SQLite is right? One common pitfall is compiling without `-DHAVE_USLEEP`. In absence of that flag, SQLite will use sleep in case of conflict, and that will have time resolution of 1 second, causing 1s delay on every lock contention. That flag tells SQLite to use usleep instead, and it is substantially faster on busy timeout.
Here is my SQLite compilation flags: https://github.com/liuliu/dflat/blob/unstable/external/sqlit...
Here is where the flag used: https://github.com/sqlite/sqlite/blob/d46beb06aab941bf165a9d...
I’d assume the DB would be most efficient at handling it’s own. At least to the extend that it wouldn’t garner a 100x speedup to do it in app.