"Twice now I’ve deeply investigated NoSQL for an upcoming project, and twice now I’ve come to the conclusion that it would be a bad decision. Many of the commen

"Twice now I’ve deeply investigated NoSQL for an upcoming project, and twice now I’ve come to the conclusion that it would be a bad decision. Many of the comments I received on that post illustrate one of the big problems with evaluating NoSQL - there are a million niche solutions and the common guidance is “it depends on what you need”. Even if you know what you need, it takes significant research and understanding to know if a particular NoSQL engine is right or wrong for that need. You can’t possibly evaluate them all, there are far too many." I don't understand this approach at all. You want to investigate using a NoSQL solution. Why? You know that you need to do research and evaluation but you give up because there are too many choices? You've heard that you have to compromise on transactions and add application complexity, so you stick with "good old SQL". I'm not sure what this article is advocating. It doesn't explore any "NoSQL" (I hate this term) solution and it doesn't even mention which RDBMS the author is using instead. The analogies and examples given show that the author did not really deeply study anything, and that is supported by the first paragraph.