NoSQL or RDBMs: who will win the database war?

This is a guest post for Computer Weekly Open Source Insider written by Sandor Klein of EDB, a provider of enterprise-class products and services based on PostgreSQL.


An open (data) battlefield

The NoSQL and relational database camps emerged fighting in 2013, and the once peaceful niche of data management has transformed into an open battlefield.

As businesses look to cope with the challenge of big data, both camps claim to offer the best approach when it comes to managing the data deluge.

Selecting the right database to suit your requirements has become tricky amidst a noisy backdrop of claims and counterclaims from the market’s major players on both sides of the divide.

As the battle continues to intensify into 2014, what hope is there for the relational camp when it comes to convincing CIOs that their solutions are more than match for the rapidly maturing NoSQL solutions that have sauntered into the marketplace? As it happens, plenty.

Noisy Mongo

The likes of CouchDB, Redis and MongoDB have certainly made a lot of noise to attract attention in 2013, but advances made by relational databases such as Postgres have continued apace.

Relational systems have been very good at learning the lessons that the NoSQL systems presented. By tooling up in areas such as JSON for semi-structured web-based documents and fast data lookups through HStore, relational solutions are now in a position to offer precisely the same core capabilities as NoSQL vendors.

This is in addition to meeting standard transactional requirements — which is not to say there is no role to play for NoSQL systems. Indeed many organisations have found that NoSQL technology is very well-suited to some types of big-data applications, but not others.

What NoSQL is good at

NoSQL’s strength lies in its ability to number crunch vast amounts of data, not as a solution for real-time decision-making. The key is for organisations to use the right technology for every application.

When a technology triggers an ideological divide as NoSQL has, there is a tendency to take sides. What’s important is for organisations to take a more enlightened view, overlooking the hype and making a decision that will ultimately derive maximum value from their database investments.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Totally agree that organizations should use the right technology for each App - and developers have turned to NoSQL for scale. Some NoSQL technologies however had problems scaling and as you say, many don't work for real-time. Check out Aerospike - In-Memory NoSQL for speed at scale - with the economics of flash. Lots of case studies, revenue critical deployments at global scale.
Thank you for your post, I enjoyed reading. As I see it, NoSQL is a new thing, new is choice, and choice is good. But for the right goal and at what cost? NoSQL (mentioned MongoDB and others) is solving real pains of the modern world that 30 year-old RDBMSs couldn't extend to solve, for example schema (or schema-less) agility, and also scalability and distribution of course... it is difficult to distribute data for relational databases, and I agree! However solutions exist to overcome specific shortcomings of RDBMSs and bring them to the same level of MongoDB's, while preserving relational, normalization and ACID. I work for ScaleBase, specializes in – the automated and logical distribution of relational data using MySQL backend databases, and optimized for the cloud. I’ve authored some blogs, showing how modern needs can be met by MongoDB as well as with MySQL, looking at autosharding, data distribution and query models if anyone is curious to know more. So customer can really have the choice, the right tool for the right job, NoSQL or relational. Decision on the goal on common grounds, compare apples to oranges, but at least of the same size and ripeness... Thanks again for the post!
Great post – there’s definitely truth behind the statement that each particular job requires a different tool. Hence why mechanics carry a vast set of tools in their tool belt – although a hammer could technically work, it’s just not practical when you need to screw in a nail.
To start off, you should consider what questions or tasks you need answered or fulfilled – this should help you decide what database you should aim for. Sometimes the answer isn’t as simple as NoSQL vs. another database option. Rather, sometimes it is about the integration of the right database solutions to make everything work in sync. For example, you correctly highlighted the concern about some Open Source NoSQL options not supporting Real-Time Transaction Processing, a critical requirement for mission critical applications, so it’s critical to make sure the deployment fits your processing needs.

For example: consider the option of an integrated NoSQL+SQL solution rather than choosing the mainstream SQL-only approach or the NoSQL-only approach could save you time and cost. It’s important to take an integrated approach at the inception of the project, which ensures the ability to share data sets across applications.

With more than 20+ year working with specialized applications dealing with non-structured data, our experience shows that multiple problems are better handled with a strong, reliable, key-value core database that will enable you to later integrate with SQL-only mission-critical systems, like the data warehouse, or Big Data analytics.

With both databases integrated, NoSQL + SQL offers engineers more flexibility and more control – with less overhead – ensuring your organization can process large data volumes, but continue to your needs over the long term.

Evaldo Horn de Oliveira, Director of Business Development, FairCom