Yes and no. SQLite can handle a small number of users. It locks the entire database while writing to it, so it can't support a large number of concurrent users.
I realise you’ve hinted at it, but also think it’s worth explicitly pointing out that it’s more about the number of users writing than just user count. It can handle concurrent readers with little bother.
I am thinking of an application where multiple users can interactive with the workbench BUT the workbench performs its actions against the database as one user. That way, it could consolidate the connections into a single one
Yes and no. SQLite can handle a small number of users. It locks the entire database while writing to it, so it can't support a large number of concurrent users.
I realise you’ve hinted at it, but also think it’s worth explicitly pointing out that it’s more about the number of users writing than just user count. It can handle concurrent readers with little bother.
For those who’ve not seen it already, there’s a good guide on when to use SQLite here: https://sqlite.org/whentouse.html
While the default is indeed to lock the entire database, it has been an option for 15 years to avoid this: https://www.sqlite.org/wal.html
I am thinking of an application where multiple users can interactive with the workbench BUT the workbench performs its actions against the database as one user. That way, it could consolidate the connections into a single one
In other words, a database server around Sqlite? That seems like the kind of thing that should exist!