A bare metal Postgres install needs optimization, and a working backup and restore plan (you did test your backups, right?).
That's half a day of work lost to get your system set up.
Now your app keeps serious data and you want a read replica. How long does that take?
Now you need a separate development environment. Here you go again, adding a few hours of work.
Then you need to update your database version. Gotta read the changelog and make sure you did everything right, and do it in a reaonsable change window.
You just racked up several day's worth of work, and for a DB instance with a similar amount of infra work done, the RDS solution is way cheaper and easier to provision.
If your time is worth money, there's no reason to go bare metal.
Why does my bare metal Postgres install need optimization? My sites mostly doesn't get much traffic, and it runs fine as-is. It'd be silly to try and optimize it without being able to measure what's actually slow.
Backup systems should also be set up according to desired reliability. I have a 10-line bash script that pulls a DB dump, zips it, and sends it to S3. Under 5 minutes to install, including setting up a new AWS role and keypair for it, just have to add in some Ansible commands I already have set up, and set a cron job to run once a day.
Read replicas are nice for some applications, but not needed for any of my current ones. I probably wouldn't want to set one up on bare-metal admittedly, but I'm not worrying about it until I need it.
I don't see a need for a separate cloud deployment for a development environment for my current application either. Would be nice if I had multiple developers and testers working on it, but I don't now.
Never needed to update the DB version, and the traffic is low enough that I don't need to really care about keeping reasonable change windows if I did.
So nope, 10 minutes of work for a low-traffic application. Meanwhile, a AWS RDS setup is easy to start, but then you have to muck with security groups, VPCs, permissions, etc to get it working right. That's not necessarily easy if you don't already make use of that stuff.
If I suddenly get big and my database is Postgres, then I can spin up my own dedicated server, or switch over to RDS after all, optimize concurrent queries, hire a DBA with scaling expertise, etc. Most of that isn't an option with SQLite. I'd have to switch to a completely different database engine. Despite the promises from ORM writers, I've never seen this go smoothly, and it would have to be done at the worst possible time for it.
What, as opposed to needing to read the RDS patch notes, and schedule the maintenance widow?