I understand what you're saying. It might come down to use-case. The particular application I manage really suffers from low GHz and not having all data in mem

I understand what you're saying. It might come down to use-case. The particular application I manage really suffers from low GHz and not having all data in memory. Ive run the benchmarks on EC2, certain reports that finish in ~5 seconds can take more than a minute on a comparable EC2 instance that costs about 10x as much. This application really needs the raw CPU. and yes we have a pretty large engineering team that has optimized all the queries, índices etc. As far as replication, backups, etc. I set all that up, and honestly it wasn't a big deal. It's a couple short chapters in the Postgres book that explain it all very simply, how to configure, continuously (and automatically) test, etc. I do agree that SANs are a nightmare. Thats why I ship all my WALs (PG backup files) to S3 (and eventually Glacier). That way I don't have to think about losing those files and it's dirt cheap. I think there's a misconception that these kinds of configurations are too complicated for a single engineer to setup, with never ending maintenance required. In reality you can set it all up in less than a week and it only really needs maintenance when you want to upgrade Postgres (some settings may have changed). I'd estimate it takes about 5 hours per year of maintenance.