What Is a Multi-Model Database? A Practical Guide

Most applications outgrow a single data shape. Orders are rows, product catalogs are nested documents, customers and their relationships form a graph, search needs an inverted index, and more and more teams are asked to add embeddings for semantic search. The traditional answer was one specialized database per shape. A multi-model database answers the same need with one engine.

This guide explains what a multi-model database is, how it differs from running several databases side by side, where it fits and where it does not, with examples in ArcadeDB, an open-source multi-model database.

What is a multi-model database?

A multi-model database is a single database engine that supports several data models natively and lets you query them together. Instead of choosing between a relational, document, graph or vector database, you get the models you need in one place, with one storage engine, one transaction manager, one security model and one backup.

The models you will meet most often:

A database is multi-model when several of these are first-class: you can create them, index them and query them without bolting on a second system.

Multi-model vs polyglot persistence

The alternative to multi-model is polyglot persistence: one specialized database per model. A typical stack might pair a relational database for orders, a document store for the catalog, a graph database for relationships, a search engine for text and a vector database for embeddings.

Each of those products may be excellent at its job. The cost is in the seams between them:

• Synchronization. The same customer now lives in several systems. Every write has to reach all of them, usually through change-data-capture or a message queue, and every pipeline is another thing that can lag or break.
• No shared transaction. If an order is written to one store and the relationship to another, there is no single commit. Failures leave the systems disagreeing until something reconciles them.
• Queries that cross models become application code. “Find documents semantically similar to this question, then follow the graph to the entities they mention” turns into two network calls and a join in your service.
• Operations multiply. Each database has its own backups, upgrades, monitoring, security model and expertise to hire for.

A multi-model database removes the seams: the records, edges, text index and vectors live in one engine and commit together.

What multi-model looks like in practice

In ArcadeDB, a vertex is also a document. It can hold nested objects and arrays, sit in a graph, and carry an embedding, all in one record:

CREATE VERTEX TYPE Customer;

CREATE VERTEX Customer CONTENT {
  "name": "Acme",
  "address": { "city": "Rome", "zip": "00100" },
  "tags": ["vip", "eu"]
};

-- document-style query on nested fields and arrays
SELECT name, address.city AS city
FROM Customer
WHERE 'vip' IN tags;

The same record can then be connected with edges and traversed as a graph. And because the vector index lives in the same engine, one query can retrieve by meaning and expand by relationships. This Cypher query finds the documents closest to a question embedding and returns the entities each one mentions:

CALL db.index.vector.queryNodes('Doc[embedding]', 5, $queryVector)
YIELD node, score
MATCH (node)-[:Mentions]->(e:Entity)
RETURN node.title AS title, score, collect(e.name) AS entities

With polyglot persistence, that is a call to a vector database, a list of IDs, and a second call to a graph database. In one engine it is one query and one round trip. It is also the core pattern behind GraphRAG: vector search finds the entry points, the graph supplies the context an LLM needs.

Several query languages over the same data is the other half of multi-model. ArcadeDB accepts SQL, Cypher, Gremlin, GraphQL, and the MongoDB and Redis query languages against the same records, so each team can use the language that suits the task. Our query cheat sheet shows the same tasks in SQL, Cypher and Gremlin side by side.

Native vs layered multi-model

“Multi-model” covers different architectures, and the difference matters for performance.

• Native multi-model. The engine implements each model directly: graph edges are stored as links between records, so following a relationship does not require a join or an index lookup per hop; documents are stored as documents; vectors live in a real approximate-nearest-neighbor index.
• Layered or emulated. One core model hosts the others. A relational database might store documents in a JSON column and answer graph queries by translating them into joins. That works for light use, but a deep traversal still pays the cost of a join per hop.

When you evaluate a product, ask how each model you care about is stored and executed, not only whether it appears on the feature list. Our comparison of ArcadeDB and PostgreSQL for graph queries shows the difference on a standard benchmark: graph patterns that compile to joins against the same patterns run on native graph storage.

Benefits of a multi-model database

• One transaction across models. A new customer, the edge to their company and their embedding commit together or not at all.
• No synchronization pipeline. There is one copy of the data, so nothing can drift.
• Cross-model queries. Filter on document fields, rank by text relevance or vector similarity, and traverse relationships in the same query.
• Fewer systems to run. One deployment, one backup, one monitoring setup, one set of credentials and permissions.
• Room to evolve. When the product needs a graph or semantic search next year, you add a type and an index, not a new database.

Trade-offs to consider

Multi-model is not automatically the right answer.

• Depth per model varies by product. A specialized engine may offer niche features a multi-model engine lacks. List the features you actually use and check each one.
• One engine is one failure domain. Consolidation reduces moving parts, but it also means the database’s high-availability setup carries more weight. Look at replication and failover as carefully as at features.
• Team familiarity. If your team knows one specialized database deeply and your application only ever needs that model, switching buys little.

When to choose a multi-model database

A multi-model database is a strong fit when:

• your data has relationships that matter and also needs document flexibility or search, as in a Customer 360 view that unifies profiles, interactions and accounts;
• you are building AI features that combine vector retrieval with structured context, such as GraphRAG or agent memory;
• you need consistency across shapes, as in fraud detection, where transactions, devices, accounts and their links must be evaluated together in real time;
• you want to cut the number of databases you operate.

If you already run a database and want to see how a multi-model engine compares, the Neo4j alternatives overview covers the open-source options, and ArcadeDB’s OrientDB migration guide covers the multi-model database it succeeded.

Try ArcadeDB

ArcadeDB is open source under the Apache 2.0 license, with graph, document, key-value, full-text search, vector and time-series models in one engine. You can run it embedded in a Java application, as a server, or as a cluster. The free ArcadeDB Academy courses walk through the models one at a time, and the GitHub repository has everything else.