This post is a response to a recent post from Michael Stonebraker on ACM.com called Why Enterprises Are Uninterested in NoSQL. First and foremost it’s important to recognize the contributions that Dr. Stonebraker has given to the relational database community. His work impacts our lives, as engineers, on a daily basis and we wouldn’t be having this discussion without all of his contributions.
However, despite this, I believe that he has done the enterprise software community a disservice with his latest post. Our job as engineers is to choose tools that help us meet requirements that are part of a solution to a business problem. It’s irresponsible of us to not explore all options when selecting tools that are equally capable of solving the problem at hand, regardless if the solution is a traditional relational database such as MySQL or if it’s a non-relational database such as MongoDB.
Certainly each product has their own trade-offs, but in the end it’s our job as the engineer to evaluate those trade-offs and to validate that they are acceptable within our project’s framework and goals. If they are acceptable who’s to say that we’ve made the wrong choice.
In his post Dr. Stonebraker indicates that the single enterprise user he spoke to indicated that support for ACID transactions was a mandatory requirement. Great! Perhaps a solution like OrientDB or Neo4j might be able to help him as both projects support ACID transactions. Does this mean that because they are considered NoSQL databases that they should not be evaluated? Of course not, but Dr. Stonebraker and his single enterprise user would like you to think that’s what should happen.
Furthermore, both Dr. Stonebraker and his single enterprise user indicate that NoSQL means no standards. For the record NoSQL really means Not Only SQL. In other words, there are other solutions than an RDBMS. However, what Dr. Stonebraker does not point out is that there are projects out there that are trying to help solve this problem.
For example, there is Project Blueprints from TinkerPop. Project Blueprint’s goal is to provide “a one stop shop for implemented interfaces to help developers create software without being tied to particular underlying data management systems”. True, projects like this might be in their infancy, but given time may grow to become the standards that Dr. Stonebraker says are missing from NoSQL.
Finally, I’d like to close with the following. NoSQL has never been promised as the great panacea to all of the world’s persistence problems. In fact, we make it quite clear that each NoSQL database has trade-offs that must be accounted for. NoSQL is not an either or proposition with a traditional relational database. In fact, polyglot persistence is a term we throw around freely. In other words, we advocate choosing the right tool to solve your problem. It means we evaluate all possible solutions, relational or non-relational, regardless if we are working for the latest web start-up or the biggest enterprise IT department.