Also, people, please stop trying to do "automatic failover". There is no such thing, in the total sense. You have to have humans checking to make sure everything ok, and lots and lots of tripwires to prevent one of a multitude of catastrophic problems from occurring. Just automate pieces in totally reliable and non-harmful ways and let a human oversee the cut-over.
We were reluctant to do automatic failover as well, since we all hear horror stories about automatic failover causing more problems than it solves. However, we changed our minds this summer for a couple of reasons. One, our traffic continues to grow and people rely on us for payments. If our database server crashes in the middle of the night, we don't want our customers to have to wait for us to do manual failover. Two, we felt a lot more comfortable with Pacemaker and PostgreSQL streaming replication failover than we used to with DRBD. We did extensive testing and tweaking, and we believe we understand the failure scenarios.
There are many axes on which you can scale and many different interpretations. People have reported that postgres scales very well to many cores and many concurrent users (something like 300K read queries per second or something ridiculous[1]). It also scales nicely for concurrent writes and avoids locking in situations where most other databases don't.
There may be cases where postgres adapted plans (automatically using statistics and the cost-based optimizer, of course) for them as their data grew. Responding to data growth is a kind of scaling -- if using a database without that capability, it may be stuck with a horrible plan that falls over as the data grows.
Scaling to multiple servers is, no doubt, important; but it's not the only important definition of "scaling" (if it were, then multi-core would just be a fad). Lots of technologies scale to many servers beautifully, but lose focus on other aspects of scalability or are just plain inefficient.
[1] http://rhaas.blogspot.com/2012/03/performance-and-scalabilit...