Setting up multi-master replication with automatic failover was easy with MySQL a very very long time ago. Yes, there were foot guns (MySQL let you do some extremely stupid things). Yes, you really had to have a decent grasp of how things worked under the hood to not lose transactions, and your metrics / logs / alerts story had to be good, and your ops staff needed to know what they were doing during an incident. But that's always the case when self-hosting databases. We looked at Postgres several times over a 5 that period, and it always felt seriously lacking to me as an operator (not a real DBA or developer).

Galera kinda improved the MYSQL replication story for certain specific use cases, at the expense of (a lot of) extra complexity and way more foot-guns. I couldn't recommend galera even when the use case matches up. It took us years to get it operating relatively safely, and that was after a heap of near-misses with customer data. (Yeah, a bunch of us thought it was folly to use it but we weren't decision makers at the time)

> Postgres also had a reputation for being correct but slower

Even back then, I found that mysql was faster for “select * from table where primary_key = 42”, but with even the slightest complication (joins, functional queries, subqueries), postgres pulled ahead.

I guess a huge percentage of SQL queries are really just key-value lookups though, so I can’t blame people for using mysql too much (this was before memcached, let alone redis et al)

Isn't postgres replication still an issue? I didn't think there was a single solid solution yet.