On MongoDB, SQL and ACID

Gavin Clarke published an interesting piece in The Register this morning entitled MongoDB straps SQL to Google’s MapReduce.  The article covers several points, but the gist (from my read) goes something like this:

• The forthcoming MongoDB, 2.2 will contain a set of operators, collectively called the New Aggregation Framework, that more or less emulate SQL’s GROUP-BY command construct.  To achieve GROUP-BY functionality, developers can stitch operators together into a “pipeline” – sort of like they do when building Unix shell scripts.
   
• According to the article, 10Gen’s CEO Dwight Merriman described MongoDB’s document-level atomicity as sufficient to cover the “majority” of transactional use cases.

While neither of the above points is surprising (I’d probably be doing and saying the same things if I were Dwight), the first one misses the mark and the second one is just plain dangerous.

On SQL

Regardless of how you feel about SQL, it is a standard.  When a vendor says “We support the SQL 99 spec, with the following exceptions and extensions”, that statement informs database technology consumers about the degree to which their existing tools, infrastructures and human skills can be leveraged.  NoSQL vendors can offer no such guidance – each one is rolling their own database syntax and semantics.  “If my team builds an app in MongoDB and then needs to build another in Cassandra or Riak, how portable is their knowledge?”  The answer: not very portable.

So, while MongoDB’s aggregation functionality is a step toward making MongoDB itself more usable, it is not a SQL GROUP-BY construct and offers none of the attendant benefits of a standard, broadly supported data language.

On ACID Transactions

With regard to ACID transactions, you either support them or you don’t.  Statements like “we cover the ‘majority’ of transactional use cases” are dangerous and unhelpful.  They put the burden on developers to determine whether a database product provides “enough” transaction support to service an application’s needs (or potentially many apps built on top of the same database) – today and in the future.  Make a bad choice there and you’re screwed because it means you’ll then have to implement transaction support in your applications.  Who in their right mind would want to do that?

Summary

There are clearly applications for which NoSQL solutions are the best fit – in particular, ones that have frequently-changing data models and require no transaction support.  However, in their froth to embrace shiny new objects, some developers have lost sight of proven engineering virtues – standards and knowledge portability matter a lot, and ACID transactions are non-negotiable when data must be 100% accurate 100% of the time.  Choosing the right tool for the job has never been more critical.