[inigyou]

If you could conceivably use multiple processes at once to access the database, and not just as an edge case, you need something more than sqlite.

Sqlite does support multi-process access correctly, but the performance is abysmal as it locks the entire file for any write transaction. Client/server databases have much smarter concurrency.

[masklinn]

It’s perfectly fine if your write throughput is low, especially in wal mode. Multiprocess does not actually change much if anything, even in multithreaded mode you want every thread to have its own connection and to have a good handle on who is writing when.

[inigyou]

Regardless, it's a sign sqlite is not right for you. You should start with postgres if you aren't sure your application will always be good with sqlite. It'll save you a migration, and doesn't really cost anything to start your project with postgres instead of sqlite.

[mahcha]

There is an interesting pattern SyncLite (https://github.com/syncliteio/SyncLite) attempts to solve to bring the best of both SQLite and Postgres with one or more SQLite databases directly serving the application while SyncLite replicating/consolidating data from all those SQLite databases into a centralized PostgreSQL database..

[inigyou]

It sounds like a solution trying to sell itself. While you probably can do something like that and it might even be useful for some applications, I can't imagine it's a very good generic solution - you probably want to do it yourself if you want to do it.