The problem with the article you link to is that the author clearly doesn't really know what he's talking about when he asks where the "bottleneck" is; the fact that someone has more web servers than database servers doesn't mean "the database can't be where the problem is". What's generally meant by "the database is the bottleneck" is the same thing that's been learned by everyone who ever does run-time profiling of a web application.
Consider an application which takes half a second to return a full response. Suppose you sit down and profile it, and find that that half second of processing time breaks down as follows:
- Parsing incoming request: 50ms
- Querying database: 350ms
- Rendering HTML for response: 50ms
- Sending response back out: 50ms
If you saw a breakdown like that, where database queries constitute 70% of the actual running time of the application, you'd rightly conclude that the database is the bottleneck. And that's exactly what most people find when they do profile their applications (and, generally, the database so completely dominates the processing time that the choice of language for the rest of the processing doesn't make any difference anyone will notice).
The number of database servers involved turns out not to matter too much; the famous quote here is that people like the author of the post you've linked are the types who hear that it takes one woman nine months to have a baby, and assume that nine women working together could do it in one month. In database terms: if a given query takes 100ms to execute on a given DB, then adding more DB servers isn't going to make any one of them be able to execute that query any faster. The reason for adding more database servers is to be able to handle more concurrent requests and keep your DB from getting overloaded, not to make isolated requests go any faster.
And from there you go into the usual dance of scaling an application: caching to cut down on the total time spent retrieving data or rendering responses, load-balancing to increase the number of concurrent requests you can serve, sharding and more advanced database-design schemes to keep from bogging down under load, etc., etc.
But, you'll note, none of this has anything whatsoever to do with the programming language in use because, once again, the amount of time spent or saved by other factors grossly outweighs the amount of time gained or lost by a "fast" or a "slow" language (and, of course, there's really no such thing; so much depends on the problem domain and the skill of the programmer that you just can't have a meaningful general comparison).
Anyway, this is getting kind of long and rambling, so I'll just wrap it up with a general guideline: if you see someone arguing that "you should build in Language X because it runs faster", it's a dead giveaway that they don't really know anything about real-world performance or scaling. Because, after all, if it just came down to "write in the fastest language", they'd be recommending that we all use assembly :)