SQL vs. NoSQL Databases: What’s the Difference?

There should be mentions about CAP theorem, and tradeoffs about consistency vs availability. Sometimes you dont care as much about CAP-consistency than availability or scalability.

God, this shit again.

Articles like this should have, in the opening paragraphs, a statement like, "This is for the general case, there are many outliers." For instance, not all non-relational databases are NoSQL. What about hierarchical databases (LDAP)?

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.

She doesn'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'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't matter if you're reading a version of the comment thread from 20 seconds ago or 5 seconds ago (as long as it's not like 2 minutes ago).

The author also classifies all NoSQL as document stores, when they're not. Mongo uses a document model/concept, but others may use a model that's more like a distributed memcache or key/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're pretty different fundamentally.

The author mentions how a lot of solutions use both, but in other posts I've looked at and other companies I've worked for, I've found that you often have to require 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's a miss.

Overall, this is a pretty basic article and not one I'd recommend. It can lead to the wrong decision for a project.

Bah. People keep confusing the syntax with the data model. SQL is simply a notation to express theorems in relational set theory. It's pretty much the only pure-functional, side-effect-free programming language that's actually gone mainstream [0]. If you look carefully at the APIs of the "No SQL" databases, you'll find them introducing relational set theoretic features.

To paraphrase Paul Graham's unbearably smug comment about Lisp: once you add filter, group by, and join, you can no longer claim to have invented a new query language, just another dialect of SQL. Math has this funny habit of remaining true no matter how many mean things people say about it on their blogs.

[0] I mean basic core SQL, not the vendor-specific stuff like PL/SQL.

Another point on rapid development: SQL databases have some amazing libraries and tooling. I've been working a lot with SQLAlchemy in Python lately and have been blown away by it.

> While NoSQL databases may not force you into a schema for your database, you will pay a toll for this mutability in your application layer.

A while ago I read a really good point on this: There's always a schema. NoSQL / "schemaless" databases don't get rid of the schema, they just move it out of the database layer. It's still there, whether in the application or the documentation or just in your head.