About raft-based leader-election, I believe the current recommendation is to look at patroni ( https://github.com/zalando/patroni), which has been built for docker and is now being integrated with Kubernetes; however, I don't think there is an inherent limitation that it couldn't be run on bare-metal.
I quite confident that the postgresql from 5y in future will be quite different in term of storage / server topology support. I won't be surprise pg_bouncer capacity to finally make its way to core when we have a coordinator.
Postgres has steady progression (even if not fast enough for some people) but they are moving without compromising robustness of their product for the users.
Raft is not complex. I doubt leader elect would be terribly hard to implement.
1. Minimize cognitive load by minimizing the number of things you have to learn.
2. Minimize deployment complexity and dependencies.
3. Complexity is just evil I'm general. Linear increases in complexity result in exponential increases in bugs, vulnerabilities, and failure modes. It's just combinatorics.
I understand where you are coming from, but having this kind of multi-server-who-is-master knowledge baked into Postgres itself will surely take another couple of releases, if it will be included at all.
Probably BDR (bi-directional replication, master-master like logical replication) will be there first, but whether the question is whether it will help a lot for local scale-out workloads (as opposed to glueing two datacenters together and allow transactions on both sides).
You really don't understand it? It's less moving pieces to think about, worry about, read about, deploy, maintain, fix and almost always leads to better performance and security.
Something as simple as connection pooling should've already been part of the database and query redirection is even more important to have included.
The unix philosophy of focusing on a single problem and solving it well seems to do just fine. I don't see why baking in featuress that the vast majority of users will never need is a good investment. If anything, it seems like it will only increase the complexity of postgresql. The protocol is well documented and open. Libpq provides all the functionality necessary. Why not bake the higher order logic into a discrete component?
The deployment and upkeep of components is a major hassle and yes, having it all bundled into the same running application (which is the only thing it can be used with anyway) decreases the amount of stuff the end-user has to worry about.
Scaling connections reasonably is something basic any database should handle natively - or better put hitting connection limits without yet another program to help is rather silly in 2017.
You can make the same argument about replication but half this thread is about logical replication being moved to core so we can get scalable distributed clusters in the future - something even fewers users would use but clearly has many benefits by being included in the main release.
That would make it very easy and robust to cluster pg without requiring a big complicated (a.k.a. high admin overhead and failure prone) stack with lots of secondary tools.
This kind of fire and forget cluster is really the killer feature of things like MongoDB and RethinkDB. Yes people with really huge deployments might want something more tunable, but that's only like 1% of the market.
Of course those NoSQL databases also offer eventual and other weaker but more scalable consistency modes, but like highly tuned manual deployment these too are features for the 1% of the market that actually needs that kind of scale.
A fire and forget cluster-able fully consistent SQL database would be nirvana for most of the market.