I am interested in this topic as well, although sqlite explicitly says that it is not meant for client-server configuration.
I still want to see if it is feasible and someone is using it in production.
What they mean by that comment is that it doesn't have users in the sense that mysql, SQL Server, etc have.
https://www.sqlite.org/whentouse.html
The documentations says that it works well for websites. For client server, you just need to make an API that handles the interactions with the database.
I got thrown into a legacy web project that used sqlite as the database. It was a small internal-only app, I guess the original developer(s) figured it was so small that sqlite would be plenty and it would reduce the environment complexity.
Unsurprisingly they were wrong. It was small, but sqlite couldn't handle multiple users. I believe this was before sqlite had WAL support, so reading would lock the DB. The 'solution' was to split the sqlite database into many smaller DBs that would allow users to use the site at the same time as long as they were in different areas. This greatly added to the complexity of the application. Some reports would need to access multiple databases to get what it needed, so it would still lock out people. Complexity was much higher then having all the data in a single postgresql/mysql database. All the users hated the system and often ran into DB lock issues.
> sqlite explicitly says that it is not meant for client-server configuration
Most applications don't need the level of concurrency that Pg or MySQL provide and they will be just fine with something simple to operate, which is why I wrote https://redisql.com/