Wow, lots of good questions coming out of this :-)

1. I chose Postgres because I have the need to remotely manage as well as pull metrics into grafana and metabase. That is simply not possible with SQLite.

I realize this post should be a series of posts where I go deep on all parts of the SimpleCTO stack, so to speak.

2. My monitoring is quite limited because. Generally I use netdata to get a quick overview on health, and I export that into grafana. I rely on Hetzner for actual healthcheck and uptime monitoring. Sentry tells me if my code starts throwing too many exceptions or errors.

I love SQLite, but it really doesn't have a great answer to HA/failover. If you enable WAL mode, even NFS is off the table.

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.

Not the author but for monitoring I just pay for datadog now. It’s expensive but requires almost zero effort to support.