I think I can safely claim that (with the right team) I can scale any database to match that rate. The real problem with scaling is that until you hit a limit,

I think I can safely claim that (with the right team) I can scale any database to match that rate. The real problem with scaling is that until you hit a limit, you don't generally know where the limit is ... and at the limit, you need the system to do something reasonable (in this case, I'd say drop read and/or write requests that couldn't be done consistently). I also wonder if you couldn't perform the same feat with only memcached (wink wink). Systems that behave erratically when you hit a limit should be avoided, and I often wonder if people publish articles like this because they themselves are amazed it was possible. For a well-behaved system, there's no need for fanfare as you grow, but when you hit a limit you have to engineer a reasonable solution. As an aside, it's pretty amazing (to some who's first computer had 2K of RAM) how big you can scale an individual server these days. The competition I'd like to see is when another team accomplishes the same feat but with half the memory, or half the number of cores or a result set that's twice as large - and then publishes how they've done it. A little friendly competition might result in some amazing discoveries.