A multi-pronged approach that might involve multiple stakeholders just doesn't seem like their way of doing things.
It would randomly die, but that was always either my fault or the applications fault, never pgsql itself.
The lack of master-master seems to be the big thing everyone mentions, but PostgresXL is currently in a usable-in-production state.
Compare to MongoDB, RethinkDB, MS-SQL and others where the tooling for replication comes in the box. Yes, to of the examples are "no-sql" but even the mysql replication is in the box and supported as such.
https://www.postgresql.org/docs/current/static/high-availabi...
I'm not sure what more you can ask from documentation.
Does MySQL document Vitess, Galera, MaxScale, etc...?
Then they wouldn't get to build cool new stuff and write blog posts about how they had to build cool new stuff because OMG UBER SCALE.
It seems to me that Cassandra (C*) may have been a better match to their needs... yes it means more administrative and application tuning, but would definitely scale to meet their needs. RethinkDB would also likely be a better match to what they are wanting to do.
That said, I've been holding out for some time on PostgreSQL's in the box replication story to take root and mature. There are definitely more mature features and solutions to sharding and replication around MySQL, I just tend to find MySQL to be brittle and every time I've ever worked with it, I have at least a half dozen WTF moments... from binary data handling/indexing, foreign key syntax, ANSI out of spec, and others. PostgreSQL has some great features, and once the replication issues settle in, it will become the default choice for a lot of projects in a lot of organizations. Though, mySQL/maria and even MS-SQL are currently better options for many SQL use cases.