The mysql replication story was the big thing for me in the early/mid 2000s. Back then postgres replication seemed like every option was a brittle/incomplete 3rd party hack with different sets of tradeoffs.
Postgres also had a reputation for being correct but slower. The perf differential disappeared a) as postgres got faster and b) mysql got more reliable/robust.
> 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)
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. The perf differential disappeared a) as postgres got faster and b) mysql got more reliable/robust.