Right, but in this case that's not a thing anyways since there's only one server.

The main reason for me is that Postgres can be backed up while online, and I can scale up to multiple servers if I suddenly need to. Not so much with SQLite where if a small project suddenly hit the front page of whatever I would suddenly need to get really creative.

I'm not sure how well the architecture described in the article lends itself to horizontal scaling since everything assumes it's on the same machine (I think?). Granted, if you build for horizontal scaling I agree, a client/server database is the way to go.

As for backups, SQLite also supports backups while another process is using the database.

This brings to mind a question: would it be possible to run simply run multiple instances of SQLite on independent hosts that are backed by single shared filesystem, such as AWS's EBS? Of course they'd be blocked on writes but it does seem that SQLite3 supports the read concurrency.