A lot of databases "suck" because they have to be jacks of all trades, in that they have to be able to do a ton of very general things. That's why a crap-load

A lot of databases "suck" because they have to be jacks of all trades, in that they have to be able to do a ton of very general things. That's why a crap-load of web sites and apps can all use the same database software. You will ALWAYS have much better performance if you write your own "database" that specifically does what it is you need doing, as in the case of Google, etc., that you mention. And don't forget, Google didn't just write their own database, they wrote their own file system, etc., and even designed their own hardware (batteries on board to eliminate large UPS's, etc). But they can afford to spend the money to hire the really smart people to build and maintain that stuff for them, and they have the scaling requirements that justify it. Most other companies either can't justify it, or don't want to... they'd rather rely on the vendor to maintain the DB code, to security testing/updates, etc. Really, I think a lot of the complaints about SQL (especially in the case of these recent articles) come from the fact that it's hard to design and implement a system that works the way they want it to, and there's no tool that just plugs into what they have that does what they need. I see their issues as the exception rather than the rule, and not really applicable to most situations. $0.02