No, you still have a problem in your database. Running a database smoothly with large datasets is the main performance problem for web applications. As fast as you can get with smart DB architecture, DB calls still take the bulk of the time compared to code running time.
Sorry, but that simply isn't true for plenty of applications, particularly if they happen to be built on relatively slow platforms like PHP, Ruby, Python, etc. That's even before we get to the bulky frameworks built on top of those!
If your data store structure and queries (SQL or otherwise) are designed to perform and scale, you can get in and out very quickly (milliseconds or less), after which you'll spend most of your time turning the data into something useful.
(That's even before we talk about caching so you don't have to talk to the data store at all...)
Facebook didn't write HipHop (and reduce CPU utilisation by 50%) because their database queries were slow!
I think the point is the problem isn't with the database, but with the code not cacheing results. This isn't some new problem. The database shouldn't be the problem because you should be cacheing results.
If you squint, every database problem is a caching problem. The only reason we store the relations in their up-to-date form is that it's too expensive to continually replay the transaction log from the beginning of time.
