I think a lot of the hate for NoSQL comes from 2 places:
1. Imperfect implementations. For example Mongo with it's lack of transactional safety (if that's still an issue, haven't worked with Mongo in a long time). Since then several different ideas and implementations have come forward and if you're looking for NoSQL right now and you have a good use case for it, you will almost certainly find a product that does just what you need.
and 2. People not understanding what NoSQL is good for and when to use it over relational. If you try to use a document store to store heavily relational data you're going to quickly give yourself a headache. The real use case of document stores is that they let you have the immense scalability of key-value stores (due to the nature of key-value stores) while also giving you some nested data and basic relational abilities.
In our stack we use a combination of SQL (Postgres), key-value store (Redis), and document store (DynamoDB), each picked to solve a certain problem and not go out of the bounds of what it's good for.
When you start using a NoSQL solution it can be nice and fit the problem quite well. Then the solution gets bigger, new features appear and new data is stored, but the storage is NoSQL. With the solution getting bigger some business intelligence could be required by marketing or other people in the company. But we all know that NoSQL solutions aren't so good with aggregated queries, but in the rush it is hard to slow down to create a second solution for this kind of queries.
So, yes, you are right when you say "People not understanding what NoSQL is good for and when to use it over relational". But the main problem is that you don't know the complete problem in advance usually.
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.
1. Imperfect implementations. For example Mongo with it's lack of transactional safety (if that's still an issue, haven't worked with Mongo in a long time). Since then several different ideas and implementations have come forward and if you're looking for NoSQL right now and you have a good use case for it, you will almost certainly find a product that does just what you need.
and 2. People not understanding what NoSQL is good for and when to use it over relational. If you try to use a document store to store heavily relational data you're going to quickly give yourself a headache. The real use case of document stores is that they let you have the immense scalability of key-value stores (due to the nature of key-value stores) while also giving you some nested data and basic relational abilities.
In our stack we use a combination of SQL (Postgres), key-value store (Redis), and document store (DynamoDB), each picked to solve a certain problem and not go out of the bounds of what it's good for.