New options in the DB-Engines ranking for multi-model DBMS

by Paul Andlinger, Matthias Gelbmann, 19 February 2019
Tags: Database models, DB-Engines Ranking, Multi-model DBMS

We recently changed the way we treat the multi-model aspect of database management systems and introduced a new option in the popularity rankings. This article explains the ideas behind.

Today, the management, querying and efficient use of vast amounts of structured and unstructured data often requires storing that data with different specialised data models. That may be in tabular form (Relational DBMS), graphs (Graph DBMS), documents in JSON or XML form (Document Stores, XML DBMS), time-series data (Time Series DBMS) and with several other models.

For using more than one data model in parallel, there are basically two options:

Use a polyglot database architecture (multiple DBMS with a single model)
Use a multi-model DBMS (a single DBMS supporting multiple models)

Because both approaches are valid, many DBMS vendors extended their existing products to support additional data models. Some examples are:

Oracle, the undisputed leader of relational DBMS enhanced its product with document, graph and RDF capabilities, making it a multi-model DBMS.

In the version 8.0 of MySQL a new document store model was introduced, which allows JSON documents to be stored in collections and managed using CRUD operations.

Microsoft SQL Server, PostgreSQL, IBM Db2 and many other RDBMS similarly extended their functionalities with multi-model capabilities.

The same trend is also seen in NoSQL systems. E.g. Redis, the most popular key-value store extended its application scenarios with downloadable modules into a multi-model DBMS.

The situation is completed by DBMS's, which are originally built to process data in different shapes (e.g. ArangoDB, OrientDB or Microsoft Azure Cosmos DB).

The DB-Engines popularity ranking must allow for that situation, especially in the adequate handling of the multi-model aspect in the DB-Engines sub-rankings (e.g. in the ranking of document stores): one visitor of such a sub-ranking may want to see only the systems specialised for the specific data model in this ranking, and does not want to have all multi-model systems diluting that ranking. The other visitor just wants to have all databases supporting that data model in the corresponding sub-ranking. In order to facilitate that choice, we now provide a checkbox, which allows a visitor to switch between the two presentation formats.

To make that possible, we had to slightly redefine the semantics of the already existing attributes ‘primary database model’ and ‘secondary database model’. The former now denotes the data models for which a DBMS is normally known and is predominantly used. For example, there is no doubt that Oracle got its popularity from being a RDBMS, therefore its primary data model is ‘RDBMS’. As mentioned, it nowadays also supports document, graph and RDF models. This information is conveyed in the attribute ‘secondary database models’. As a consequence, the ‘primary models’-attribute controls in which sub-ranking a system goes and which database model is listed for the system within the ranking tables. Systems having more than one primary model just show up as ‘multi-model’. Clicking the checkbox in a sub-ranking includes also the databases supporting that data-model as a ‘secondary model’.

It is important to mention, that these changes do not impact the various statistics about the overall popularity of data models (e.g. https://db-engines.com/en/ranking_categories), since we are still using the primary model for that calculation.

As some data models inherently can support other models (e.g. each relational system can be (mis-) used as a key-value store), we do not qualify a system as multi-model in that case.

Share this page