A multi-model database is a database that handles multiple data types, like vectors, graphs, documents, relational data, and more – in a single, converged engine.
Multi-model databases are most valuable when multiple data types are closely related and must be queried transactionally. When working with real-world, multi-model data, I’ve found this to often be the case.
Over time, systems grow in complexity
To help illustrate the utility of a multi-model database, let’s consider a fairly typical scenario:
Your engineering team builds and deploys a new service architecture around a NoSQL database like DynamoDB or similar. The initial deployment goes well, and NoSQL meets the initial requirements neatly.
Later on, a customer request requires you to add vector search capabilities, so your team bootstraps a vector database. All is well.
Then, user traffic picks up and you add a cache (such as Memcached or Redis). This new system is integrated into the stack.
As the system evolves, new capabilities continue to be added. Real-time event-streaming (through something like Apache Kafka) enables async order processing. Location-aware capabilities pull in a spatial database. Your team spins up and manages more and more disjoint data platforms.
If not managed, complexity leads to inefficiencies
Without careful planning and tight engineering controls, a few types of problems arise:
- Data duplication: For example, NoSQL data is copied to a graph or vector database, complicating the source of truth or risking “stale data”.
- Network overhead: To complete a task, clients must make network calls to different databases, joining the data in the app-tier. The additional network round-trips add latency and network costs.
- Hybrid queries are complex: Queries that join multiple types of data (e.g., vector + graph) must query two databases, and then be joined at the app-tier. This is usually custom logic.
- Transactions aren’t easy: It’s challenging to implement transactions over disjoint systems. Atomic, transactional work will require some sort of distributed transaction implementation, which is often heavy weight and complex.
- Experts for every system: Each data platform has different requirements for day-to-day operations, backups, upgrades, and failover. Even with managed systems, someone must own and maintain that component.
Multi-model databases simplify and add value
Data de-duplication
Data lives in one engine, with one unified database platform. Vectors, text, spatial data, JSON, and more can live side by side as columns in the same schema. For data that lives in the same system duplication is no longer a problem, and data is automatically synchronized. Extract-transform-load (ETL) workloads can be dramatically reduced, or even eliminated.
One query, one round-trip: simple hybrid search
If you need to query vectors (similarity search) and text (lexical search), you can do this in one query statement. For example, a query that filters on vector distance and text CONTAINS may include both predicates in a single statement. When the query is executed, the results are returned to the client in one round-trip.
Transactional boundaries
Because data lives in one engine, the transactional boundary can encompass all your data. If I’m modifying JSON data and related graph edges, I can encapsulate this in a single, atomic transaction at the database server level.
Contrast this with a multi-database architecture: if a JSON update succeeds but a graph update fails, I must implement compensating transactions, retries, reconciliation jobs, or other error correction logic.
One system, less operational overhead
When one multi-model database handles your application’s data needs, you can reduce the operational overhead for your team. I don’t need to maintain, upgrade, backup, and manage separate databases for JSON, vectors, graphs, and more – I only need to manage one data platform.
Scaling
One common argument against multi-model databases is that single-purpose databases can be easier to scale for specific workloads. Serverless databases, for example, often make it simple and efficient to add read/write capacity as demand increases. However, scaling each database independently requires separate autoscaling policies, capacity planning, and budget management across the stack. For bursty or elastic workloads, that flexibility may still be worth the additional operational complexity.
Modern multi-model databases can support a wide range of workloads through horizontal and vertical scaling. Oracle’s Globally Distributed Database supports deployment across multiple regions, while its Maximum Availability Architecture (MAA) provides guidance for building highly available and resilient systems. Together, they illustrate how a unified database platform can scale globally while maintaining strong fault-tolerance and availability characteristics.
When I’d use a multi-model database
I’d use a multi-model database when an application needs several related data models and those models must work together. For example, an application may need relational records, JSON documents, vector embeddings, full-text search, or graph relationships over the same underlying data.
A multi-model database is especially useful when hybrid queries, transactional consistency, and low-latency access across data types are important. Keeping related data in one platform can reduce duplication and simplify application logic, while still supporting specialized ways to query that data.
Leave a Reply