The article is from 2012, but its contents is still very true. The only general purpose solution out there is pgpool, but from my own experience, unfortunately, it's less than stable at times and it has its own interesting quirks you have to live with (like having a SQL parser that lags behind PostgreSQL 1-2 releases).
Then there are bugs. Sure: As they are discovered, they get solved quite quickly, but if you are depending on certain functionality, it can still be very annoying.
It's also touted as a HA solution, but from my own experience last year, I greatly increased the overall stability of an installation by getting rid of pgpool - there's too much magic going on in there.
Finally, I was quite unhappy about them silently fixing a case where an unauthenicated client could request all the servers memory to be consumed. No security announcement - not even a release was made.
Unless you are very willing to spend a lot of time working around quirks and deeply familiarizing yourself with the source code, I would recommend against pgpool at this time, which leaves us, again, without any general-purpose load balancing solution. Other solutions have restrictions that make them quite situational (no prepared statements, non-deterministic cleanup after the client disconnects, etc).
I love PostgreSQL but many of the tools for it are nowhere near the same level of quality as PostgreSQL itself. Many of the past start-ups have used MySQL and whilst the base may not be as good the tooling on top makes their replication setups far simpler.
I've given up on using an explicit load balancer (pgpool scales badly and is temperamental as you write). The application itself now handles load balancing, swapping out database connectors depending on whether it requires writes / no-lag reads.
The current replicated PostgreSQL setup I have uses WAL-E for continuous archiving / backup (it recently got support for non-US-East S3 buckets[1]) and repmgr for replication management (hasn't seen a release in a year and the documentation is somewhat sparse). Don't get me wrong, I like and respect both projects, but I have less confidence in and more complications from them than PostgreSQL.
The article is definitely still true. When using Postgres in larger systems it's always a problem when the client asks "well what about redundancy?" — there is no good answer to that, for reasons outlined in the article and the post above.
That's entirely not true. Postgres has built-in replication and you can even do synchronous replication if you want to pay for the latency - you can't have more redundancy than this.
Doing the failover is trivially done using something like keepalived or heartbeat as Postgres has built-in support for quickly promoting a slave to the master.
What we don't have, however is good load balancing. Also, because load balancing is f'ing hard to get right when you are in a master/slave replication configuration because it's really hard to know what queries you can safely send to the slave. After thinking quickly, here are some cases: use of nextval/currval, use of select after insert/update in a transaction, querying unlogged tables, and probably many more.
Then there are bugs. Sure: As they are discovered, they get solved quite quickly, but if you are depending on certain functionality, it can still be very annoying.
It's also touted as a HA solution, but from my own experience last year, I greatly increased the overall stability of an installation by getting rid of pgpool - there's too much magic going on in there.
Finally, I was quite unhappy about them silently fixing a case where an unauthenicated client could request all the servers memory to be consumed. No security announcement - not even a release was made.
Unless you are very willing to spend a lot of time working around quirks and deeply familiarizing yourself with the source code, I would recommend against pgpool at this time, which leaves us, again, without any general-purpose load balancing solution. Other solutions have restrictions that make them quite situational (no prepared statements, non-deterministic cleanup after the client disconnects, etc).