The Weight of Relational Databases: Time for Multi-Model?
While computers and software have changed greatly in the past 47 years — since the start of epic time — there has been little innovation related to databases. Software requirements have changed dramatically over the past five decades; computing needs are vastly different.
In the 1970s, Intel introduced the first 4004 microprocessor that accessed only 640 bytes of memory. In the same period, the first relational database system was designed. RDBMS was invented from the paramount need to optimize storage and to utilize memory, efficiently. The world was an extremely different place. Almost everything in the computer hardware and software world has changed since then, except for relational databases. Are they still the best solution?
Polyglot Persistence
Michael Stonebreaker predicted that “This concept [one size fits all] is no longer applicable to the database market, and [we believe] the commercial world will fracture into a collection of independent database engines.”
He had a point. The desire to do things differently has prompted many to follow the polyglot persistence paradigm. Hundreds of database companies focused on solving one problem very well: dealing with complex relationships with graphs, handling structured and semistructured data with documents, or offering fast response times with key/value stores.
The argument goes like this: focus on a narrow issue and build a specialized solution that solves it well and thereby makes developers happier and more productive. It’s appealing. It works. And it scales well.
We’re not disputing Martin Fowler’s foundational polyglot persistence argument. There are indeed hundreds of purpose-built databases. Every company tends to adopt more than one. We are arguing that single-model databases became so involved in solving niche problems that they couldn’t see the forest for the trees. They didn’t realize that the real problem was elsewhere. As a result, they didn’t help developers to become more productive.
Excessively Increasing
Polyglot programming is older than polyglot persistence. Still, applications are built mainly with a single programming language, with ancillary functions and features using different ones. The same is true for databases. Using different solutions is not always easy. The more databases, the more systems and processes needed, as well as more people to hire, train and manage.
Relational databases have been so successful primarily because of the one-size-fits-all approach. Nevertheless, the relational model doesn’t align with how modern applications are built. There’s a definite market need for a better next-generation, general purpose database.
One Size Fits Most
Companies today are looking to reduce the number of technologies used, striking a fine balance between innovation and productivity. They’re looking for a next generation, “core database technology” with which to build most of their applications and the best “edge databases” for specific cases.
A database cannot support each and every data model without at least compromising performance, and at best be good at everything and great at nothing. Still, if one could build a database from the ground up which natively supports the most important data models, it could be the infrastructure for the vast majority of the applications.
A multi-model database, like ArangoDB, has been built to process data in different shapes: key/value pairs, documents and graphs. It allows developers to use naturally all of them with a simple query language that feels like coding, but can be faster than purpose built solutions. Imagine that: one language to learn; one engine to know and operate; one product to support. That’s so much easier.
Certainly, we will continue to live in a polyglot persistence world. However, multi-model databases are emerging as the next generation database platform to provide a one-fits-most solution that’s been missing for a very long time.
Originally published, with minor changes, at dataandco.expertly.io and db-engines.com
