Your RAG Stack Doesn’t Need Four Databases

Start with vectors. Add graphs, documents and search when you need them. Never replatform.

Choosing the right database stack for modern software applications and complex retrieval workflows is fraught with commitment risk. For early-stage and Series B startups building AI platforms, requirements evolve rapidly. Most AI projects start the same way: chunk the docs, embed them, drop them in a vector store, ship the demo. Then the real questions arrive. “Which of these parts is overdue for maintenance, and who owns it?” Similarity search can find text that sounds right. It can’t follow a relationship, filter on a date and look up an owner in one step.

So the stack grows. A graph database for relationships. A document store for the records. A key-value cache for lookups. Sync jobs to keep them all honest. Before long you’re maintaining four databases and the glue between them, and that’s before you’ve shipped the feature. This multi-store approach brings severe operational friction, data synchronization challenges, duplication and unnecessary network latency.

Native multimodel databases offer a far better alternative. By consolidating multiple data stores into a single core engine, systems can process complex, multi-paradigm queries without database sprawl.

The polyglot persistence dilemma

Polyglot persistence emerged as software architects realized that a single relational model could not efficiently handle every persistence pattern. A typical modern architecture often deploys:

• Relational databases for structured tabular records.
• Document stores for unstructured or semi-structured JSON objects.
• Key-value stores for high-speed hash lookups.
• Graph databases for traversing highly linked relationships.

While each system excels at its specific task, combining them into a single solution creates a fragile “system of systems.” Engineers must build and maintain Byzantine orchestration pipelines to keep data synchronized across stores. Operational overhead multiplies with every added technology, requiring specialized skill sets and adding significant latency as queries jump across network boundaries.

Database approach	Systems required	Query language	Operational friction	Synchronization
Multi-store polyglot	Multiple specialized databases	Multiple distinct APIs	High (frequent upgrades, complex deployment)	External ETL and orchestration pipelines
Layered multimodel	One database with add-on models	Varies; limited interop	Moderate	Internal abstraction mapping
Native multimodel	One core engine	One unified language	Low (single engine, unified skills)	Native co-location in one store

What defines a native multimodel database?

A true native multimodel database has one core storage engine, one unified query language, but multiple coexisting data models, including document, key-value, graph and vector search capabilities.

This distinction excludes “layered” multimodel databases that place facades over a single primary model or force systems to switch modes. In a native multimodel database, key-value pairs, JSON documents and property graphs exist as first-class citizens side by side:

• Documents are also key-value pairs. Every JSON document has a unique _key, so a document collection works as a key-value store with no extra setup.
• Graphs are built from documents. Vertices are stored as JSON documents, and edges are stored in edge collections whose _from and _to attributes link the starting and ending vertices. No separate graph engine to sync.
• One query runs across models. A single declarative query language can perform document filtering, graph traversals and key-value joins inside a single execution path.
• Vectors sit next to the data they describe. Embeddings are just attributes on your documents, indexed with a vector index built on the Faiss library, so high-dimensional embeddings live alongside documents and graphs and provide semantic retrieval without an isolated vector database.

Case study: navigating complex hierarchies

To see the practical advantage of native multimodel querying, consider an aircraft fleet maintenance domain. Managing an aircraft fleet means tracking millions of components arranged in deep hierarchical structures (partonomies) spanning as-designed, as-built and as-maintained configurations.

To answer critical operational questions, a data store must perform three distinct query types.

1. Graph traversals (navigational queries)

• Question: What are all the constituent parts of a specific engine assembly?
• Query pattern: Starting at a component vertex, the query navigates down through child nodes along edge relationships.
• Execution: Outbound graph traversals over named graphs, without manually joining tables.

2. Filters on properties (document queries)

• Question: Which parts across the entire fleet require maintenance before a specific date?
• Query pattern: Independent of the graph structure, this query relies on secondary indexes on specific document properties (for example, nextMaintenance).
• Execution: Runs directly against document collections using secondary index lookups rather than full collection scans.

3. Combined multimodel queries (the multimodel payoff)

• Question: Which parts need maintenance next week, what is their maintainable parent component, and who is the technical point of contact?
• Query pattern: Combines document filtering, recursive upward graph traversal and key-value hash joins.

In a multi-store pipeline, this query means fetching overdue parts from a document store, querying a graph database to find parent components, and querying a relational or key-value store for contact information.

In a native multimodel database, it runs as a single declarative block:

FOR p IN parts
  FILTER p.nextMaintenance <= "2026-10-15"
  FOR c IN 0..4 INBOUND p GRAPH "FleetGraph"
    FILTER c.isMaintainable == true
    LIMIT 1
    FOR person IN contacts
      FILTER person._key == c.contact
      RETURN { part: p._id, component: c, contact: person }

This single query combines secondary index document filtering, upward graph traversal and primary key hash join lookups without data leaving the database engine.

4. Now add RAG (vectors plus graph)

Your technicians want to ask the maintenance manuals questions. Embed the manual chunks, add a vector index, and link each chunk to the parts it describes with a describes edge. Now retrieval can find the right passages and tell you which of those parts are overdue.

FOR chunk IN manualChunks
  SORT APPROX_NEAR_COSINE(chunk.embedding, @questionVector) DESC
  LIMIT 5
  LET overdue = (
    FOR part IN 1..1 OUTBOUND chunk describes
      FILTER part.nextMaintenance <= @cutoff
      RETURN part._key
  )
  RETURN { text: chunk.text, source: chunk.source, overdueParts: overdue }

Vector search finds the passages, the graph connects them to real parts, and the document filter adds today’s maintenance status. That’s context a vector-only store can’t give your LLM.

Architectural benefits of going multimodel

Consolidating storage paradigms into a native multimodel database brings distinct architectural advantages:

• No orchestration layer. Unified transactional consistency replaces external sync jobs and ETL pipelines.
• Start lean, grow without replatforming. Begin with vector search, then add graph relationships, document filters or full-text search on the same data as requirements change.
• Consistent writes. ArangoDB transactions are ACID on single servers and OneShard deployments, so a document and its edges update together. (In multi-shard clusters, multi-document transactions are not guaranteed to commit atomically, so design accordingly.)
• Performance without compromise. Dedicated document and graph capabilities inside a unified engine match the efficiency of specialized single-model engines.
• Room for future requirements. Expanding from vector search into graph traversal or document search within the same core engine future-proofs the architecture for fast-growing startups, with no rip-and-replace migrations.
• A broad solution space. It fits a wide range of enterprise workloads, including real-time recommendations, enterprise knowledge graphs, fraud detection, logistics, network topology and IoT hierarchy management.
• Room to scale. Clusters shard data horizontally, and SmartGraphs keep connected data together to cut network hops during traversals.
• One skill set. Your team learns one query language instead of four APIs.

Instead of assembling four different databases to handle key-value, document, graph and relational queries, modern architectures can rely on a native multimodel foundation for high performance, operational simplicity and maximum modeling flexibility.

ArangoDB: one engine for every model

ArangoDB is a primary example of this approach, natively integrating documents, key-value pairs, property graphs and vector indexing into a single core engine. Many AI projects start with vector search for similarity retrieval, and ArangoDB supports native vector search out of the box, so teams can start lean and layer on graph relationships or document filtering as requirements grow, avoiding the polyglot persistence dilemma entirely.

With a unified query language (AQL) and transactional guarantees across models, ArangoDB delivers low operational complexity, unified governance and low-latency performance. It eliminates database sprawl while keeping query flexibility, for early-stage startups and global enterprises alike.

Try it yourself

Grab the free ArangoDB Community Edition and run the queries above. Vector indexes need the --vector-index startup option, so add it before you create your first one.

Want the graph built for you? The free Developer Edition of the Arango Contextual Data Platform adds AutoGraph Studio, which turns your documents into a context graph automatically, with no schema to design and no extraction pipeline to write.