On Selecting a Database System Fit for the Task

Now that the rate of hot air hissing out of the NoSQL marketing balloon seems to be abating, we can take stock of the obvious qualities of the technologies in a less excitable atmosphere. There are some impressive technologies out there. The oddly-named Neo4J, for example, is an excellent ‘Graph’, or network, database that can do analysis that is awkward to do with an RDBMS. Then there are useful wide-columnar stores like Cassandra, and document databases like RavenDB and MongoDB.

However, when NoSQL databases attempt to portray themselves as the new radical alternative to “old-fashioned” and entrenched RDBMSs like SQL Server, for general commercial database work, they can come unstuck, as anyone following the ups and downs of MongoDB will observe.

I can’t help but think MongoDB as the Labrador puppy of the NoSQL world. It’s cute and everyone likes it, but it persists in barking excitedly and knocking over furniture. Three German students recently discovered up to 40,000 MongoDB databases, running as web services or website backends, with a completely “open door” policy to entry, where it would be possible to access and even modify the data in the databases without even the inconvenience of first needing to gain access to a login!

It’s not as if MongoDB doesn’t come with the requisite security features to prevent this; it does. However, it’s inevitable that many will neglect to follow them. Instead, it relies on technical expertise to set it up. The default in the above case appears to be no security at all.

This sort of attention to detail might not be important to your application. If your data is short-lived, does not need industry-level custodianship, and if a high level of consistency and correctness isn’t a high priority, then RDBMSs might be overkill for you. Likewise, you may have certain types of data that require the special processing magic or speed offered by certain NoSQL databases.

The reasons that RDBMS seem relatively slow and overweight when compared with NoSQL is that they are designed for a different purpose. By their very nature, business applications have little use for approximation. Instead, correctness, consistency, and transactional integrity is fundamental, no matter the volume of simultaneous transactions. This type of application has legal obligations to provide for a variety of audit, access-control, encryption and other security options. They must fail gracefully in the face of hardware problems.

You shouldn’t choose a NoSQL database merely because you think it will be easier to use, quicker to learn or that you’ll need less qualified or expensive people to administer it and ensure that it is secure. Choose one only if it is a better fit for your business requirements. If you accept that idea, then it seem reckless to judge whether you can stray too far from the safe haven of the RDBMS until you are sure you understand fully the broad sweep of your business requirements.