EDIT: this was meant to be in reply to ct4ul4u.<p>Agree. There are still cases where assembly language is the appropriate choice. That doesn't mean those generalize to "business" use cases.<p>Sure there are cases where a "nosql" approach makes sense. But the examples cited (Google, Digg) bear little similarity to a typical "business" use case, and I'd claim that for "business" applications RDBMS is generally the best solution.
While the first and third are legitimate the second point regarding Digg isn't so clear.<p>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.<p>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.
After some significant work with Google App Engine's data store, I can't help but think that the question "What are use cases for No SQL technologies?" should be turned on its head. Instead, ask yourself "Do I need full SQL database"?<p>For the typical web app, you can't really go wrong selecting MySQL or Postgres. However, you also can't really go wrong to pick something like GAE's data store either. Unless you need sophisticated dynamic reporting capabilities, a key/value store is actually easier to work with than a relational database. A static schema slows you down, but it is a price worth paying if you need to a powerful query language and aren't concerned about scaling.