Imagine an app that receives an HTTP request every second. One in five of these requests requires making a query that takes 3 seconds to complete. The rest is serviced immediately. You don't want the long request freezing your entire server and preventing the fast requests from being serviced.
We experimented with different async DB approaches, but settled on
synchronous at FriendFeed because generally if our DB queries were
backlogging our requests, our backends couldn't scale to the load
anyway. Things that were slow enough were abstracted to separate
backend services which we fetched asynchronously via the async HTTP
module.
I may open source the async MySQL client I wrote, but I am still
skeptical of the long term value given the code complexity it
introduces.
BretDisclaimer: I wrote an async DB module for Twisted/PostgreSQL and it did not turn out to be all that complex.
Also, Tornado is now introducing some kind of interface to Twisted's event loop, which does have everything ported.
Bret just doesn't seem to want async My-SQL in the main code base.
Personally I would go with async DB, or have DB access in its own thread(s) and async communicate with that.
I figure after the first million users, your embarrassingly parellel app server layer is not your bottleneck, it's getting the database to scale.