Content repositories: SQL or NoSQL?

The NoSQL movement seems to be pretty active, advocating a move away from traditional relational databases:

...developers have become crippled by being able to only think of data in terms of Rows and Columns. There's a multitude of database paradigms: Graphs, Trees, Objects, and so on. Furthermore, databases limit developers to SQL, which is great for certain kinds of set mathematics and not much else. In order to overcome fundamental limitations of DBs, things like Conditionals, Iteration, String Manipulation, and more have been hacked into what was at first an elegant set mathematics language.

Algorithms (such as MapReduce) which make data analysis scalable are highly unintuitive in SQL. The limitations in the environment lead to a limitation in engineers' ability to solve "big data" problems.

This may be true if you're building the next Twitter or Facebook. But how many of us really do?
In the quite ranty article I Can't Wait for NoSQL to Die Ted Dziuba has a point:

by replacing MySQL or Postgres with a different, new data store, you have traded a well-enumerated list of limitations and warts for a newer, poorly understood list of limitations and warts, and that is a huge business risk.

This is exactly the reason we decided to build Midgard2 on top of a relational database. While it does constrain us in some cases, we can still provide a quite reasonably full-featured content repository this way.

And being built on SQL means we know the system scales down to mobile devices and all the way up to major business systems like Lufthansa's global marketing budget tracking. That is something very few NoSQL systems will be able to boast.


Read more Midgard posts.