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.