If you can switch from one to the other and back again, how are they not solving the same problems?
Let's bring up the age-old vehicle analogy. Any vehicle fundamentally solves the the same problem but that's naïve outlook that doesn't acknowledge any specific use-cases. I can drive a truck down the street to get a Coke or ride my bicycle across Canada but that doesn't mean bicycles and trucks are meant to solve the same problem. The differences are obvious when you need to move a pallet of Coke (or 50).
If you have pallet of Coke to move, a bike and no driving licence that you don't care what the bike was meant for.
If you have to hammer a nail but you only have pilers in your close vicinity you hammer it with pilers and don't care what inventors of pilers meant them for.
I'm not trying to draw any parallels to RDBMS vs NoSQL just pointing out that what often matters in real life is what problems are solved with which tools and why. What the tools were meant for is pie in the sky.
It's not the physical world and we basically always have whichever tool we need available to us. I mainly use open source software so that may not be true for everyone I suppose. That's their choice though.
I can store JSON in a MySQL column and you'd say I'm using the wrong tool. But I decided to define a schema instead, then I'm using the right tool? It's pretty arbitrary. Some requirements do lean one way or the other but most of the time there's not much of a difference.
The areas where clearly an RDBMS is the correct solution or where NoSQL is clearly the correct solution aren't an issue. I think there are huge areas that do overlap. NoSQL is being advocated in far more situations than just where it's clearly the correct solution.
Yes they both store "data", but there are types of data that one is well suited to deal with, and alternative types of data that the other one is better for. On my team we've already split out data into two sets, one that lives in ACID RDBMS and one that lives in NoSQL.
If you are dead set in using one solution for everything, my pity for you.
First these addresses didn't have a zipcode field, but now they do. What about relationships between records, isn't there going to be redundant data? What if the user changes their email in the account record, do I have to manually update their contact record? This is what foreign keys are for. OMG, Where am I ... Where's the exit? We're all gonna die!
That's basically what I go through every time I think about it. It's a big scary fully loaded gnarly nested hash table aimed directly at my foot.
I'd love to see the technical details of how Digg used MySQL, why it was slow and why NoSQL is better, how they use it. The more of this I see and the less real information the more I think they didn't know what they were doing in the first place.
Maybe his numbers are off and his technique is wrong, but this article isn't making a one-sized-fits-all mistake.
It's pretty clear that this guy things Digg is a bunch of idiot engineers - I mean, why else allude to "rudimentary comp. sci. knowledge"?
These articles might have a central point, but when it's surrounded by a bunch of opinion, it like watching TV news (e.g., Fox News). The real information gets drowned out.
Digg's description of their entire setup seems a bit unusual -- from how they've defined their tables to their query methods. It seems at least somewhat likely that they were not making optimal use of their technology.
I'd be curious what the traffic/content difference between Digg and Stackoverflow is. Stackoverflow uses an architecture very similar to what Forbes proposes here and they have plenty of capacity on rather unremarkable hardware.
http://www.alexa.com/siteinfo/stackoverflow.com#trafficstats
Edit: To expand I'd imagine SO serves a lot of static "how do I" google hits for logged-out users which is about as easy to serve as it gets. Digg puts a higher emphasis on the logged in experience and commenting which reduces the ability to cache.