but this is bleeding edge stuff ( never mind that it will work perfectly given past experience).
What did hackers (not whole development + ops) teams do before 9.3.2 ?
with all due respect, is this the reason why startups still default to mysql over postgres ?
Postgres historically has been tricky to configure with 'proper' replication. This is partially because replication is not a remotely simple problem to fix as it appears. The reason people still default to mysql is simply because it occupies more mindshare and is marginally easier to set up. I still don't think it even allows such things as DDL rollbacks so it's hard to talk about it next to Postgres when you're talking about safety.
People did custom scripting or used third party tools for easy failover before 9.2/9.3. What PostgreSQL has improved the last years is simplicity of setting up replication and speed of failover.
> with all due respect, is this the reason why startups still default to mysql over postgres ?
I do not these particular issues. But if we go back before streaming replication (when people had to transfer WAL files with rsync) then I am pretty sure this was part of the reason for why small companies chose MySQL over PostgreSQL:
What did hackers (not whole development + ops) teams do before 9.3.2 ? with all due respect, is this the reason why startups still default to mysql over postgres ?