Blog > Post
The Weight of Relational Databases: Time for Multi-Model?
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.
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.
|About the Author:
||Luca Olivari is a software executive and advisor with almost two decades of experience. He has held several senior leadership positions at public as well as venture-backed, high-growth startups. Before running the international Business Development and Strategy at MongoDB, he led the MySQL Sales Consulting across EMEA at Oracle. Prior to joining ArangoDB as the next big thing in the database world, Luca served as Chief Data Officer at ContactLab, a leading engagement marketing cloud provider.|
Teilen sie diese Seite mit ihrem Netzwerk