SQL Is Not the Problem

There is a lot of buzz about NoSQL out there. According to the hype, NoSQL solves scalability issues, NoSQL simplifies development, NoSQL has unlimited write performance, etc. While these claims may technically be true, they are in no way exclusive to the NoSQL offerings out there. All of these things are achievable in a SQL database with full ACID and relational capabilities. In a recent post, Derrick Harris asks “Will Scalable Data Stores Make NoSQL a Non-Starter?” He Makes the point that scalable SQL is a reality today, so why would someone go to a NoSQL solution? What benefit could it possibly bring? Would anyone choose to give up transactions if they didn’t have to? Would anyone choose to give up ACID properties? Would anyone choose to give up the ability to do relational operations? How would giving up any of these things simplify development? Looking at the comments on Derrick’s post provides a clue. They mention the “flexible schema” as the key feature.

A flexible schema is defined by the ability to assign arbitrary properties to an object without having to have defined columns for those properties. For example, in a single table, object A could represent a picture and have “height” and “width” properties while object B could represent an audio stream that has “length” and “bitrate” properties. In a traditional RDBMS environment, you’d probably create multiple tables for each different object type which can be inconvenient and possibly inefficient.

Is that it? Why wouldn’t you just add that feature to a scalable SQL database rather than throw away all the good things SQL databases have to offer? You could easily add a “map” column to a table that allows you to store an arbitrary map of key/values associated with an object. You now have the tools to implement a flexible schema while maintaining relational capabilities, ACID properties, and full scalability. It’s the best of both worlds.