While the first and third are legitimate the second point regarding Digg isn't so clear.
The Digg example could have used MySQL without modification had they added the correct indexes. And if they didn't want to do that, they could have heavily cached queries in Memcache (or something) and performed the join on the fly. And before get flamed for speculating, I know this because I was responsible for the same feature on another Top 100 site of similar scale.
Getting performance out of MySQL might not be as simple as it is in a key/value store, but scalability isn't a new issue, and MySQL is decent at doing it efficiently (although in a way only DBAs would know/understand). It could have saved Digg 3TB of disks to maintain.
While I know very little about MySQL, I was surprised by that example too. How a relational join could be slower than that couple of query's? Moreover, at first glance, why didn't do exactly the same with a subselect(MySQL supports them now, right)? The second query seems to me a performance killer (dynamic by nature, has to be parsed every time).
I checked the link to the digg case myself, and then I found this:
Computing the intersection with a JOIN is much too slow in MySQL, so we have to do it in PHP.
If they claim that doing any heavy computation is faster in PHP than in MySQL they are obviously 100% incompetent at dealing with databases. And I say that as someone generally laughing at MySQL compared to other database-engines. They actually prove this in their explanation:
Query Friends for all my friends. With a cold cache, this takes around 1.5 seconds to complete.
With proper indexes this should take 100ms at most.
Not saying that non-relational databases don't have uses, but every single case I've seen the specifics of where a NoSQL solution is proposed as a better alternative with regard to performance and scalability has so far been rooted in incompetence. Make of that what you like.
The Digg example could have used MySQL without modification had they added the correct indexes. And if they didn't want to do that, they could have heavily cached queries in Memcache (or something) and performed the join on the fly. And before get flamed for speculating, I know this because I was responsible for the same feature on another Top 100 site of similar scale.
Getting performance out of MySQL might not be as simple as it is in a key/value store, but scalability isn't a new issue, and MySQL is decent at doing it efficiently (although in a way only DBAs would know/understand). It could have saved Digg 3TB of disks to maintain.