If ZK caused a lot of grief then you must be doing something horribly wrong with me.
From my experience ZK is one of the tools that's most ops friendly (i.e. you set it and forget it), right next to Postgres and Solr.
From my experience ZK is one of the tools that's most ops friendly (i.e. you set it and forget it), right next to Postgres and Solr.
Never used Solr, but even as someone who loves Pg over every other RDBMS out there I'd hardly call it "ops friendly", with the Bring-Your-Own-Tooling mentality it turns a lot of operations people off when they realize features like replication, log archiving, etc. require bolt-on tools to actually do anything useful.
ZK is set and forget though, outside of occasional tweaking of JVM parameters based on growth.
We currently have 9.6 with barman for streaming backups and repmgr to control replication. Compared to any of our MySQL setups is a breeze to manage, my team is owning both and the bad thing is that there was only one issue so far[1] on call (bad, because if system doesn't break often no one will learn about it).
PostgreSQL + barman + repmgr is much nicer than anything else we have for MySQL.
Few things: barman offers streaming backup, meaning it is not just once a day, but it is done continuously. On top of that contains a single command that can verify it operates correctly (it has enough backups, streaming operation works etc).
I also like that everything is robust. In MySQL if replication breaks, I need to manually restart it, if it gets too far behind (too many changes, or it is not fixed fast enough) the wal logs will be erased and I would need to set it up from the scratch again[2].
Postgres is smart enough to keep track of all wal logs and only deletes them if all standby nodes received them. If connection is broken (for example a network partition) it will reconnect and resume replication. It self heals whenever it cans. It is a breeze to manage.
Another thing MySQL lost a lot of points for me was at my previous workplace. An MySQL host suddenly started throwing errors to clients. Turns out that few tables got corrupted, the fixing was easy, just shutting down and running repair tool. What was puzzling is that there was no obvious reason (the disk had plenty of free space, no corruption) the machine was not abruptly terminates (~100 days uptime) I never found why data got corrupted. Also, I never experienced things like that with Postgres.
[1] the issue was that barman host had a bad disk, so that triggered an alert and after disk replacement things continued to work.
[2] there is also one crazy system that MySQL allowed to happen. Essentially in master-standby replication someone had genius idea to do some processing on the data in master and write it in standby. Over time that data became also important, so actually the standby node needed to be backed up instead of the master. This is "great" because if replication breaks, whomever is on call will have fun time doing some acrobatics to restore the whole thing. Postgres correctly doesn't allow writes to standby during replication.
MySQL replicas self-recover via MASTER_CONNECT_RETRY and MASTER_RETRY_COUNT. e.g. set to 1, 8640000 respectively to make a replica retry every one second for up to 100 days before finally giving up.
At least this is true for network errors. If replication breaks due to data inconsistency, it should stay broken and a human should look into it, IMHO.
Corrupted tables and repairs suspiciously sound like MyISAM, and a realize this ancient engine still lurks at some places. I haven't done a "repair" for over 14 years -- the last time I used MyISAM in production. Using MyISAM today is analogous to using the ext2 file system today.
In any case this just clarifies a couple comments on MySQL and has nothing to say on MySQL vs. PostgreSQL.
I use them all, as someone who is very familiar with PostgreSQL and Linux systems in general I have no complaints - but unless you know what you're doing it's painful to get all of these set up, they're not intuitive and not integrated in.
This is what I mean by "Bring-Your-Own-Tooling", the core support for replication, wal archiving, etc. is all built-in to PostgreSQL but there's no included tooling to manage it. It's up to you to pick between barman, wal-e, whatever to handle backups. It's up to you to choose between repmgr or pglookout. It's up to you to choose between pgBouncer or pgpool. Batteries not included, and nothing is opinionated, have fun.
I'm not comparing PostgreSQL against MySQL either, I'm comparing it against Oracle or SQL Server - this functionality is baked in and as a result DBA's are a dime a dozen (for the most part), because their job mostly revolves around managing performance and general maintenance instead of wiring a bunch of extra tools together to get it into a production-ready state.
I love PostgreSQL as a developer, and as someone who knows what he's doing I don't mind it from an operations role either - but I don't look forward to the day when we finally fill our open DevOps position and I have to train them on monitoring and managing it.