> "much more usable "

It always worked well, but there are many newer developments around operations and scaling that finally made it much easier to run. Even now there are some limitations with logical replication and horizontal scaling but the main system can easily be installed and running in a few commands to serve most users just fine.

It should be noted that the rise of Docker containers and K8S has also helped greatly in letting users run all kinds of software with minimal work.

Replication is still a pain.

Indeed. MySQL replication topologies with GTID are super easy to maintain and run. Does Postgres still require "extra" tools like pg_rewind to do a simple operation like turning a former primary server into a new replica?

Some of the MySQL backup/restore stuff is a lot more straightforward (innobackup vs WAL shipping).

GTIDs are relatively new and require some porting work to implement on pre-existing databases. MySQL replication is a massive disaster without them. Like most things in PostgreSQL, there is a bit of extra legwork to get things set up right up front, but when they work, they work.

MySQL replication with binlog_pos was a total crapshoot. The reason innobackupex exists (and anything from Percona, to be honest) is because MySQL's default options were so unworkable. The Postgres equivalent is probably something like barman.

Hyperbole much?

MySQL replication was workable before GTID. GTID simply made things a lot easier. GTID was hard to work into existing DB's at places like Facebook, but it we managed to get things going without a DBA in several multi-TB databases (sans downtime).

GTID is over 4 years old at this point. That's not relatively new in the tech world. Especially with the pace of things like Kubernetes and containers.

There are 3rd party additions to Postgres, too. pg_rewind was written by eBay (?) to address the obvious shortcomings of repointing primaries and replicas.