August 24, 2015

Multi-model database managers

I’d say:

Before supporting my claims directly, let me note that this is one of those posts that grew out of a Twitter conversation. The first round went:

Merv Adrian: 2 kinds of multimodel from DBMS vendors: multi-model DBMSs and multimodel portfolios. The latter create more complexity, not less.

Me: “Owned by the same vendor” does not imply “well integrated”. Indeed, not a single example is coming to mind.

Merv: We are clearly in violent agreement on that one.

Around the same time I suggested that Intersystems Cache’ was the last significant object-oriented DBMS, only to get the pushback that they were “multi-model” as well. That led to some reasonable-sounding justification — although the buzzwords of course aren’t from me — namely:

Caché supports #SQL, #NoSQL. Interchange across tables, hierarchical, document storage.

Along the way, I was reminded that some of the marketing claims around “multi-model” are absurd. For example, at the time I am writing this, the Wikipedia article on “multi-model database” claims that “The first multi-model database was OrientDB, created in 2010…” In fact, however, by the definitions used in that article, multi-model DBMS date back to the 1980s, when relational functionality was grafted onto pre-relational systems such as TOTAL and IDMS.

What’s more, since the 1990s, multi-model functionality has been downright common, specifically in major products such as Oracle, DB2 and Informix, not to mention PostgreSQL. (But not so much Microsoft or Sybase.) Indeed, there was significant SQL standards work done around datatype extensions, especially in the contexts of SQL/MM and SQL3.

I tackled this all in 2013, when I argued:

Developments since then have been in line with my thoughts. For example, Spark added DataFrames, which promise substantial data model flexibility for Spark use cases, but more mature products have progressed in a more deliberate way.

What’s new in all this is a growing desire to re-integrate short-request and analytic processing — hence Gartner’s new-ish buzzword of HTAP (Hybrid Transactional/Analytic Processing). The more sensible reasons for this trend are:

But here’s the catch — the best models for writing data are the worst for reading it, and vice-versa, because you want to write data as a lightly-structured document or log, but read it from a Ted-Codd-approved RDBMS or MOLAP system. And if you don’t have the time to move data among multiple stores, then you want one store to do a decent job of imitating both kinds of architecture. The interesting new developments in multi-model data management will largely be focused on that need.

Related links


3 Responses to “Multi-model database managers”

  1. clive boulton on August 26th, 2015 7:59 pm

    Multi-model seems be to shifting from Caché class #SQL, #NoSQL support, to support for management of different storage engines in the same cluster. MongoDB’s Wired Tiger.

    Perhaps the real break thru is eliminating the “impedance mismatch” between application programming and frugal multitenancy.

  2. Andy Lawrence on September 4th, 2015 12:02 pm

    I am currently working on a new general-purpose data management system that supports several different data models. It was originally designed as a file system replacement that uses a new kind of data object I invented (a Didget) to manage unstructured data with extensive structured meta-data extensions (i.e. tags). It essentially became a new kind of file system that had a lot of database features.
    The database features worked so well, that I tried to implement a traditional RDBMS on top of it. Tables are created using a column based set of key/value stores. So far, I am able to outperform traditional database managers (MySQL and PostgreSQL) at query operations. My system does not use indexes, yet my queries come back faster (and require less disk reads and memory footprint) than fully indexed tables on those other systems.
    The system is still under development but all the tests so far are looking very promising. I want this product to be a platform upon which relational databases, graph databases, document databases, and key/value stores can be built. It is versatile enough to meet the needs of applications that currently need file systems, SQL stores, and NoSQL stores to manage large sets of both structured and unstructured data.
    A simple video demonstration can be seen at:

  3. Andy Lawrence on September 21st, 2015 4:01 pm

    Update – Using some multi-threading techniques, I have a version that is now even faster. See how fast at

Leave a Reply

Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:


Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.