the developers "do one thing and do it well"

it's better to have a flexible 'correct' implementation of a DB instead of baking in features which make it more complex and less extensible.

Postgres' motto is "do it right, or don't do it at all". The developers rather let other projects (or postgres addons) figure out the all the hidden traps and then implement a better-than-average solution on the first try a few years later.

Cf. their JSON support, which regularly outperforms dedicated NoSQL databases; they're also slowly integrating building blocks for multi-master replication, while still holding out on actually implementing it – seeing MariaDB's recent track record with their solution ( https://aphyr.com/posts/328-call-me-maybe-percona-xtradb-clu... ), probably a good decision.

PostgreSQL only adds clean, well thought-out, maintainable, and fully reliable implementations of features to their codebase. In stark contrast to many other open source database products, when PostgreSQL adds something, barring often one or two bugs found in the .0 release, you can trust it works now and will continue working pretty much forever. I appreciate this approach, and it is why I have been using PostgreSQL now for almost fifteen years. This particular feature is something that is difficult to make correct (see Jepson complaining about essentially everyone) as well as difficult to come up with a model that supports more than a few narrow use cases. If you need something now it is better than people are being directed to third-party products that can be built on the solid core of PostgreSQL, and which then will have clear expectations associated with them.

To discourage people from using something broken. You're talking about a database that waited until 2011 to add a SERIALIZABLE implementation because the existing solutions all sucked, and only did it then because of new research (SSI). They have zero qualms about keeping features out of the database, no matter how useful, if they can't be implemented well.

repmgr and other projects listed here were considered and heavily tested initially. While each of them are great projects, we needed a solution that was fully automated in both cluster configuration/initialization as well as cluster recovery and migration. Many of these projects were inspirational in the design of yoke. You can read our vision for an "automated, API-driven infrastructure" (http://nanopack.io) for further clarification on why yoke was needed.