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.
