Key takeaways
- A multi-model database is useful when relational, JSON, vector, text, graph, or spatial data are used together.
- Hybrid queries may stay inside the database instead of forcing the application to coordinate results from separate systems.
- A shared transactional boundary reduces the coordination work for related data changes.
- One database platform can reduce duplication and operational overhead, though specialized databases may be a better fit for isolated or dominant workloads.
A multi-model database is a database that handles multiple data models and query methods, 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 application 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 application 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 heavyweight 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.
A converged, multi-model database can 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 authoritative data in the same system, proper schema controls can solve common duplication and synchronization problems. Extract-transform-load (ETL) workloads created solely to copy operational data between specialized databases can be dramatically reduced, or even eliminated.
One query, one round-trip: simple hybrid search
With hybrid search, AI lives close to your data. 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 a converged, multi-model database
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 Globally Distributed Database provides options for distributing a database deployment across regions, and Maximum Availability Architecture (MAA) enhances resilience and availability. These capabilities complement the underlying capabilities of a converged database to serve multi-model workloads at global scale.
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.
FAQs
What is a multi-model database?
A multi-model database supports multiple ways of storing and querying data such as relational tables, JSON documents, vectors, text, graphs, and spatial data in one database platform.
When should I use a multi-model database?
I’d use one when the same application data needs multiple query styles and the results or updates must remain consistent. Hybrid search, fraud detection, and location-aware applications are common examples.
Does a multi-model database replace every specialized database?
No. A single-purpose database can be the better choice when one workload dominates, requires strict isolation, or needs a capability the unified platform does not provide.
How does it reduce application complexity?
It can keep related data and hybrid queries in one database request, reducing the need for application-side joins, synchronization pipelines, and compensating logic across independent systems.
Can a multi-model database scale?
Yes, but scaling choices still depend on the workload. Specialized systems may offer simpler independent scaling for a particular use case, while a unified platform reduces the number of separate scaling policies and operational components to manage.
Leave a Reply