To be fair, I think there are a lot more use cases than that. My last project and my current one both used NoSQL solutions. The former because graph walking is

To be fair, I think there are a lot more use cases than that. My last project and my current one both used NoSQL solutions. The former because graph walking is painful in SQL and the latter because schemaless documents enable so many new scenarios (in my case, the automatic mapping of user-created forms to the backend). For me, the performance ramifications of NoSQL is way overplayed compared to its usability improvements. It is certainly not a successor or replacement to SQL, but for applications that handle a lot of unstructured or semi-structured data, NoSQL makes code tighter, simpler and easier to reason about. Which means less bugs and faster deployments. EDIT: I should qualify this argument by stating that I'm talking about datastores that support custom queries (like MongoDB and CouchDB) rather than ginormous k/v stores (like Tokyo Cabinet). I've found limited usefulness for the latter.