What is a multi-model database?

A multi-model database is an engine that stores and queries multiple data models, relational, document, graph, key-value, vector, in the same product, instead of handing each model to a separate specialized system. The term dates to May 2012, coined by Luca Garulli, creator of OrientDB, in a keynote at NoSQL Matters Cologne, as an explicit alternative to polyglot persistence: instead of multiple specialized databases stitched together by synchronization pipelines, a single product hosts several models internally. But "handling multiple models" is an ambiguous claim, and the reference academic survey, Lu and Holubová in ACM Computing Surveys (2019), draws a precise line between two distinct capabilities: storage capability (storing data across multiple models in the same product) and cross-model guarantee capability (a single transaction, a single query optimizer, a unified consistency model across models). The same survey, examining the systems then in existence, found none with full, genuine cross-model transactional management: nearly all offered shared storage, few offered truly unified guarantees.

See also: Graph database · The database that stores nodes and relationships as a native structure: the storage technology a knowledge graph is often built on.

Why the distinction matters

The gap between "stores multiple models" and "guarantees one transaction across models" changes what you can promise an internal stakeholder. If an application writes a document and simultaneously updates a connected relationship graph, that write may be a single atomic transaction, with coherent rollback across both models on failure, or two separate writes sharing only the underlying physical infrastructure, with two independent failure paths. DB-Engines formalized the distinction in 2019, introducing "primary model" and "secondary models" tags in its ranking, a signal that the market needed a way to say "supports multiple models" without automatically implying "the guarantees are unified".

The real enterprise choice

A company that needs to track orders (relational), the network of supplier relationships (graph), and semantic search over contracts (vector) has three paths: separate specialized systems with synchronization pipelines (classic polyglot persistence, more isolation of guarantees per model but more systems to govern, more sync latency, more failure surface), a data lakehouse with multi-model extensions, or a natively multi-model database. The operational upside of a single product is real: fewer systems to patch, one permission model, one team learning one tool. The risk is assuming "one product" automatically equals "one transaction": if the vendor offers shared storage but separate query optimizers per model, the company still runs two distinct guarantee systems, just inside the same binary.

The questions to ask before signing

Anyone evaluating a multi-model database should test concretely what the marketing sheet promises: whether a write touching two models in a single transaction fails and rolls back on both, or only on one. Whether the query optimizer plans cross-model joins in a single execution plan, or internally translates to separate per-model queries. Whether the transaction isolation level (dirty reads, repeatable reads) is identical across every model, or varies from one to another. Without verified answers to these three questions, "multi-model" only describes where the bytes physically live, not what you can promise about the atomicity of operations that cross them.