GraphRAG, vector RAG, and agentic RAG solve different problems—here's how to combine them without over-migrating.
RushDB
Push any JSON. Get graph relationships and vector search instantly — no schema, no pipeline, no setup.
Start building free →FAQ
Ask five AI engineers whether GraphRAG replaces vector search and you'll get five different opinions, often shaped by whichever migration they just finished. The framing that has taken hold in a lot of conference talks and blog posts treats retrieval-augmented generation as a ladder: plain RAG, then GraphRAG, then Agentic RAG, each one a strict upgrade over the last. That framing does not hold up against how these systems actually work. Vector search, graph traversal, and agentic orchestration answer different questions, and official documentation from the two ecosystems most associated with GraphRAG — Neo4j and LlamaIndex — frames graph retrieval as a complement to vector search, not a replacement for it Neo4j GraphRAG documentation LlamaIndex documentation. The practical question for an AI engineering team is not which paradigm to standardize on, but which retrieval path a given query actually needs, and how much orchestration complexity that path is worth.
Treat the three paradigms as answers to three different questions instead of three rungs on a ladder.
Vector RAG answers: what is semantically similar to this text? An embedding model turns a query into a vector, and a similarity index returns the nearest neighbors. It does not know that two similar-looking support tickets were filed by the same team, or that one document supersedes another — that context has to live in metadata fields attached to each vector, if it is captured at all.
GraphRAG answers: what is connected to this entity, and how? Instead of ranking by distance in embedding space, a graph engine walks explicit relationships — issue to project, contributor to team, document to author — and returns the connected structure. Neo4j's own GraphRAG documentation recommends combining vector search with graph retrieval rather than treating graph traversal as a wholesale replacement for other retrieval methods Neo4j GraphRAG documentation. LlamaIndex's materials similarly describe graph and vector retrieval as complementary building blocks within the same pipeline rather than competing pipelines LlamaIndex documentation.
Agentic RAG answers a different kind of question: what sequence of retrieval and reasoning steps actually answers this multi-part request? An agent might call a vector search for a fuzzy sub-question, then a graph traversal for a relational one, then reconcile both answers. Agentic RAG is an orchestration layer, not a retrieval mechanism in its own right — it is only as good as the retrieval tools it is allowed to call.
None of this is a benchmark claim. No controlled study in the sources gathered for this article measured GraphRAG's latency or token cost against vector-only retrieval on the same dataset, and none measured how often a pure vector-only pipeline fails a genuinely multi-hop query. What the documentation does support is the shape of the trade-off:
| Retrieval mode | Core question it answers | Latency shape | Token/compute footprint | Native multi-hop context |
|---|---|---|---|---|
| Vector RAG | What is semantically similar to this text? | Fast — one embedding call plus a similarity scan | Lowest of the three | Not native; reconstructed from metadata if captured |
| GraphRAG | What is connected to this entity, and how? | Grows with hop count and fan-out | Scales with traversal depth and result summarization | Native — relationships are walked directly |
| Agentic RAG | What sequence of steps answers this request? | Highest — chains multiple retrieval and model calls | Highest — every intermediate step adds model tokens | Depends entirely on which tools the agent calls |
Because vector similarity search ranks embeddings independently of the relationships between the underlying entities, a vector-only retrieval layer is architecturally unlikely to resolve queries that depend on connected, multi-hop context — though no benchmark in the sources collected here measured that gap directly, so treat it as an architectural inference rather than a measured result.
A hybrid architecture routes a query to whichever retrieval path fits it, instead of forcing every request through one heavy engine. A lightweight semantic router — the same idea behind libraries like Semantic Router — can classify an incoming query as similarity-shaped ('find tickets like this one') or relationship-shaped ('who owns every open ticket connected to this project') before any expensive call happens.
Both paths can terminate in the same storage layer if that layer supports both access patterns natively. This is the specific niche RushDB occupies: a context layer that applications and agents can query for either similarity or connections without maintaining two separate databases, including through its vector and graph search capabilities. According to RushDB's own architecture documentation, RushDB implements a Labeled Meta Property Graph (LMPG) model on top of Neo4j, using Neo4j as the underlying storage and transaction engine while elevating properties into first-class HyperProperty structures rather than plain key-value pairs. That vendor-documented design is why the same client can issue a similarity query and a relationship query against the same records — Neo4j provides the underlying labeled property graph storage and transaction engine, while RushDB's LMPG model layer adds HyperProperty structure on top of it. It is worth being precise about what that does and does not establish: it describes RushDB's product architecture as documented by RushDB, not an independent benchmark of query performance, and it says nothing about whether a given application actually needs graph traversal at all.
In practice, a hybrid query against RushDB looks like two SDK calls chained together: a similarity search to find candidate records, followed by a relationship lookup to pull in whatever is connected to the top candidates. The JavaScript SDK exposes vector similarity search directly through db.records.vectorSearch, which narrows candidates by label and an optional where filter before ranking by similarity RushDB JavaScript SDK TypeDoc — RestAPI / ai / vector search / raw query RushDB JavaScript SDK TypeDoc — VectorSearchParams. The same client surface also exposes relationship-oriented operations — db.records.attach, db.records.detach, and db.relationships.find — so graph-style retrieval and mutation live in one SDK rather than a separate client RushDB JavaScript SDK TypeDoc — Model attach method. RushDB's AI schema helpers also surface vector-index metadata directly: a property's schema entry can include a vectorIndexes array, and a non-empty array means that property is queryable with vectorSearch RushDB JavaScript SDK TypeDoc — RushDB / Transaction / Model.
The following pattern is illustrative rather than a captured trace from a live project — it shows the documented call shape, not a specific dataset's output.
# Python
from rushdb import RushDB
db = RushDB("RUSHDB_API_KEY")
candidates = db.records.vector_search({
"labels": ["DOCUMENT"],
"propertyName": "content",
"query": "checkout timeout troubleshooting",
"limit": 5,
})
top = candidates.data[0]
related = db.relationships.find({
"source": {"labels": ["DOCUMENT"]},
"target": {"labels": ["AUTHOR"]},
"limit": 10,
})
for edge in related.data:
if edge["sourceId"] == top.id:
print(edge["sourceId"], edge["type"], edge["targetId"])
relationships.find returns edges rather than records: each entry carries sourceId, targetId, a relationship type, and direction, so the application code above is deciding which edges belong to the top vector match rather than asking the database to do a combined similarity-plus-traversal query in one call. That distinction matters — RushDB unifies both access patterns in one client, but the orchestration between them still happens in application code, not inside a single native hybrid query.
Schema discovery is the part of this that can actually be demonstrated end to end, because it doesn't depend on an embedding model or an index configuration — it only requires a nested JSON import. Consider a support-tracking project imported as one PROJECT record with nested ISSUE and CONTRIBUTOR arrays:
{
"PROJECT": {
"name": "Atlas Support",
"repository": "atlas-api",
"ISSUE": [
{
"title": "Checkout timeout",
"status": "open",
"priority": "high",
"ownerTeam": "backend"
},
{
"title": "Update empty state",
"status": "open",
"priority": "low",
"ownerTeam": "frontend"
}
],
"CONTRIBUTOR": [
{
"name": "Mina",
"team": "backend"
},
{
"name": "Noah",
"team": "frontend"
}
]
}
}Importing that payload gives RushDB enough structure to infer the graph automatically, without a separate schema-definition step. Calling the schema endpoint returns the inferred labels, per-label properties, and cross-label traversal directions as structured JSON:
schema = db.ai.get_schema({})
print(json.dumps(schema.data, indent=2))
The relationships in that response — PROJECT to ISSUE, PROJECT to CONTRIBUTOR — are exactly the graph-traversal side of a hybrid query: they exist because records were nested at import time, not because a separate join was configured after the fact. That discovered schema can then ground a structured filter instead of a free-text prompt. Querying ISSUE records for status open and priority high returns the one record the schema predicts:
{
"data": [
{
"__label": "ISSUE",
"ownerTeam": "backend",
"priority": "high",
"status": "open",
"title": "Checkout timeout"
}
],
"total": 1
}That one-record result is a small example, but it demonstrates the mechanism plainly: the fields available to filter on (status, priority, ownerTeam) came directly from the inferred schema, and the structured query used them without any manual mapping step. Note that schema responses like this are served from a schema cache that refreshes roughly once an hour rather than being recalculated on every call, so a schema read immediately after a large write may briefly lag the underlying graph.
Captured from a run against an isolated RushDB project in Python and TypeScript; volatile record identifiers are normalized.
Use the discovered fields in a structured query
{
"data": [
{
"__label": "ISSUE",
"ownerTeam": "backend",
"priority": "high",
"status": "open",
"title": "Checkout timeout"
}
],
"searchQuery": {
"labels": [
"ISSUE"
],
"limit": 10,
"where": {
"priority": "high",
"status": "open"
}
},
"total": 1
}For a team deciding how to architect retrieval, the practical takeaway is to profile query shapes before picking an engine. If most production queries are single-hop similarity lookups — find documents like this one — a vector-only path is probably still the cheapest and fastest option, and adding a graph layer would add traversal cost the workload doesn't need. If a meaningful share of queries are relational — who owns every open issue connected to this project — a similarity index alone will not resolve them without reconstructing the relationship in application logic first, since vector similarity ranks embeddings independently of any relationship between the underlying entities.
Most real applications sit in between, which is why a routing layer that can dispatch to either path is worth the added complexity more often than a wholesale migration to one paradigm is. RushDB's role in that architecture is narrow and specific: it is a context layer that agents, applications, and analytics workloads can query for both similarity and connected structure through one SDK, not a general-purpose warehouse or a drop-in replacement for every vector store or every graph database a team might already run. Migrating an entire retrieval stack to GraphRAG because a demo looked impressive is exactly the mistake this framing is meant to prevent — the better first step is measuring which of the two questions, similarity or connection, the failing queries are actually asking.
The operational boundary that most affects local prototyping is that RushDB's raw query endpoint, db.query.raw, is cloud-only in the JavaScript SDK: it does not work for self-hosted or local-only deployments RushDB JavaScript SDK TypeDoc — RestAPI / ai / vector search / raw query RushDB JavaScript SDK TypeDoc — Transaction. The Python SDK documents the same boundary from the other side — db.records.vector_search performs similarity search over indexed properties, but db.query.raw is available only for managed RushDB Cloud projects or custom databases connected through RushDB Cloud RushDB Python SDK README and contract notes. A team prototyping entirely against a self-hosted instance cannot fall back to a raw Cypher escape hatch for a query shape the structured SDK methods don't cover; the documented SDK surface — vectorSearch/vector_search, relationships.find, records.find — is what's actually available offline, and the sources gathered here don't establish whether every complex hybrid workflow can be expressed that way without raw queries.
The comparison table above is a characterization of documented design intent, not a benchmark: no source collected for this article measured GraphRAG's latency or token cost against direct vector search on identical data, and none measured PostgreSQL's pgvector plus recursive CTEs against Neo4j-backed traversal for two- or three-hop queries. Anyone using that table to justify an architecture decision should treat it as a starting hypothesis to test against their own workload, not a settled result. Finally, the vendor description of RushDB's LMPG model running on Neo4j comes from RushDB's own architecture documentation rather than an independent audit, so it should be read as a description of intended design rather than a third-party-verified performance claim.
The evolutionary framing — RAG, then GraphRAG, then Agentic RAG — makes for a tidy narrative, but it doesn't match what the underlying documentation actually recommends or what the SDK surfaces actually do. Vector search, graph traversal, and agentic orchestration are three tools that answer three different questions, and the right architecture usually uses more than one of them, routed by query shape rather than by whichever paradigm is newest. Whether that hybrid layer is built on RushDB, on Neo4j directly, or on a combination of pgvector and a separate graph store, the discipline is the same: measure what a query actually needs before adding the cost of traversal or agentic orchestration to answer it.