Over the last year, we’ve heard a lot of buzz about the “NOSQL” movement and the development of document-oriented, key-value and other data stores which do not provide traditional SQL (Structured Query Langauge) interfaces. Such databases include: CouchDB, MongoDB, and others like Cassandra (from Apache & Facebook). Even Microsoft has entered the fray with Azure.

Through this recent project, we gained significant exposure to one of these, MongoDB. While we would not replace our trusty SQL database with Mongo in many applications, MongoDB is a compelling option and indeed recommended in situations such as patient records and other data sets with operations performed in the context of single large hierarchical records.

These records often require many SQL joins to assemble in memory and with agile development methods requiring greater flexibility in data models, keeping complex joins optimized can slow development and be a constant source of tension between developers and corporate IT.

We would consider adding a non-SQL data store to a project where the performance characteristics will make significant impact and the extra complexity does not present a problem and perhaps most importantly, where technical buy-in has been achieved with all stakeholders. In all the applications we have considered so far, a traditional SQL database continues to be used in addition to any alternative data store. NOSQL doesn’t mean No-SQL. We take it to mean, “Not Only SQL.”