Do you need (or at least benefit from) your database to run in-process? Because that is the only advantage I can see to SQLite over Postgres. Which makes it the better candidate in many places, but not for anything like a server.
Plus, not everything is a public-facing website. It's amazing how little overhead it takes.
exactly. single-node availability is often "good enough." when using sqlite for a simple service, I've cranked things out from first-line-of-code to production in 30 minutes. When the app only gets a hit every minute or so and only from internal traffic, no need for the overhead of a highly available service.
You'll have to shut the app down to back it up. That problem gets worse if you want some kind of a cold standby, since backups should be frequent.
You could replicate it, but that requires running a separate daemon and starts to beg the "why not just have Postgres be the daemon?" question.
Sysadmin tasks start to get very difficult when someone starts with SQLite and expects to get Postgres-like features out of it. I'd rather run Postgres than try to replicate or continually back up SQLite.
This is not the case:
1) SQLite recommends using the official backup API, rather than copying files on disk. The backup API can be used while the app is running.
2) Litestream is the hot new tool on the block. It streams incremental DB changes to a backup stored on S3, for up-to-date point-in-time recovery.
Modern, production-grade, web-scale machines are able to run more than one process, these days.