Articles like this should have, in the opening paragraphs, a statement like, &quot;This is for the general case, there are many outliers.&quot; For instance, not all non-relational databases are NoSQL. What about hierarchical databases (LDAP)?<p>The other thing this article totally fails to address: Why NoSQL was so problematic early on. How Mongo by default would let errors fail silent in Java and other drivers.<p>She doesn&#x27;t address the huge limitation in many NoSQL solutions: consistency. She briefly mentions ACID, but neglects the primary use case for document based NoSQL: if your data doesn&#x27;t need to be current on ever read. So a blog is a great example, or any type of social network really. It really doesn&#x27;t matter if you&#x27;re reading a version of the comment thread from 20 seconds ago or 5 seconds ago (as long as it&#x27;s not like 2 minutes ago).<p>The author also classifies all NoSQL as document stores, when they&#x27;re not. Mongo uses a document model&#x2F;concept, but others may use a model that&#x27;s more like a distributed memcache or key&#x2F;value store. There are things like Apache Geode which uses a distributed object store with client based schema versioning. The data model space is pretty big and they&#x27;re pretty different fundamentally.<p>The author mentions how a lot of solutions use both, but in other posts I&#x27;ve looked at and other companies I&#x27;ve worked for, I&#x27;ve found that you often have to <i>require</i> both. In a lot of implementations, people use both a NoSQL and a relational store; one more as a fast read cache and the other for long term persistence. Then you get into all the issues with insuring consistency between the two and it&#x27;s a miss.<p>Overall, this is a pretty basic article and not one I&#x27;d recommend. It can lead to the wrong decision for a project.