Hubbry Logo
Multi-model databaseMulti-model databaseMain
Open search
Multi-model database
Community hub
Multi-model database
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Multi-model database
Multi-model database
Multi-model database
View on Wikipedia
from Wikipedia

In the field of database design, a multi-model database is a database management system designed to support multiple data models against a single, integrated backend. In contrast, most database management systems are organized around a single data model that determines how data can be organized, stored, and manipulated.[1] Document, graph, relational, and key–value models are examples of data models that may be supported by a multi-model database.

Background

[edit]

The relational data model became popular after its publication by Edgar F. Codd in 1970. Due to increasing requirements for horizontal scalability and fault tolerance, NoSQL databases became prominent after 2009. NoSQL databases use a variety of data models, with document, graph, and key–value models being popular.[2]

A multi-model database is a database that can store, index and query data in more than one model. For some time, databases have primarily supported only one model, such as: relational database, document-oriented database, graph database or triplestore. A database that combines many of these is multi-model. This should not be confused with multimodal database systems such as Pixeltable or ApertureDB, which focus on unified management of different media types (images, video, audio, text) rather than different data models.

For some time,[vague] it was all but forgotten (or considered irrelevant) that there were any other database models besides relational.[citation needed] The relational model and notion of third normal form were the default standard for all data storage. However, prior to the dominance of relational data modeling, from about 1980 to 2005, the hierarchical database model was commonly used. Since 2000 or 2010, many NoSQL models that are non-relational, including documents, triples, key–value stores and graphs are popular. Arguably, geospatial data, temporal data, and text data are also separate models, though indexed, queryable text data is generally termed a "search engine" rather than a database.[citation needed]

The first time the word "multi-model" has been associated to the databases was on May 30, 2012 in Cologne, Germany, during the Luca Garulli's key note "NoSQL Adoption – What’s the Next Step?".[3][4] Luca Garulli envisioned the evolution of the 1st generation NoSQL products into new products with more features able to be used by multiple use cases.

The idea of multi-model databases can be traced back to Object–Relational Data Management Systems (ORDBMS) in the early 1990s and in a more broader scope even to federated and integrated DBMSs in the early 1980s. An ORDBMS system manages different types of data such as relational, object, text and spatial by plugging domain specific data types, functions and index implementations into the DBMS kernels. A multi-model database is most directly a response to the "polyglot persistence" approach of knitting together multiple database products, each handing a different model, to achieve a multi-model capability as described by Martin Fowler.[5] This strategy has two major disadvantages: it leads to a significant increase in operational complexity, and there is no support for maintaining data consistency across the separate data stores, so multi-model databases have begun to fill in this gap.

Multi-model databases are intended to offer the data modeling advantages of polyglot persistence,[5] without its disadvantages. Operational complexity, in particular, is reduced through the use of a single data store.[2]

Benchmarking multi-model databases

[edit]

As more and more platforms are proposed to deal with multi-model data, there are a few works on benchmarking multi-model databases. For instance, Pluciennik,[6] Oliveira,[7] and UniBench[8] reviewed existing multi-model databases and made an evaluation effort towards comparing multi-model databases and other SQL and NoSQL databases respectively. They pointed out that the advantages of multi-model databases over single-model databases are as follows :

  1. they are able to ingest a variety of data formats such as CSV (including Graph, Relational), JSON into storage without any additional efforts.
  2. they can employ a unified query language such as AQL, Orient SQL, SQL/XML, SQL/JSON to retrieve correlated multi-model data, such as graph-JSON-key/value, XML-relational, and JSON-relational in a single platform.
  3. they are able to support multi-model ACID transactions in the stand-alone mode.

Architecture

[edit]

The main difference between the available multi-model databases is related to their architectures. Multi-model databases can support different models either within the engine or via different layers on top of the engine. Some products may provide an engine which supports documents and graphs while others provide layers on top of a key-key store.[9] With a layered architecture, each data model is provided via its own component.

User-defined data models

[edit]

In addition to offering multiple data models in a single data store, some databases allow developers to easily define custom data models. This capability is enabled by ACID transactions with high performance and scalability. In order for a custom data model to support concurrent updates, the database must be able to synchronize updates across multiple keys. ACID transactions, if they are sufficiently performant, allow such synchronization.[10] JSON documents, graphs, and relational tables can all be implemented in a manner that inherits the horizontal scalability and fault-tolerance of the underlying data store.

Theoretical Foundation for Multi-Model Databases

[edit]

The traditional theory of relations is not enough to accurately describe multi-model database systems. Recent research [11] is focused on developing a new theoretical foundation for these systems. Category theory can provide a unified, rigorous language for modeling, integrating, and transforming different data models. By representing multi-model data as sets and their relationships as functions or relations within the Set category, we can create a formal framework to describe, manipulate, and understand various data models and how they interact.


See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Multi-model database

View on Grokipedia
from Grokipedia
A multi-model database is a type of (DBMS) that natively supports multiple models—such as relational, (e.g., or XML), graph, key-value, and spatial—within a single, integrated backend, allowing diverse types to be stored, queried, and managed without requiring separate specialized databases. This approach, often termed , addresses the challenges of handling heterogeneous in modern applications by providing unified administration, security, scalability, and high availability features across all supported models. Key benefits of multi-model databases include simplified and reduced operational complexity, as organizations avoid the overhead of maintaining multiple siloed systems for different formats. They enable efficient querying using a common language or extensions, such as SQL with added support for graph patterns (e.g., MATCH clauses), functions, for XML, and spatial operators, often leveraging and indexing tailored to each model. Notable implementations include AI Database 26ai (as of 2025), which supports via Simple Oracle Document Access (SODA), property graphs with analytics, RDF semantic graphs, and spatial ; Azure SQL, which integrates these capabilities into its relational engine using extensions; and , a multi-model service supporting document, key-value, wide-column, graph, and spatial models. The rise of multi-model databases reflects the evolution of to accommodate , cloud-native applications, and polyglot programming, with benchmarks emerging to evaluate performance across models like , graph, and key-value stores. These systems prioritize optimized storage formats, such as binary JSON representations, and cross-model query capabilities to support complex, real-world workloads in industries like , healthcare, and .

Overview

Definition and Characteristics

A multi-model database is a database management system (DBMS) that natively supports multiple data models—such as relational, , graph, and key-value—within a single, integrated backend, enabling seamless storage, querying, and management of diverse data types without requiring separate systems for each model. This approach allows applications to leverage specialized data structures and access methods tailored to specific needs while maintaining a unified platform for all data operations. Key characteristics of multi-model databases include a unified storage that efficiently manages various data formats and structures in one repository, model-agnostic querying that supports operations across different models via a single interface or , and the elimination of data silos by consolidating heterogeneous data sources. Unlike , which relies on multiple specialized databases leading to increased complexity, integration overhead, and potential inconsistencies, multi-model databases achieve polyglot capabilities within a single , simplifying administration, , and scalability. These databases evolved to overcome the rigidity of traditional single-model systems, such as relational DBMS limited to structured or silos optimized for one but inflexible for others, by enabling hybrid handling that supports the varied workloads of modern applications. This unified flexibility addresses the challenges of diversity in environments without the drawbacks of fragmented architectures.

Historical Development

The concept of multi-model databases emerged in the early , building on innovations in databases to address the growing need for handling diverse data types within a unified system, rather than relying on separate specialized databases. This development responded to the challenges of , a term coined by software architect Martin Fowler in his 2011 bliki post, which described using multiple database technologies tailored to specific application needs to manage varying data storage requirements. One of the pioneering systems, , was first released in 2010 by Luca Garulli, integrating document, graph, key-value, and object-oriented models into a scalable database. The term "multi-model database" itself was formally introduced by Garulli in May 2012 during his keynote at the NoSQL Matters Conference in , , envisioning an evolution of first-generation products to support broader use cases through integrated backends. Between 2014 and 2018, multi-model databases gained traction with key releases that demonstrated practical viability and enterprise appeal. , initially launched as AvocadoDB in 2011 and renamed in 2012, established itself as an open-source option supporting , graph, and key-value models with a focus on query flexibility via its language. Similarly, introduced in 2017 as a globally distributed, multi-model service, evolving from the internal Project Florence started in 2010 to handle large-scale, multi-tenant applications across key-value, , graph, and column-family models. Post-2020, the adoption of multi-model databases accelerated, driven by the demands of cloud-native architectures and AI-driven workloads that require seamless integration of structured, semi-structured, and . Systems like SurrealDB, first released in 2022, have advanced this trend through ongoing developments up to 2025, emphasizing real-time querying, extensibility, and deployment in environments to support distributed AI applications. This growth reflects broader shifts in , including the transition from rigid management systems (RDBMS), which dominated from the 1970s to the , to the scalable but fragmented paradigms of the . The rise of multi-model approaches was further influenced by the explosion, where frameworks like —initially released in April 2006—exposed the "variety" challenge in processing heterogeneous datasets, prompting hybrid designs that unify storage and querying without sacrificing performance. By consolidating models into single engines, these databases mitigated the operational overhead of while adapting to the surge in modern ecosystems.

Supported Data Models

Common Models

Multi-model databases typically support a variety of standard data models to accommodate diverse application needs, including relational, , graph, key-value, column-family, spatial, vector, and time-series structures. These models allow users to store and manage different types of data within a unified system, leveraging each model's strengths for specific use cases such as structured queries, semi-structured storage, or relationship traversals. The organizes data into tabular structures with rows and columns, supporting SQL-like querying, transactions for , and operations like joins to relate multiple tables efficiently. This model is particularly suited for applications requiring strict enforcement and complex analytical queries, as implemented in systems like Azure SQL Database, which extends traditional relational capabilities to multi-model environments. The model stores data as self-contained, semi-structured units in formats like or , offering schema flexibility to handle varying data shapes without rigid predefined structures. It excels in scenarios involving hierarchical or nested data, such as or user profiles, where rapid ingestion and retrieval are prioritized over fixed schemas, as seen in ArangoDB's native document collections. The graph model represents data as nodes, edges, and properties to capture complex relationships and interconnections, enabling efficient traversals and for relationship-heavy datasets like social networks or recommendation engines. This approach facilitates queries that follow paths through connected entities, providing insights into networks that tabular models struggle with, as supported natively in databases like . The spatial model handles geographic and geometric data, supporting queries for location-based analysis, proximity searches, and mapping applications using standards like GeoJSON or Well-Known Text (WKT). It is ideal for use cases in logistics, urban planning, and environmental monitoring, with native support in systems like Oracle Database and ArangoDB. Key-value and column-family models provide foundational storage for high-performance access patterns. The key-value model uses simple pairs for fast lookups and caching, ideal for session data or configuration stores with minimal overhead. Column-family models, akin to wide-column stores, organize data into dynamic columns within rows for scalable handling of sparse, semi-structured information like logs or sensor readings, as exemplified by Azure Cosmos DB's Cassandra API. Emerging support for vector and time-series models addresses modern demands in AI/ML and real-time analytics as of 2025. The vector model stores high-dimensional embeddings for similarity searches and applications, such as semantic retrieval in large language models, integrated in systems like . The time-series model manages timestamped sequential data for temporal analysis, supporting efficient aggregation and forecasting in IoT or financial applications, as provided by SurrealDB.

Extensibility and User-Defined Models

Multi-model databases enhance flexibility by supporting user-defined models, which allow developers to create custom data structures tailored to specific application needs without altering the core system. These models are typically defined through mechanisms such as extensions, where users specify new item types, constraints, and relationships using declarative constructs like the TRIPLE format (<ITEM NAME, ITEM TYPE, ITEM CONSTRAINT>). For instance, custom geospatial models can be built by extending graph-based structures with path filters to handle spatial queries, while event-sourced models leverage document-oriented with matching filters for temporal event tracking. This approach enables the integration of domain-specific semantics while preserving compatibility with built-in models. Extensibility features in multi-model databases further empower customization through plugin architectures, schema-on-read paradigms, and API hooks that facilitate the addition of new models without backend modifications. Plugin architectures permit the registration of characteristic filters or functions that extend query processing for novel data types, ensuring seamless incorporation of specialized logic. Schema-on-read approaches, such as those employing supply-driven inference, dynamically interpret heterogeneous data sources—ranging from relational to graph-based—allowing on-demand extensions of existing schemas with minimal upfront definition. API hooks provide entry points for injecting domain-specific behaviors, such as custom indexing or validation, directly into the query engine. These features collectively support scalable adaptation, as demonstrated by tools that unify schemas across models using record schema descriptions (RSD) to capture integrity constraints and inter-model references. In practice, these capabilities enable multi-model databases to adapt to industry-specific requirements, fostering innovation in dynamic environments. In , extensibility allows the creation of custom models by extending multidimensional cubes with real-time market data feeds, improving OLAP analyses for volatile conditions. For IoT applications, hybrid sensor models can be user-defined to integrate time-series and graph elements, supporting real-time in scenarios like . By 2025, integration of AI in database management has supported advancements in schema evolution and , reducing manual configuration in evolving data ecosystems.

System Architecture

Core Design Principles

Multi-model database systems are engineered around a unified backend that serves as a single, integrated storage layer capable of handling diverse data models such as relational, , graph, and key-value without requiring separate engines or approaches. This design minimizes overhead by sharing core infrastructure services like transactions, recovery, and indexing across models, ensuring data consistency and reducing the complexity of managing multiple disparate systems. By consolidating storage, these systems avoid the procedural integration challenges of traditional polyglot setups, allowing for more efficient resource utilization and simpler administration. To facilitate seamless interaction with varied models, multi-model databases employ layers, often in the form of unified APIs or intermediaries like object-relational mappers, that translate operations between models without exposing underlying complexities to applications. These layers enable declarative access to multiple models through a , supporting transformations such as SQL queries over graph or documents, which enhances developer productivity by abstracting model-specific details. For instance, views and query rewriters act as logical intermediaries, permitting flexible organization independent of physical storage while maintaining model fidelity. Scalability and consistency in multi-model databases involve strategic trade-offs guided by the , where systems prioritize availability and partition tolerance for distributed workloads while often favoring to accommodate diverse model requirements like high-throughput key-value operations alongside ACID-compliant relational transactions. This balance is achieved through tunable consistency models, such as BASE for scalable, fault-tolerant scenarios and stricter guarantees for critical data, enabling horizontal scaling across large, semi-structured datasets without sacrificing overall system reliability. In practice, and adaptive indexing support massive data volumes, ensuring performance under varying loads from common models like graphs and documents. Security and governance are reinforced through unified access controls that apply consistently across all supported models, typically via (RBAC) policies to enforce fine-grained permissions and prevent unauthorized cross-model data exposure. This centralized approach simplifies compliance by providing a single governance framework for auditing, , and policy enforcement, reducing risks associated with fragmented in multi-model environments. For example, attribute-based controls can restrict intra-document access using standards like , ensuring secure handling of hybrid data while maintaining operational efficiency.

Storage and Indexing Mechanisms

Multi-model databases typically employ a unified storage engine to manage diverse data models such as documents, graphs, and key-value pairs, often building on document-oriented structures like trees or extending key-value stores to accommodate relational and graph elements. For instance, systems like utilize , an LSM-tree-based engine optimized for high write throughput, to persist all data models in a single layer, where documents serve as the foundational unit and graph edges are represented as specialized documents linking vertices. In contrast, leverages and hash-based storage for efficient read operations across its multi-model support, including object-oriented extensions for relational-like queries. These engines balance write-heavy workloads with LSM-trees for sequential appends and read-optimized B-trees for point lookups, enabling seamless integration of heterogeneous data without model-specific silos. Indexing strategies in multi-model databases are designed to support queries across models, incorporating composite indexes for relational joins, full-text indexes for document searches, and traversal indexes for graph . Composite indexes, often built on multiple attributes, facilitate efficient relational operations by combining keys from or key-value stores, as seen in ArangoDB's hash and skiplist indexes that span and graph elements. Full-text indexes employ inverted structures to handle semi-structured content, while graph-specific traversal indexes use adjacency lists or edge pointers to enable rapid , with OrientDB's unique traversal mechanism supporting millisecond-level queries regardless of database scale. Adaptive indexing approaches dynamically adjust based on query patterns, selecting model-appropriate structures—such as B-trees for ordered relational access or bloom filters for probabilistic key-value lookups—to optimize across mixed workloads. Data representation in multi-model databases relies on unified serialization formats to store heterogeneous efficiently, often using binary encodings like or to embed diverse models within a common structure. For example, graphs are typically represented via adjacency lists embedded in collections, allowing key-value pairs to serve as node properties and relational tuples to map onto composite keys, as implemented in systems like ArcNeural with its memory-mapped files for vectors and for payloads. evolution tools, such as the MM-evolver proposed in , support propagating changes across models—such as adding attributes to documents or altering graph edges—while maintaining through versioned mappings and categorical transformations. This enables flexible handling of evolving schemas without disruptions, prioritizing extensibility in environments.

Querying and Interfaces

Query Languages

Multi-model databases employ a variety of query languages to handle operations across diverse data models, typically through unified languages that abstract underlying complexities or model-specific subsets routed via a single interface. Unified query languages, such as Query Language (AQL), enable seamless querying of key-value, document, and graph models within a single syntax, supporting declarative operations like traversals and joins without requiring model-specific switches. Similarly, extensions to SQL, including SQL/JSON as standardized in ISO/IEC 9075:2016, allow relational databases like to query documents alongside tabular data using operators like containment (@>) and path expressions, effectively supporting hybrid relational-document models. Model-specific query subsets are often integrated into multi-model systems to leverage specialized paradigms while maintaining a unified access point. For instance, in databases like ArcadeDB, SQL handles relational queries, Cypher supports for property graphs (e.g., MATCH (n:Hero)-[:IsFriendOf]->(m) RETURN n, m), and enables traversal-based graph operations, all executable through a consistent interface such as the system's Java API or web console. These subsets allow developers to apply graph-specific languages like Cypher or for complex relationship queries without abandoning relational SQL for structured data, with the database routing requests internally across models. Advanced features in these languages facilitate cross-model interactions, such as joins between graph edges and documents or aggregation pipelines that summarize data from multiple sources. In , for example, queries can perform graph traversals followed by aggregations like counting connected components across document collections, optimizing for multi-model storage targets. SQL++ variants extend this by incorporating path queries and object-relational mappings for unified aggregations over and relational data. The (GQL), standardized as ISO/IEC 39075:2023, further integrates property graph querying into SQL, enabling multi-model systems to handle graph patterns alongside relational and document data. As of November 2025, interfaces using large language models (LLMs) are an emerging trend in database querying, primarily through tools that translate plain English prompts into SQL (NL2SQL), with growing exploration for broader data models. These tools aim to enable non-experts to query enterprise-scale databases while balancing accuracy and latency, though adoption for cross-model operations across graphs, documents, and vectors remains in early stages.

APIs and Access Methods

Multi-model typically expose standard APIs that enable model-agnostic interactions, allowing developers to perform operations across diverse models without switching interfaces. RESTful APIs are widely adopted for their simplicity and compatibility with web-based applications, providing endpoints for CRUD operations on relational, , graph, and key-value . GraphQL endpoints further enhance flexibility by permitting clients to specify exact requirements, reducing over-fetching in scenarios involving multiple models. Language-specific drivers, such as JDBC extensions for and Python SDKs, support unified access to these models, facilitating seamless integration in polyglot environments. Access protocols in multi-model databases prioritize efficiency and versatility to handle varied workloads. serves as a high-performance protocol for low-latency, bidirectional communication, particularly suited for architectures querying hybrid data structures. WebSockets enable real-time, persistent connections for streaming updates across models, supporting applications like live analytics on graph and document data. patterns allow hybrid queries by virtually unifying multiple backend stores, enabling cross-model joins without data duplication. Integration capabilities extend multi-model databases into broader ecosystems, with connectors facilitating data flow to streaming platforms like Kafka for real-time ingestion and processing of multi-structured events. Compatibility with BI tools via standard ODBC/JDBC drivers supports workflows, allowing unified reporting on relational and non-relational . As of 2025, serverless access models have gained prominence, offering auto-scaling APIs without infrastructure management, as seen in cloud-native implementations that handle variable loads across data models efficiently.

Benefits and Limitations

Advantages

Multi-model databases offer a simplified by integrating multiple data models—such as relational, , graph, and key-value—into a single platform, thereby reducing the need for deploying and maintaining separate specialized databases. This consolidation addresses the challenges of , where applications require diverse data storage solutions, by minimizing integration overhead and lowering operational costs associated with data synchronization and system . In terms of performance efficiency, these databases leverage unified storage layers and optimized indexing strategies to enable faster query execution across different models without the latency introduced by (ETL) processes or data duplication between silos. This approach results in better resource utilization, particularly in distributed and cloud-based environments, where a single instance can handle varied workloads more effectively than fragmented systems. The flexibility of multi-model databases makes them well-suited for modern application development, including architectures that demand varied data access patterns, AI and workflows requiring vector embeddings alongside structured data, and real-time that benefit from seamless querying of operational datasets. By natively supporting these paradigms within one system, developers can iterate more rapidly and adapt to evolving requirements without architectural overhauls.

Challenges and Drawbacks

Multi-model databases introduce significant in , primarily due to the need to handle diverse models within a unified , which often features contradictory characteristics and requires specialized skills for effective administration. This can result in a steeper for developers and administrators, as unified querying across models demands familiarity with multiple paradigms, potentially leading to suboptimal performance akin to a "jack-of-all-trades" approach that underperforms compared to specialized single-model in model-specific workloads. Query optimization across heterogeneous models exacerbates this, as execution plans must accommodate varied access patterns, sometimes degrading performance by up to 65% for operations spanning multiple models. Consistency issues pose another key challenge, particularly in balancing transaction properties across differing models, where relational components may require guarantees while document or graph elements favor , necessitating advanced to avoid inconsistencies in distributed environments. Hybrid consistency models can mitigate this by providing strong guarantees for critical transactions and relaxed ones for others, potentially reducing latency in write-heavy scenarios by 38%, though implementing such strategies adds operational overhead. Additionally, proprietary extensions in multi-model systems can lead to , making migration difficult due to dependencies on vendor-specific features for cross-model integration. As of 2025, multi-model databases exhibit maturity gaps, remaining a relatively emerging field with limited ecosystem support relative to established single-model specialists like relational or databases, which boast more mature tools, libraries, and community resources. This immaturity manifests in challenges for ultra-high-volume scenarios, where unified storage engines may achieve throughput within 12% of specialized systems but struggle with extreme heterogeneity without custom tuning. Despite projected growth at a 19.3% CAGR through 2028, the ecosystem's relative youth limits widespread adoption in mission-critical applications requiring proven long-term reliability.

Notable Implementations

Commercial Systems

Oracle Database is a multi-model relational database management system that supports relational data alongside document (JSON via Simple Oracle Document Access (SODA)), graph (property graphs and RDF semantic graphs), spatial, and key-value models within a single integrated engine. First introduced with multi-model capabilities in version 12c (2013) and enhanced in 19c (2019), the latest version 23ai (as of 2025) adds AI Vector Search for machine learning workloads, enabling unified querying via SQL extensions like JSON functions, graph MATCH clauses, and spatial operators. It provides enterprise-grade features such as ACID transactions, high availability through Real Application Clusters (RAC), and scalability for big data analytics, making it suitable for industries like finance and healthcare requiring secure, compliant data management across diverse models. Microsoft Azure SQL Database extends the with native support for documents, graph queries via , spatial data, and XML through T-SQL, allowing multi-model operations without separate databases. Launched as part of Azure SQL in 2010 and with multi-model features maturing by 2017, it leverages the for cloud scalability, automatic tuning, and integration with Azure services like Synapse Analytics. As of 2025, it supports hyperscale storage up to 100 TB and serverless compute options, ideal for hybrid transactional-analytical processing (HTAP) in applications such as and IoT. Microsoft Azure Cosmos DB is a globally distributed, multi-model database service that supports document, key-value, graph, and column-family data models through multiple APIs, including SQL (Core), , , , and Azure Table Storage. Launched in May 2017, it provides automatic scaling, low-latency guarantees under 10 ms for point reads and writes, and multi-region replication for , making it suitable for enterprise cloud applications such as real-time analytics, personalization, and AI-driven services that require consistent across global data centers. Couchbase Server functions as a distributed multi-model database that integrates document storage with graph capabilities, enabling the modeling of complex relationships using documents and SQL++ (formerly N1QL) queries that support joins, recursive common table expressions for , and transactions. It emphasizes mobile and real-time synchronization through Couchbase Lite and Sync Gateway, allowing seamless data replication between edge devices and cloud environments for offline-first applications. In October 2025, Couchbase released version 8.0, introducing hyperscale vector indexing and search enhancements like the Hybrid Vector Index for billion-scale AI workloads, which supports hybrid queries combining vector similarity with document and graph data. These features position Couchbase for use cases in mobile apps, IoT data syncing, and generative AI applications requiring low-latency access to interconnected data. SingleStore (formerly MemSQL) is a database that provides native multi-model support for relational, , time-series, vector, full-text, and geospatial data within a single engine, using standard SQL queries across all models without needing separate systems. It converges (OLTP) and (OLAP) through its (HTAP) architecture, delivering sub-millisecond query latencies for real-time ingestion and analytics on petabyte-scale datasets. This low-latency unification enables use cases like fraud detection, , and interactive dashboards in enterprise environments, where immediate insights from mixed workloads are critical.

Open-Source Projects

ArangoDB is a prominent open-source multi-model database that natively integrates , graph, and key-value storage models within a single engine, enabling unified querying across data types. Its architecture leverages a flexible storage layer that supports documents for , graph structures for relationship modeling, and key-value pairs for simple lookups, all managed by a distributed cluster design for scalability. The project, initiated in 2014, uses the ArangoDB Query Language (AQL), a declarative SQL-like syntax extended for multi-model operations, allowing complex traversals and joins in one query. Foxx provide a framework for embedding custom logic directly into the database, facilitating serverless-style applications without external . Community contributions have been vital since its 2.0-licensed inception, with active development on including extensions for search and analytics; recent 2025 enhancements integrate the Operator for automated cluster management, deployment, and scaling in containerized environments. OrientDB, now evolved into ArcadeDB following its 2018 acquisition by and subsequent support discontinuation in 2021, represents a key open-source multi-model effort emphasizing graph and paradigms with extensions for other models like key-value and time-series. ArcadeDB's architecture builds on OrientDB's record-based storage but introduces a lighter, faster transactional engine using Alien Technology for multi-model handling, supporting graphs for analytics, documents for flexibility, and vectors for AI workloads in a single backend. It extends standard SQL with graph-specific syntax like OpenCypher for traversals, enabling efficient analytics on large-scale connected data without model silos. Post-acquisition, community forks led by original creator Luca Garulli birthed ArcadeDB as the official continuation under Apache 2.0, fostering contributions in areas like sharding, replication, and plugin development via , with strong emphasis on speeds reaching millions of records per second. SurrealDB, a Rust-based open-source multi-model database, unifies , graph, relational, time-series, geospatial, and key-value models in a scalable, embeddable designed for modern applications. Its core engine supports real-time queries through live subscriptions and event-driven updates, allowing reactive data flows across models without polling. Focused on edge and embedded scenarios, it runs in-process for low-latency operations on devices, with offline-first synchronization and a small footprint suitable for IoT and mobile use. Gaining significant traction since 2023, the project has seen rapid adoption through $6 million in funding, major releases like in 2024, and reported $5 million revenue by 2025, driven by its developer-friendly SQL-like and AI-native features. The community, active on and , contributes to its 2.0-licensed codebase, emphasizing security (RBAC, JWT) and scalability from single-node to distributed clusters.

Evaluation and Benchmarking

Performance Metrics

Performance metrics for multi-model databases evaluate their ability to handle diverse data models and workloads efficiently, focusing on key indicators that reflect operational effectiveness across relational, document, graph, key-value, and increasingly vector-based operations. Throughput, typically measured in (QPS) or (TPS), quantifies the volume of operations a database can process over time, particularly important for mixed s involving operations like graph traversals and relational joins. For instance, in benchmarks simulating scenarios, throughput varies significantly by workload; a New Order transaction spanning multiple models might achieve 230 TPS in one system, while a transaction reaches 738 TPS, highlighting how multi-model integration can optimize or constrain processing rates depending on data access patterns. Latency, the time taken for individual query responses, is assessed in milliseconds or seconds and often scales logarithmically with size, with graph traversals typically incurring higher latency than simple relational joins due to traversal depth and join complexity across models. Scalability metrics examine a database's capacity to expand without proportional degradation, including horizontal scaling efficiency—such as the ability to distribute workloads across nodes—and sharding overhead, which measures the additional computational cost of partitioning . Resource utilization tracks CPU and consumption under mixed workloads, where handling concurrent relational queries, graph , and document retrievals can lead to uneven load distribution if not optimized. In evaluations using scale factors from 1GB to 30GB, multi-model databases demonstrate linear in and query execution on clustered setups, completing large-scale preparation in under on three nodes, though sharding introduces overhead in cross-model queries compared to single-model operations. Consistency and durability metrics ensure reliable data handling in distributed environments, with transaction commit rates indicating the percentage of ACID-compliant operations successfully finalized across models, often exceeding 99% in standalone modes for workloads like order processing that span graphs and relational data. Replication lag, the delay in synchronizing data across replicas, is monitored in milliseconds to balance and freshness, particularly in globally distributed systems where levels can introduce lags under high throughput. In 2025, vector similarity search speed has emerged as a critical metric for AI-integrated multi-model databases, measuring query latency for high-dimensional embeddings; for example, systems can achieve low-latency responses in the tens of milliseconds for searches over millions of vectors while maintaining high recall rates, enabling efficient hybrid workloads combining with traditional models.

Benchmarking Approaches

Benchmarking multi-model databases involves methodologies that evaluate system performance across diverse data models such as relational, , graph, key-value, and increasingly vector representations. Standard benchmarks are often adapted from single-model suites to handle combined workloads, ensuring comprehensive assessment of and . For instance, the Yahoo! Cloud Serving Benchmark (YCSB) is extended for key-value operations within multi-model contexts, while the Linked Data Benchmark Council (LDBC) benchmark supports graph traversals integrated with other models. The Transaction Processing Performance Council Decision Support (TPC-DS) benchmark is similarly adapted for analytic queries involving relational and data, as seen in frameworks that scale real-world datasets to simulate mixed-model . These adaptations emphasize combined workloads to test model conversions and joint operations, such as graph pattern matching alongside relational aggregations. The UniBench framework, for example, draws from YCSB, LDBC, and TPC benchmarks to generate correlated data across models, executing queries that span , graph , and key-value lookups in a unified . Similarly, M2Bench incorporates TPC-DS-inspired analytic tasks across relational, , graph, and models, using domain-specific scenarios like e-commerce recommendations that mix at least two models per task. Such approaches prioritize end-to-end query execution times and under scale factors from 1 to 10, providing a foundation for evaluating multi-model synergies. Recent developments as of 2025, such as VDBBench 1.0, further incorporate AI-augmented techniques for vector operations in real-world simulations. Custom benchmarking approaches often involve workload simulations that blend models in configurable proportions to mimic real-world applications. For example, scenarios might allocate 40% of operations to relational queries, 30% to graph traversals, and the remainder to document or key-value accesses, generated via synthetic tools on platforms like Spark. The MMSBench-Net benchmark employs custom scripts to simulate workloads, integrating relational user , document logs, and graph topologies with adjustable query distributions for parallel execution. Tools like HammerDB, primarily for relational OLTP, can be scripted into hybrid setups for multi-model testing, while bespoke generators handle evolution and model mixing. These methods ensure repeatable tests focused on transaction throughput and query latency, often using choke-point queries to isolate multi-model challenges. In 2025, benchmarking trends incorporate AI-augmented techniques for vector operations, reflecting the integration of embedding-based models in multi-model systems. Tools like VDBBench facilitate real-world simulations with streaming ingestion and concurrent reads/writes on high-dimensional datasets (e.g., 768-1536 dimensions from AI models like V2), measuring P95 latency and recall for retrieval-augmented generation workloads. Fair comparisons across vendors necessitate standardized configurations, particularly distinguishing deployments—offering auto-scaling and pay-as-you-go economics—from on-premise setups with fixed hardware control. Benchmarking studies highlight the need for identical workloads and resource normalization to account for latency variability versus on-premise predictability, ensuring equitable evaluation of and cost-efficiency in multi-model environments. These approaches target metrics such as throughput and resource utilization as core evaluation goals.

Theoretical Underpinnings

Foundational Concepts

The concept of , introduced by Martin Fowler and Pramod Sadalage in 2012, posits that applications benefit from employing multiple specialized technologies to match diverse data requirements, rather than relying solely on relational databases. This approach acknowledges the limitations of a one-size-fits-all model, advocating for key-value stores for simple lookups, document stores for , and graph databases for complex relationships. Multi-model databases represent an evolution of this idea, integrating these varied models into a unified system to reduce integration overhead while preserving the strengths of each . Data model unification in multi-model databases addresses the fragmentation of storage by extending abstract conceptual models, such as the entity-relationship (ER) model, to encompass relational, graph, and structures within a cohesive framework. The traditional ER model, which focuses on entities, attributes, and relationships, can be generalized to represent graph edges as relationships and hierarchies as nested entities, enabling seamless transitions between models. This unification mitigates the object-relational impedance mismatch—a longstanding challenge where the gap between application-level object models and rigid relational schemas leads to inefficient data mapping and query complexities—by allowing native support for multiple representations without custom intermediaries. Formal foundations for multi-model databases draw on to enable schema flexibility, permitting dynamic evolution of data structures while maintaining and consistency across models. provides a rigorous basis for defining polymorphic schemas that accommodate varying degrees of structure, from strictly typed relational tables to schemaless , ensuring that queries and updates preserve semantic integrity. Complementing this, offers conceptual tools for query mapping, treating data models as categories where morphisms represent transformations between relational tuples, graph traversals, and extractions, thus facilitating unified query processing without loss of expressiveness.

Research Directions

Recent research in multi-model databases emphasizes the integration of (AI) and (ML) capabilities to handle diverse data types, including unstructured and vector-based representations. A key focus is on incorporating native vector databases into multi-model architectures, enabling seamless storage and querying of embeddings alongside traditional models like relational and graph data. For instance, the Hybrid Multimodal Graph Index (HMGI) framework proposes a graph-based that combines relational indexing with vector search, using modality-aware partitioning to optimize performance for multimodal data ingestion and retrieval in databases. This approach achieves sub-linear query times and outperforms standalone vector databases in scenarios requiring relational context, addressing the limitations of retrofitting vector support into legacy systems. Advancements in further enhance AI integration by allowing collaborative model training across distributed multi-model datasets without centralizing sensitive information. The FLAMMABLE framework introduces multi-model federated learning (MMFL), where clients dynamically engage multiple models per training round based on their computational resources, adapting batch sizes to mitigate heterogeneity. This results in 1.1–10.0× faster convergence and 1.3–5.4% higher accuracy compared to single-model baselines, facilitating scalable ML over multi-model stores. Complementing this, 2025 studies on hybrid embeddings explore combining textual, visual, and relational embeddings within multi-model environments to support richer semantic queries, as seen in HMGI's adaptive index updates for dynamic multimodal data. Emerging challenges in quantum and are driving innovations in secure multi-model storage. Research highlights the need for quantum-resistant to protect diverse models against future quantum threats, with proposals evaluating lattice-based and hash-based algorithms for database integration. These schemes ensure post-quantum for multi-model systems by applying hybrid cryptographic layers that maintain compatibility with existing query engines while safeguarding vector and graph . In parallel, hybrids address by enabling secure, multi-tenant access across distributed models; the MtDB system leverages for metadata coordination and IPFS for , supporting universal SQL queries with 35ms latency over large-scale records and 1.2–1.3× overhead for integrity enforcement. This architecture promotes in decentralized environments, such as healthcare, without compromising multi-model flexibility. Standardization efforts aim to unify querying and evaluation across multi-model databases, tackling inconsistencies in schema evolution and cross-model operations. Proposals for universal query representations, such as Directed Acyclic Graph-based primitives, provide a model-agnostic framework for multimodal retrieval, extensible to polystore systems via standardized pipelines. Similarly, natural language translation to multi-model query languages (MMQLs) introduces adaptive frameworks that improve accuracy by over 9% through schema embeddings and error correction, fostering a common interface for diverse data models. Academic benchmarks, including SIGMOD 2024–2025 studies, advance consistency testing; for example, the TransforMMer tool simulates data evolution across relational, document, and graph models, generating dynamic benchmarks to evaluate interoperability and performance under schema changes. The Multimodal Attributed Graph Benchmark (MAGB) further assesses consistency in graph-vector hybrids, revealing modality biases and the benefits of balanced embeddings for reliable multi-model learning.

References

  1. https://www.oracle.com/a/tech/docs/multimodel19c-wp.pdf
  2. https://learn.microsoft.com/en-us/azure/azure-sql/multi-model-features?view=azuresql
  3. https://www.cs.purdue.edu/homes/csjgwang/CloudNativeDB/MultiModelCSUR19.pdf
  4. https://www.oracle.com/database/26ai/
  5. https://azure.microsoft.com/en-us/products/cosmos-db/
  6. https://www.cidrdb.org/cidr2017/gongshow/abstracts/cidr2017_20.pdf
  7. https://www.vldb.org/pvldb/vol18/p5335-koupil.pdf
  8. https://www.techtarget.com/searchdatamanagement/definition/multimodel-database
  9. https://www.singlestore.com/blog/what-is-a-multi-model-database/
  10. https://www.progress.com/marklogic/server/features/multi-model-database
  11. https://www.informationweek.com/data-management/unlocking-data-potential-the-advantage-of-multi-model-databases
  12. https://martinfowler.com/bliki/PolyglotPersistence.html
  13. https://db-engines.com/en/system/OrientDB
  14. https://www.chaossearch.io/blog/why-enterprises-need-a-true-multi-model-platform
  15. https://www.devopsschool.com/blog/what-is-arangodb/
  16. https://azure.microsoft.com/en-us/blog/azure-cosmos-db-microsofts-globally-distributed-multi-model-database-service/
  17. https://surrealdb.com/releases
  18. https://www.cockroachlabs.com/blog/history-of-databases-distributed-sql/
  19. https://sachin-s1dn.medium.com/the-evolution-of-apache-hadoop-a-revolutionary-big-data-framework-e3a1d6dbb37a
  20. https://www.rapydo.io/blog/the-rise-of-multi-model-databases-in-modern-architectures-innovation-market-impact-and-organizational-readiness
  21. https://orientdb.dev/docs/3.2.x/datamodeling/Tutorial-Document-and-graph-model.html
  22. https://surrealdb.com/docs/surrealdb/models/time-series
  23. https://arxiv.org/pdf/2011.08724
  24. https://www.sciencedirect.com/science/article/abs/pii/S0169023X23001271
  25. https://journalofbigdata.springeropen.com/articles/10.1186/s40537-022-00645-9
  26. https://www.cs.helsinki.fi/u/jilu/documents/Poly.pdf
  27. https://www.researchgate.net/publication/349426887_Multi-Model_Database_Systems_The_State_of_Affairs
  28. https://www.macrometa.com/topics/multi-model-database
  29. https://www.progress.com/docs/default-source/marklogic-docs/markLogic-10-multi-model-database-datasheet.pdf
  30. https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/security
  31. https://arangodb.com/tag/rocksdb/
  32. https://dl.acm.org/doi/10.1145/3323214
  33. https://arxiv.org/pdf/2506.09467
  34. https://www.sciencedirect.com/science/article/abs/pii/S0169023X21000598
  35. https://epub.uni-regensburg.de/77266/1/A_Generic_Schema_Evolution_Approach_for_NoSQL_and_Relational_Databases.pdf
  36. https://link.springer.com/article/10.1007/s10619-023-07433-1
  37. https://www.postgresql.org/docs/current/datatype-json.html
  38. https://arcadedb.com/
  39. https://www.iso.org/standard/76125.html
  40. https://finance.yahoo.com/news/zilliz-predicts-natural-language-overtake-184800112.html
  41. https://aws.amazon.com/blogs/machine-learning/enterprise-grade-natural-language-to-sql-generation-using-llms-balancing-accuracy-latency-and-scale/
  42. https://hypermode.com/blog/cross-database-queries
  43. https://docs.confluent.io/platform/current/connect/kafka_connectors.html
  44. https://www.geeksforgeeks.org/blogs/top-serverless-databases/
  45. https://slashdot.org/software/multi-model-database/
  46. https://dl.acm.org/doi/10.1145/3555776.3577645
  47. https://aerospike.com/blog/ai-database-landscape/
  48. https://dl.acm.org/doi/10.1145/3548785.3548810
  49. https://www.progress.com/blogs/multi-model-databases-a-modern-approach-to-data-management
  50. https://eajournals.org/ejcsit/wp-content/uploads/sites/21/2025/05/Modernizing-Data-Engineering.pdf
  51. https://www.sciencedirect.com/science/article/pii/S266596382400068X
  52. https://www.oracle.com/database/technologies/appdev/json.html
  53. https://azure.microsoft.com/en-us/blog/dear-documentdb-customers-welcome-to-azure-cosmos-db/
  54. https://azure.microsoft.com/en-us/blog/a-technical-overview-of-azure-cosmos-db/
  55. https://www.couchbase.com/products/server/
  56. https://www.couchbase.com/blog/query-graph-recursive-cte/
  57. https://www.couchbase.com/blog/couchbase-8-hyperscale-ai/
  58. https://www.singlestore.com/
  59. https://www.singlestore.com/solutions/real-time-analytics/
  60. https://docs.arangodb.com/3.12/
  61. https://github.com/arangodb/arangodb
  62. https://arangodb.com/2025/05/deploying-arangodb-on-kubernetes-and-customizing/
  63. https://github.com/ArcadeData/arcadedb
  64. https://docs.arcadedb.com/
  65. https://groups.google.com/g/orient-database/c/iWQbwCCMCgc
  66. https://surrealdb.com/
  67. https://surrealdb.com/solutions/embedded-and-edge
  68. https://techcrunch.com/2023/01/04/surrealdb-raises-6m-startup-funding-database-as-a-service/
  69. https://getlatka.com/companies/surrealdb.com
  70. https://github.com/surrealdb/surrealdb
  71. https://www.cs.helsinki.fi/u/jilu/documents/UniBench.pdf
  72. https://milvus.io/blog/vdbbench-1-0-benchmarking-with-your-real-world-production-workloads.md
  73. https://link.springer.com/article/10.1007/s10619-019-07279-6
  74. https://www.vldb.org/pvldb/vol16/p747-moon.pdf
  75. https://ceur-ws.org/Vol-3714/paper6.pdf
  76. https://www.hammerdb.com/
  77. https://www.researchgate.net/publication/389357072_Evaluating_Cloud-Based_vs_On-Premise_Data_Processing_Tools_A_Benchmarking_Study
  78. https://www.oreilly.com/library/view/nosql-distilled-a/9780133036138/
  79. https://www.sciencedirect.com/science/article/pii/S0306437921001149
  80. https://www.researchgate.net/publication/345349085_Type_theoretical_databases
  81. https://journalofbigdata.springeropen.com/articles/10.1186/s40537-022-00613-3
  82. https://dl.acm.org/doi/10.1145/3477314.3507690
  83. https://arxiv.org/abs/2510.10123
  84. https://arxiv.org/abs/2510.10380
  85. https://dl.acm.org/doi/10.1145/3745812.3745888
  86. https://eprint.iacr.org/2025/2034
  87. https://dl.acm.org/doi/10.1145/3746027.3758155
  88. https://aclanthology.org/2025.acl-long.776
  89. https://www.researchgate.net/publication/395751057_Simulating_Multi-Model_Data_Evolution_for_Benchmarking_Big_Data_Systems
  90. https://dl.acm.org/doi/10.1145/3711896.3737404
Add your contribution
Related Hubs
User Avatar
No comments yet.