Tools don't always need to evolve though. I don't want my hammer to evolve into a screwdriver too, or vice-versa.

Having separate tools for separate things makes sense when the things are different enough.

its a file on disk, it relies on the file handling of the OS and an OS file system doesn't give you the same guarantees as a fully fledged db. Even if you try to fix this problem you're just going to end up with trade offs which to properly mitigate you'll end up approaching running some sort of service anyway. At some point you have to ask yourself if jumping through all these hoops has saved you more effort than just running a proper service.

You can justify it as a migration strategy between a file and a service but you're just hammering in screws if you try to force Sqlite to be a multi-client database.

> If there are many client programs sending SQL to the same database over a network, then use a client/server database engine instead of SQLite[1].

[1] https://www.sqlite.org/whentouse.html