That's not what I said at all. And I think you're really misconstruing my words with the goal of declaring that NoSQL, an extremely large category of databases,

That's not what I said at all. And I think you're really misconstruing my words with the goal of declaring that NoSQL, an extremely large category of databases, is bad, which is a dangerous generalization. I never said anything about difficulity getting NoSQL databases to work, i talked about how they are put to use in problems that don't warrant them as a solution. The problems that I said are as follows: 1. One of the most popular NoSQL databases early on (MongoDB), is imperfect, but a lot of people decided to use it without really reading into what it does and the flaws it as because: 2. people got so hung up on hype for NoSQL that they did not think about what makes it great for certain use cases. Key-value stores offer unrivaled scalability, allowing you to store extreme amounts of data and cluster it efficiently, something that is simply not possible in relational databases. However, they do not offer the relational capabilities of SQL (and i'd say for most apps and services these days the vast majority of data is relational). The nice part about document stores, which are really what got the hype going about NoSQL, is that they offer the extreme scaling potential of key-value stores and offer some relational capabilities. Thus they are great for high volume nested data which will be looked up almost always by it's primary key. People ignored that this was the optimal use case and just used Mongo it when it seemed convenient and cool, which led to problems down the line when the realized they didn't have relational capabilities and they didn't have a schema to keep things organized. I use a key-value store (NoSQL) and a document store (NoSQL) every day as well as a relational store (SQL). You just need to pick the right DB for the situation. No database is a jack of all trades.