I agree this is certainly a simplification, but I don't think one grossly so. A lot of the points you mention do not apply to our setup: - Our standby databas

I agree this is certainly a simplification, but I don't think one grossly so. A lot of the points you mention do not apply to our setup: - Our standby database is guaranteed to be consistent (barring some massive hardware failure), because we disable write caching on both the drives and the RAID controller, and the only data being exchanged is the write-ahead log. If the standby receives corrupt data, it will not apply it and will break off the replication and maintain its consistent (and stale) state. The underlying file system of the master and standby are completely distinct, thus any failure on either machine has no effect on the other. - Streaming replication has no effect on write performance on the master, as the replication is best-effort and asynchronous. Of course this is a redundancy trade-off, but one that is fine for our needs. If you need to commit every transaction to multiple machines, that is a whole different and more complicated problem. - Increasing availability was not the main goal for us. If our master database crashes, our website will break. However, our database state should be intact (either on the master or standby), and that was our goal. Having master-master replication or something along those lines is significantly more complicated and invites a host of problems that involve a lot of trade-offs. We accept that in case of master database hardware failure, a human is going to have to fix it. However, we believe with our current system, we can greatly reduce the time it will take.