I mean SQLite is living on a single node, what exactly do you do when you have failure, when more than one process need to acces the DB, when you need RBAC etc ...
Depends on the failure. What do you have in mind?
> when more than one process need to acces the DB
Easy, you use `journal_mode` set to `WAL` when you connect to the sqlite database.
> when you need RBAC
If you need RBAC, you aren't going to be using sqlite. In theory you could have your application handle the RBAC part since sqlite is embedded in your application.
Another solution is to leverage unix users and groups and set permissions appropriately for the database file and the application running.
> Easy, you use `journal_mode` set to `WAL` when you connect to the sqlite database.
and set isolation level and check_same_thread and PRAGMA synchronous and then put all queries in retry loops because the DB is maybe locked https://sqlite.org/wal.html#sometimes_queries_return_sqlite_...
I wasted so much time trying to get multiple sqlite queries running at the same time
You were trying to write at the same time right?
If the discussion is around failures for the use case of the article (dashboard for blogs which is read-only), my best guess at 'high availability' would be just to have a separate SQLite DB file on multiple app server nodes and call it done. The author mentions that the DB is updated once per day (probably during the night) by a cron job. Just as easy to then scp a few copies to other app server nodes.
If the discussion is around a 24x7 read-write workload with high business costs for performance, availability, and scalability then it's an entirely different problem.
Same thing you have for failure when your pg instance is running on a single node?