For me it's maintenance. Sysadmin level of effort on a SQLite file is near 0

I think this is true only if you're willing to give up resiliency.

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.

> You'll have to shut the app down to back it up.

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.

Adding to (1), you don't have to code anything to the backup API - the standard "sqlite3" command line has a ".backup" command that does it for you.

But how do you make sure a pool of web servers all have the same consistent view of your database?

Oh yeah, if the app is big enough to have multiple replicas, I'll use postgres over sqlite. Mainly sqlite for me is for little apps/services. I do know people that have a setup for distributed sqlite, but IMHO when you want more than machine talking to the db, postgres is a much better fit.

Yeah it's nice not to have to think too hard about that when you're trying to focus on a product getting shipped.

Plus, not everything is a public-facing website. It's amazing how little overhead it takes.

> not everything is a public-facing website

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.

That's fair, though I've never done any sort of sysadmin on a Postgres server either..

It makes the dev setup trivial, since there is no database server around.

Setting up postgres on the same machine is also trivial.

Modern, production-grade, web-scale machines are able to run more than one process, these days.

Sure, but an embedded database is still simpler than client/server. For many tasks, postgres does not offer any meaningful benefit over sqlite so why add the complexity?

I've never worked on such a project that didn't benefit from postgres, but if I did, I would still use postgres because upgrading from sqlite to postgres, and learning a second SQL dialect, and converting a SQL between dialects sounds like a useless nightmare that costs me nothing to avoid.

I feel it's modern hype on lonely/indie/solo developer creating new thing which changes the world. Not caring on "complex" things till the project reaches 1 request per minute and finally have some data to be lost, is totally fine with this goal/scale.