The multi-model database provides an elegant solution to the challenge of heterogeneous data. This new class of database naturally supports multiple data models in their organic form within a single, integrated backend, and uses data and query standards appropriate to each model.

Integrated Indexes

Integrated data requires integrated indexes. Typically, you have to choose which indexes get created for each data type. On the other hand, a true multi-model database has an integrated suite of indexes that allow fast data access immediately after data is loaded. A multi-model database works more like Google—Google doesn’t require web pages to fit a certain format, it just indexes them. With a multi-model database, users can quickly search data across all data models with a single, composable query.

Composable Queries

Queries are extended or combined to provide seamless query across all the supported data models. Indexing, parsing, and processing standards appropriate to the data model are included in the core database product.

Unified Platform

You get a unified platform that reduces the footprint for backup and recovery, development and testing, and search. You also get to maintain one security model.

Data Modeling Flexibility

You get the flexibility and power to choose the right model for your data. For example, with a document and triple store combined, you can use JSON for objects (e.g., customer, stock trade), XML for text (e.g., blog post, news article), and RDF triples for facts and relationships.

Shared Nothing Architecture

A distributed computing architecture in which each node is independent and self-sufficient, and there is neither a single point of contention across the system, nor a single point of failure. More specifically, none of the nodes share memory or disk storage.

A Multi-Model Scenario

In the illustration, you see a document describing a person: Jen, and some triples that describe facts and relationships about Jen. And, if you wanted to represent Jen in a relational view, you can do that too. In MarkLogic, this data would be stored as documents, but it’s easy to create a relational view on top of documents for the purposes of querying with SQL.

Diagram Product Multi Model Scenario

Data Types Supported by MarkLogic


Ideal for structured data that is stored as objects

  • Schema-agnostic
  • Query with JavaScript
  • Compact and fast to parse
  • Six kinds of values: objects, arrays, floats, string, booleans, nulls
  • Avoids namespaces, comments and attributes
  • Common data format for the web


Ideal for structured and unstructured data or text

  • Schema-agnostic
  • Query with XQuery
  • Can store objects, sets, and many data types such as dates, durations, integers and more
  • Uses namespaces (for embedding object types), comments and attributes (for adding metadata)
  • More maturity than JSON as a data model


Ideal for facts and relationships

  • Define entities and relationships
  • Atomic structure (cannot be broken down further)
  • Uses universal standard for data and querying (RDF and SPARQL)
  • Used for reference data, metadata, provenance


Ideal for systems of data, text and relationships

  • Documents can contain triples
  • Triples can annotate documents
  • Graphs of triples can contain documents
  • Enhanced Querying:
    • Expand a document search using graphs
    • Enhance graph search by linking to documents
    • Restrict document search using triples metadata

A Multi-Model Database Helps with Data Integration

The best way to manage entities and relationships is with a multi-model database that combines the benefits of a document store and triple store. Documents are for entities. RDF triples are for relationships. This approach is proven to be faster and more effective than using a relational model (or using a document-only or triples-only approach). Want to get a deeper understanding of how to succeed at data integration by managing entities and relationships in your data?

Product Feature Data Hub Framework

Don't be Fooled by Multi-Model Imposters

You should be alert to multi-model imposters, as many vendors are falsely advertising multi-model databases when in fact they are just multi-tools bolted together without a unified storage or query layer.

True multi-model databases require the ability to store multiple types of data in the same system with unified data governance, management and access. A “multi-query” database is not comparable. If you’re storing it, you must be able to search it. The database should handle all the different data models, and index them so you can run combination queries of text, SPARQL, XQuery, etc. against them — composability of search is crucial.

MarkLogic is a Multi-Model Leader

A multi-model database combines the benefits of two databases into one (e.g., document database and graph database, or Semantics) and provides a unified query interface. MarkLogic is a leading multi-model database that uses this approach, and it has been proven to be very effective for integrating data from silos. Customers are able to get the flexibility of a document model for their core data, while storing their metadata using RDF triples. This not only helps with integrating data faster and easier, it also improves data governance.

Integrate Your Data With a Multi-Model Database

Are Multi-Model Databases the New Normal?

Decimate Data Silos With a Multi-Model Database

Related Resources

Traditional data modeling is inadequate. Organizations are constrained by relational technology and they need a better approach to data modeling, to integrate data faster and build smarter applications: a multi-model approach using NoSQL and semantics.
Damon Feldman looks at two paths of multi-model database engineering: a single platform that allows many models on one core, versus complex integrations where many systems are pre-packaged. Which is better for you?
This talk will lay out the most important reasons to simplify your architecture and discuss how to find the best balance between simplicity and functionality.

Feature-Rich and Built for the Enterprise

This website uses cookies.

By continuing to use this website you are giving consent to cookies being used in accordance with the MarkLogic Privacy Statement.