Relational databases and SQL rule the world! You must be a ‘grey hair’ to remember the days when databases were not relational and Edgar Frank ‘Ted’ Codd still was but yet another researcher at IBM. A researcher who was quite disappointed when IBM initially wasn’t interested in his new ‘relational’ scheme of storing data, because the company cared more for the revenue being generated by its IMS database system. Actually, IMS was only one of plenty of non-relational databases that ruled the 60/70/80’ies: IDMS, Adabas, Datacom/DB, Model 204, to name but a few of them. By the way, most of these database products are still in use, usually for the most critical of business applications.

The present day NoSQL products, however, are no continuation of that first generation of database systems. On the ‘nosql-database.org’-site the concept ‘NoSQL’ is defined as ‘next generation databases addressing some of these points: being non-relational, distributed, open source and horizontal scalable’, targeting webscale-databases (at least originally). Other aspects are ‘schema-free’, ‘easy replication support’, ‘simple API’ and capable of handling very large amounts of data, particularly non-structured document-type of data (in the Terabyte and Petabyte-ranges). This is exemplified by users as Google, Amazon, Facebook, LinkedIn, Twitter, Sourceforge and BBC. The latter uses CouchDB to handle 150 million requests per day on two clusters of systems.

The different needs of these companies also make it very clear that NoSQL is not a single concept. Several approaches are considered and some people would rather refer to this movement as ‘NoREL’, for ‘non-relational’. Neal Leavitt (1) points to three popular types of NoSQL databases, in casu ‘key values stores’, ‘column oriented databases’ and ‘document based stores’. And yes, all of them have their advantages and problems.

In general, NoSQL products are deemed to be much faster handling data than relational databases, often because of simpler data models. But also because they do not always abide by the same strict datahandling standards as required by mission critical back office databases.

A major challenge is the youth of these products, leaving them without the myriad of support tools that have emerged in the relational database space. That leaves lots of additional coding to be done, limiting NoSQL acceptance by companies without in-house expertise.

In general, the remarks of Dmitriy Ryaboy in his article should be very thoroughly considered before jumping into NoSQL, because this truly is still an emerging field of expertise. And clearly, it will not replace the relational database systems, as the latter did not replace the first generation of database systems. Cohabitation will be the rule, and that requires additional effort for the business case of a NoSQL project. That is, are the profits and advantages really bigger than the hassle and disruptions it will generate?

It is to the credit of Devoxx that expanding beyond the world of Java, it provides a platform for discussion and learning about elements that are closely related to today’s development needs, while not being ‘classic’ programming subjects!

(1) “Will NoSQL Databases live up to their promise?”, Neal Leavitt, Computer, vol. 43, no. 2, pp. 12-14, Feb. 2010,

(GK)