The (non-)sense of NoSQL O(R)M frameworks

NoSQL seems to be ready for prime time. Several NoSQL companies, including 10gen (MongoDB), DataStax (Cassandra) and Neo Technology (Neo4J), recently received millions in funding to expand their (commercial) NoSQL offerings. Even Oracle is now entering the already crowded NoSQL-space with its very own key-value NoSQL Database 11g. No doubt that this type of publicity will boost the enterprise adoption of NoSQL technologies.

At the same time, the rise of Object Relational Mapping (ORM) within the NoSQL space is impressive. Multiple approaches and frameworks are competing within the same solution space and I can’t stop wondering whether they do not enter the market too soon … Don’t get me wrong. I strongly believe in the advantages of using an ORM. In fact, I can not even remember my last enterprise-type application that is not powered by an ORM. So why am I expressing my concerns in case of NoSQL?

Relational databases have been around for the past thirty or more years. We have all done our own share of low-level database work and have been exposed to the overal technicalities of a RDBMS. As a result, when advancing to the use of an ORM, people can count on this basic knowledge set when problems are encountered. Most of us however, lack this type of in-depth NoSQL expertise. Nevertheless, as the NoSQL hype is growing, people will fall back on their ORM expertise in order to quickly adopt this new technology. This is enforced by the motivation of several NoSQL ORM frameworks: “Don’t mind the NoSQL complexities. Just employ an approach you already know!”. Unfortunately, all abstractions will fail you at some point in time …

But what about the mapping-side of things? First of all, various NoSQL approaches, including document-based databases, don’t exhibit the object-oriented impedance mismatch. In approaches that do, an ORM will not always make sense. Several ORMs target a variety of NoSQL technologies by providing a generic mapping framework: “Map your objects. Don’t care about the target NoSQL technology. We’ll do that.”. Unfortunately, this approach will fail you at achieving the true (performance) promise of NoSQL. An ORM framework would not have been able to help me at attaining the performance gains as described in one of my previous articles. In fact, it would not even make sense to implement the problem domain as such. Hence, I’m afraid that the use of an ORM framework will disappoint a lot of NoSQL newcomers …

ORM frameworks in the NoSQL space will however get us closer to the idea of Polyglot Persistence. Spring Data Graph for instance, allows you to map Pojos in such a way that parts of it are persisted to a traditional database and parts of it to the Neo4J graph database. This is achieved in a technical transparant way, making it an easy-to-use solution. Nevertheless, I still feel it’s way too soon for ORMs as the knowledge and best practices on NoSQL are just being developed.