this is infra for a single-user app. SQLite is THE replacement for file databases like MSAccess, but the box goes down and your database dies with all your data.
So this fills that gap by giving you a database as a service level of QOL without needing to provision a database as a service backend. Otherwise you're dicking about maintaining a service with all that comes with that (provisioning, updating, etc) when really all you need is a file that is automagically backed up or placed somewhere on the web to avoid the drawbacks of the local file system.
But aren't many single-user apps still multi-platform? For example as an Android application but also as a web app the user might access from his desktop device?
Ye that's fine because same user access wont be concurrent. We're avoiding data corruption or the need to take out an expensive and broad write lock.
Sqlite and msaccess can and have often been used with multiple users. I have experience with the latter in the 2000s with Access on a network share.
it's not the correct solution for multiple users. If you want that then you should be running a database as a service.
> 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.
https://www.sqlite.org/whentouse.html