[throwaway342526]

Agreed - replication is the key. There are two key perspectives on what architectural purpose a database serves:

1) As a relational query engine first and foremost. Postgres wins handily here, leaving people wondering "why use Mysql."

2) As a reliable replicated datastore, which perhaps happens to be queried via SQL or some rough approximation thereof.

One item you didn't mention is how the replication chain behaves in the event of a node failure. With Postgres, yes, you can promote a slave to master, but last I checked (~2 years ago) promoting a slave to master would break replication to all other slaves, causing a complete loss of redundancy in your entire cluster. I believe this may have been addressed recently; I know folks were working on it.

Going back slightly further in history, Postgres has always lagged far behind Mysql in terms of replication tools and ability. What Postgres has going for it is a far, far superior SQL environment. Which is fantastic; I absolutely prefer it as a developer. But it can be a complete non-starter operationally and architecturally.

[ntqz]

With regards to replication and remastering - that was fixed in 9.3 - https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_...

[paulryanrogers]

True, but built-in replication is still the whole installation or nothing. I believe Slony doesn't have this limitation; though, being trigger-based has some other quirks of it's own. Pgpool is another solution I've also used for a while. All have quirks which I don't recall running into with Mysql's replication.