> Basically, once you grok AWS, things become more productive
> OTOH, that's not nearly the case with Postgres. I spent a day and a half tuning the version I host, switching to RDS, then switching back because RDS was too slow
These two statements are contradictory.
You would have been better off just renting a dedicated host for your DB and doing the tuning yourself (either in person or getting someone to do it) - because the AWS offering is slower than your own instance, and database is a service thats often ripe for easy optimisation by using a dedicated host/cluster of hosts vs virtualised host(s).
Of course dedicated hardware is faster. It is also very inflexible. You cannot clone your DB box to 10 more instances wishing minutes. You cannot detach and reattach volumes withing minutes. You cannot resize the box to 2x size withing minutes. You cannot move it to a different VLAN within minutes. AWS is not the speediest, but it certainly is flexible.
According to your comments though, you'd have been just as well served with a regular VPS at a regular VPS host - you wouldn't have wasted time to found out RDS is slow, and you wouldn't have issues with slower than usual disk IO on EBS.
My point about physical was just another common optimisation for performance critical DB servers, you could probably get close to bare metal speed with the flexibility of virtualised by using a "single VM on hardware" model that some providers offer now.
> OTOH, that's not nearly the case with Postgres. I spent a day and a half tuning the version I host, switching to RDS, then switching back because RDS was too slow
These two statements are contradictory.
You would have been better off just renting a dedicated host for your DB and doing the tuning yourself (either in person or getting someone to do it) - because the AWS offering is slower than your own instance, and database is a service thats often ripe for easy optimisation by using a dedicated host/cluster of hosts vs virtualised host(s).