NoSQL v. SQL is the worst holy war ever.

This seems to be filled with religious contention, as demonstrated at . Both sides are talking past each other, so I want to lay it out flat.

First of all, while NoSQL and RDBMS can sometimes exclude one another, they should not be seen as adversaries. NoSQL is designed to address a certain problem space and RDBMS is designed to address another. Both can be an important part of one infrastructure. So all of the resentment between sides is pointless.

Relational databases scale. NoSQL databases scale. Both are scalable and tunable, depending on the situation. Sometimes an RDBMS will be better for your project (yes, even in performance). Sometimes a NoSQL datastore will be better for your project.

NoSQL datastores like CouchDB and MongoDB are developed by competent developers. They are used by competent developers.

Relational and SQL-bearing databases like SQL Server and PostgreSQL are developed by competent developers. They are used by competent developers.

NoSQL offers a barebones solution for people whose primary concerns are speed and load. RDBMS offer a full-fledged solution for people whose primary concerns are data integrity and interrelatibility.

There might be a place in your organization for both!

There is no need to get haughty about this. Pick the design that works best for your problem set. There is no need for one to eliminate the other. Both are useful.

Good software development is all about good judgement. Anyone can learn syntax rules and throw together something that kind-of-sort-of works, but a good developer will know when to deploy one thing and when to deploy another. Keep your options open and stop the silliness.

NoSQL v. SQL is the worst holy war ever.

18 thoughts on “NoSQL v. SQL is the worst holy war ever.

  1. I agree completely! I am using MySQL, MongoDB and Redis all in one application. MySQL for the traditional roles of a webapp, mongo for logging and redis for analytics and a few misc things. A great example of using redis is keeping track of online users. Veryefficient set operations, so I can just push a userid and a last activity time onto a redis set, and check that against some idle/timeout threshold.

    In any event, all are great solutions by amazing developers. Thanks for breaking from the zealotry that has been floating around!

  2. That’s true, and I don’t really like it. It’s part of the default style here. I will go in and take it out, thanks. : )

    Edit: Should be gone now.

  3. Pingback: NoSQL v. SQL is the worst holy war ever.

  4. Very much in agreement,
    hopefully this holy war is stopped much quicker than some of the age old ones we’ve seen in the past. As far as scalability goes, I think NoSQL camp tends over overplay this. I think one of the bigger advantages in NoSQL is the loose document/key-value model, which really helps speed up development.

  5. There will always be absolutism in the software world, as there is in the larger world – as developers we needs to see them for what they are and stay balanced – the right tool for the job.

  6. Hi

    while I agree totally with your point (as someone that mix Redis, MongoDB, and MySQL) and while zealotry is probably the first thing I dislike in programming, please – “holy war” really means something.

    My point is: there’s no blood here – it’s just the regular and evergoing chatter of new things vs older things that has always been seen in IT (let alone other fields :-).

  7. Agree completely, although I’d only add one element, which is that NoSQL (or, more specifically, non-relational) stores also address the problem of storing data which is a poor match to the relational model, it’s not just speed and load. Other than that, yes, this is a very silly battle.

  8. Thank you for stating the obvious. And you are right: if people are having a problem seeing the obvious, then their judgment is being clouded by irrational considerations.

  9. Pingback: Destillat #10 | - Open Source, Wet-, Web-, Software

  10. > emacs still sucks though

    I’m an emacs user, but that was the funniest comment ever.

  11. I like to use the term “butthurt” to describe the crazies on both sides. Heck, our new real-time data platform at Drawn to Scale could even support SQL…and thanks to Clojure, we could bang out that grammar in a few hours 😉

  12. Pingback: 2010 The Year in Bookmarks @ Hyperextended Metaphor

  13. Holy wars are good. The NoSQL vs SQL debate is necessary to find a good synthesis of the two “technologies” (if you want to call NoSQL a technology. It’s really more of all the non-relational technologies put in a bag).

    SQL has already successfully integrated OLAP. SQL will also successfully integrate column stores (“NewSQL”). It won’t be long and some smart computer scientist will integrate NoSQL features (graphs, unstructured querying) into SQL. Hierarchical querying is already available (using a not-so-intuitive syntax)

    And curly braces should totally be put on the same line!

  14. SQL databases can not scale like some nosql databases. Try to spread a SQL database over a network, or even the internet without a complex and buggy master/slave setup. Good luck with that.

    There are plenty of nosql databases that are ACID compliant as well.

    I prefer graph databases because they offer so much more flexibility and your average drooling API monkey(read: php+mysql) can understand it. Most of the drooling monkeys actually think that the relational in relational database has something to do “with how tables are related” which is not only laughably wrong it is pathetic.

    It is much easier for these idiots to understand key-value and graphs.

Leave a Reply

Your email address will not be published. Required fields are marked *