Not everything you need can be reached through connections. Not everything you need can be preserved as a semantic vector. And not every question deserves an agent loop. The sweet spot is one application that can use the right retrieval mode for each part of the problem.
Ask five AI engineers whether GraphRAG replaces vector RAG and you will get five different answers, usually shaped by whichever system they built most recently.
The common story is a maturity ladder:
Diagram
It implies a simple progression: start with embeddings, graduate to graphs, then graduate again to agents.
That is the wrong mental model.
Vector RAG, GraphRAG, and Agentic RAG are not three generations competing for the same job. They preserve and recover different kinds of context.
Vector RAG is strongest when relevance is semantic: what means something similar to this?
GraphRAG is strongest when relevance is relational: what is connected to this, and how?
Agentic RAG is strongest when retrieval itself must be planned: which operations do I need, in what order, to answer this?
Each has a blind spot. A graph cannot traverse a relationship that does not exist. A vector cannot guarantee that ownership, causality, provenance, sequence, or identity survived the embedding. An agent adds latency, cost, nondeterminism, and more ways to fail.
So the practical goal is not to find a winner. It is to build an application where the retrieval mode follows the information need.
That is exactly the boundary RushDB draws in one API surface. Its Semantic Search (db.records.vectorSearch) handles meaning-based retrieval over an indexed property. Its Smart Search (db.ai.search) turns a natural-language request into an inspectable, schema-aware SearchQuery for structured and relational retrieval. Its normal records search handles exact filters, aggregations, and graph traversal. None pretends to solve the others' problem.
The useful comparison is not RAG < GraphRAG < Agentic RAG. It is:
Diagram
The sweet spot is a shared context layer with multiple retrieval modes:
use vector retrieval for fuzzy semantic recall;
use graph retrieval when the answer depends on identity, ownership, dependency, provenance, or hierarchy;
combine semantic ranking and graph scope when the query needs both;
use agentic orchestration only when the sequence of retrieval steps cannot be determined cheaply in advance.
Do not force topology into embeddings, and do not force fuzzy meaning into topology. Preserve both representations when your application needs both.
The architectural test for any system is whether it can do this over the same records — whether the vector path and the relational path observe the same data, labels, relationships, and permissions. RushDB keeps those paths on one data model and one Labeled Meta Property Graph, so an application can pick a retrieval mode per query without ever being forced to standardize on a single paradigm.
Vector retrieval, graph retrieval, and agentic orchestration do not optimize the same thing. Vector RAG compresses content into an embedding space where semantic proximity is queryable. GraphRAG preserves explicit entities and relationships so topology is queryable. Agentic RAG gives a model control over retrieval operations so a plan can be adapted as evidence arrives. None strictly contains the other two.
The ecosystem is converging on a more realistic architecture: one application, several retrieval operators, selected or composed according to query shape. Microsoft's GraphRAG still exposes vector search alongside local, global, and DRIFT modes;1 Neo4j's GraphRAG tooling exposes vector, text-to-Cypher, hybrid, and tool-selecting retrievers.2 That is not a compromise between competing paradigms. It is the natural consequence of applications containing different kinds of information.
RushDB takes this to its logical endpoint: rather than bolting several stores together and synchronizing them, it exposes the vector, relational, and natural-language-planning paths over one graph data model. You still select the retrieval operator per query — but all operators read the same records, schema, and permissions, removing a whole class of drift and ACL bugs.
Graphs are powerful only where meaningful structure exists. “Find postmortems that describe failures similar to a cascading timeout” has no SIMILAR_TO edge to traverse:
Diagram
Their similarity exists in language and meaning — a vector question, not a graph traversal. In RushDB terms, this is Semantic Search over an indexed property.
“Which team owns the service affected by INC-204, and which deployment immediately preceded it?” depends on explicit facts:
Diagram
You can serialize these facts and embed them, but nearest-neighbor similarity does not guarantee preservation of relationship semantics, direction, identity, or temporal ordering. The information may be present in the corpus while still awkward to query as a relationship. Here the correct primitive is structured retrieval: an exact SearchQuery, or Smart Search if the user expresses the request in natural language.
An exact-ID ownership lookup is cheaper and more predictable as a deterministic graph query than as an LLM plan. A semantic-similarity question needs one vector search. Agentic RAG earns its complexity only when the retrieval plan itself is dynamic.
Vector RAG turns query and content into embeddings and ranks stored vectors by similarity. This is powerful because human questions rarely use the same vocabulary as the source: “How do we stop customers from getting charged twice?” maps to “Duplicate payment capture caused by retry behavior after gateway timeout.”
Vector retrieval is especially strong when the answer is concentrated in one or a few passages, the user's wording differs from the source, and there are no reliable explicit relationships. That describes much documentation search and knowledge-base retrieval.
But embeddings do not magically preserve relational truth. Two nearly identical tickets can belong to different projects and owners; their embeddings may be almost identical, yet “Who owns the checkout timeout affecting Atlas?” is answered by a chain of identity and relationships, not by vector distance.
Embeddings encode similarity. They do not guarantee preservation of explicit topology.
At least four distinct architectures hide under the label:
Pattern A — graph-enriched local retrieval. Retrieve something semantically, then expand into connected context (provenance, neighbors, dependencies). Microsoft's local search and RushDB's GraphRAG tutorial both follow this shape: vector-seed for relevant chunks, then traverse HAS_CHUNK/COVERS-style relationships to enrich context.
Pattern B — graph-native structured retrieval. The user asks a relational question directly:
Diagram
There is no reason to run vector search. In RushDB this maps to a structured SearchQuery via db.records.find, or to Smart Search when the request is in natural language.
Pattern C — graph-generated corpus summaries. Microsoft's GraphRAG extracts an entity graph, runs community detection, and pre-generates community summaries so global search can reason at corpus level — useful for “what are the major recurring themes?”-style questions, and a structurally different evaluation class than local retrieval.34
Pattern D — graph-guided search over operational data. The graph already exists because the application data is relational (ACCOUNT → SUBSCRIPTION → INVOICE, SERVICE → DEPENDS_ON → SERVICE). Retrieval is less about document search and more about preserving state, provenance, and causality across an agent's world. This is precisely the class RushDB is built for: nested JSON becomes connected records on import,5 so an agent's world model is already a graph rather than a pile of denormalized chunks.
Restrict candidates with exact constraints, then rank by similarity. This is frequently the best production pattern because it couples relevance with correctness boundaries such as tenancy, permissions, dates, and lifecycle state.
Diagram
RushDB's records.vectorSearch() implements this natively: labels and a where clause narrow the candidate set before similarity ranking, and where supports relationship traversal. Because where runs as a graph filter first, a highly selective filter makes semantic search faster — fewer records are ranked, not just more correct.6
results = db.records.vector_search({
"labels": ["INCIDENT"],
"propertyName": "description",
"query": "authentication failures after a gateway change",
"where": {
"customerTier": "enterprise",
"country": "Germany",
"createdAt": {"$gte": "2025-07-01"}
},
"limit": 10
})
for incident in results.data:
print(incident.score, incident.data)
Use vector retrieval to find semantic entry points, then traverse outward to collect context that should not be embedded into every chunk. This is ideal when relevance is fuzzy but context is relational, and it is the pattern behind RushDB's GraphRAG tutorial as well as Neo4j's VectorCypherRetriever and LlamaIndex's VectorContextRetriever.27
Sometimes you know where in the graph the answer must live, but not which text inside that neighborhood is relevant. Define the relational scope first, then rank semantically only inside it:
Diagram
This is stronger than vector search plus metadata when scope depends on relationships that change over time, and safer for authorization-sensitive systems: the candidate universe is structurally bounded before semantic relevance is considered. In RushDB it is a relationship traversal inside the where of one vectorSearch call:
results = db.records.vector_search({
"labels": ["NOTE"],
"propertyName": "body",
"query": "migration risk during the move to the new platform",
"where": {
"PROJECT": {
"$relation": {"type": "BELONGS_TO", "direction": "out"},
"status": "active",
"ACCOUNT": {
"$relation": {"type": "OWNS", "direction": "in"},
"name": "Acme"
}
}
},
"limit": 10
})
That is the difference between “hybrid retrieval” and “vector search plus an application-side join.”
Run multiple retrievers independently and merge the results (reciprocal-rank fusion or a learned reranker). Useful when no single retriever dominates, but it executes several paths per query — a good fit when recall matters more than latency, a poor default otherwise. Because RushDB exposes all paths through one client, fusion needs no separate vector, graph, and keyword services.
Agentic RAG turns retrieval strategies into tools and gives a model control over which tools to call.
That is useful when the sequence of steps genuinely cannot be known in advance. But every agentic step carries a tax: another model decision, another round trip, more tokens, another place for tool arguments to be wrong.
Do not use an agent to decide something a deterministic router can decide reliably.
The bigger architectural win for most systems is classifying query shape before retrieval. A useful router distinguishes exact lookups, filtered lookups, semantic similarity, relational, hybrid, and multi-step shapes — and a simple deterministic router is enough:
def route(query: str, has_ui_filters: bool, has_exact_id: bool, asks_relationships: bool, needs_semantics: bool, needs_multistep: bool) -> str:
if has_exact_id:
return "structured"
if has_ui_filters and not needs_semantics:
return "structured"
if asks_relationships:
return "hybrid" if needs_semantics else "graph"
if needs_multistep:
return "agentic"
return "vector"
This is also where a schema-aware Smart Search fits: instead of handing an agent free rein over arbitrary database operations, RushDB constrains natural-language requests to a bounded, inspectable SearchQuery that runs through the normal records path. You get planning where it helps without unbounded tool access.
Indexing cost. A graph extracted from unstructured text requires entity extraction, entity resolution, relationship extraction, and optional community summarization — far more expensive than vector indexing.8 LazyGraphRAG explores deferring that cost, but the numbers are implementation-specific, not universal.9 When the source data is already structured (JSON, CSV, a database export), you can model the graph directly: RushDB's JSON import decomposes nested payloads into typed records and creates parent-child relationships during ingestion,5 collapsing most graph-construction cost for operational data.
Query compute. A vector query is one embedding plus ANN. A graph query is seed identification plus traversal plus filter plus ranking. Global and agentic queries multiply the LLM work.
Context-window cost. Retrieval cost is not only database work. An uncontrolled graph expansion turns 5 seeds into ~1,000 candidate facts; the LLM should not receive all of them. GraphRAG needs context budgeting — hop limits, relationship allowlists, per-relation caps, deduplication, reranking, token-budget-aware assembly — just as vector RAG needs top-k tuning.
Operational complexity. The hidden cost of hybrid stacks is running a vector database, a graph database, indexing pipelines, synchronization jobs, separate ACL logic, and duplicate deletion paths. The fewer places the vector view and the relational view can disagree, the cheaper the system is to operate — the operational argument for one data model over multiple retrieval operators.10
Freshness. GraphRAG demos assume the graph is correct; production must keep it correct. If ownership is duplicated into dozens of chunks and embeddings, those chunks go stale when the service changes owner. If ownership is a first-class relationship, update it once:
Diagram
Separate semantic evidence (embeddings) from operational truth (explicit records and relationships), and resolve mutable facts — permissions, incident state, account status, active contracts, policy versions — at query time. This is why RushDB's hybrid retrieval keeps where as a graph filter executed at query time: tenancy and ownership come from the current graph state, not stale embeddings.6
Graph quality. A bad graph makes retrieval worse: duplicated entities fragment traversals, generic RELATED_TO edges preserve little queryable meaning, and overconnected neighborhoods stop being selective. Graph construction needs discipline — stable identity, typed relationships, direction, provenance, and explicit separation of observed vs inferred edges. RushDB's relationship-suggestion flow keeps inferred patterns reviewable before approval rather than silently materializing them as truth.11
RushDB is relevant here precisely because its thesis does not require every query to become GraphRAG. It puts structured records, relationships, live schema metadata, and semantic indexes behind one data model and API surface, so one application can choose different retrieval paths over the same context. The value is not “graph beats vector”; it is avoiding separate, drifting representations when the application genuinely needs both.
RushDB's Labeled Meta Property Graph (LMPG) represents property definitions as first-class metadata in the graph, exposing labels, property names, inferred types, value domains, relationship structure, and vector-index metadata as runtime schema.10 Query planning is much safer when the model can inspect the actual schema — and application code can discover facets at runtime:
properties = db.properties.find({})
facet = next(prop for prop in properties["data"] if prop["name"] == "importance")
values = db.properties.values(facet["id"])
print(json.dumps(values["data"], indent=2))
That same runtime schema grounds Smart Search in a real vocabulary — labels, properties, relationships, and semantic indexes from the project, not a static prompt template.
Smart Search translates natural language into an inspectable SearchQuery, executes it through the normal records path, and returns the records plus the generated query and warnings. The LLM does not invent arbitrary operations; it produces a constrained query you can inspect, validate, and refine. The docs are explicit: Smart Search is for schema-aware structured, relational, and filtered retrieval — not a substitute for similarity ranking.
The same application uses db.ai.search when structure or relationships matter and db.records.vectorSearch when meaning matters:
# Relational / structured intent: let RushDB plan against the live schema.
relational = db.ai.search(
"Find active enterprise customers connected to overdue invoices"
)
print(relational.search_query)
print(relational.warnings)
for record in relational:
print(record.data)
# Semantic intent: rank a known indexed property by meaning.
semantic = db.records.vector_search({
"labels": ["NOTE"],
"propertyName": "body",
"query": "customer may cancel because onboarding is going badly",
"limit": 10
})
for record in semantic.data:
print(record.score, record.data)
That is the article's core point implemented literally: the natural-language interface does not force every request through the same retrieval mechanism.
Smart Search also lets natural language refine an existing query object via current_query/currentQuery, turning the generated SearchQuery into conversational query-builder state rather than replacing it with an opaque prose-only plan:
initial = db.ai.search("Find active enterprise customers created last quarter")
refined = db.ai.search(
"Only show records from Germany",
current_query=initial.search_query
)
print(refined.search_query)
print(refined.warnings)
Raw Cypher remains an escape hatch for projects on a user-owned Neo4j instance,12 but for agent-facing workloads the safer default is the constrained, inspectable query surface.
A support model with CUSTOMER → PROJECT → INCIDENT → SERVICE → TEAM, plus RUNBOOK and DEPLOYMENT, does not need one universal retrieval endpoint. One search experience can route by intent:
Diagram
“Find incidents like this one.” Vector search over INCIDENT.description — no traversal needed.
“Find incidents like this one for Acme.” Acme's structural scope as a prefilter, then semantic ranking: structure defines eligibility; embeddings rank meaning inside the eligible set.
“Who owns the service affected by INC-204?” Skip vectors. A deterministic SearchQuery — or Smart Search for a natural-language UI — answers directly; adding similarity would not make it more correct.
“What runbook should we use for incidents similar to INC-204?” Get INC-204 → vector-search similar incidents → traverse INCIDENT → SERVICE → RUNBOOK → rank/dedupe runbooks.
“What failure patterns recur across all incidents this quarter?” A corpus-level problem: aggregate structured categories, cluster embeddings, or use global/community summaries, depending on whether the patterns exist as explicit data or must be inferred from text.
Evaluate fairly. A misleading benchmark evaluates every retriever on the same undifferentiated question set. Label queries by information need (semantic-local, exact/structured, relational single/multi-hop, hybrid, global) and report per query class, not just overall. Measure retrieval (Recall@k, MRR/nDCG, path recall), answers (correctness, attribution, unsupported-claim rate), the system (latency, LLM calls, tokens, stale-answer rate), and operational complexity (number of stores, sync pipelines, ACL implementations).13
Run an ablation, not a migration. Compare vector-only, vector+filter, vector→graph-expansion, direct-graph, routed hybrid, and agentic hybrid against your query distribution. You may discover vector-only remains best for 60% of traffic, graph traversal improves 20%, hybrid matters for 15%, and only 5% genuinely needs agentic planning. If so, forcing every query through the most expensive pipeline is a regression.
Migrate incrementally. Classify failures (semantic miss vs wrong scope vs missing relationship vs global vs multi-step vs stale source), improve vector retrieval first, model only the relationships that matter, add graph scoping (a where relationship constraint inside vectorSearch — no new infrastructure, because RushDB data is already relational on import),5 add graph expansion, add routing, and only then add agentic orchestration where needed.
The architecture I would default to is a shared context layer with multiple retrieval modes:
Diagram
The point is not that every request is hybrid. It is that the same application can be vector-only for one query, graph-only for another, and genuinely hybrid for a third. The design principle:
preserve semantic information where semantic retrieval is useful;
preserve explicit relationships where correctness depends on structure;
keep hard filters and permissions deterministic;
route simple queries directly;
compose retrieval modes only when the query genuinely crosses information types;
use an agent only when the sequence cannot be predetermined reliably.
Underneath this is the reason hybrid retrieval exists: applications contain at least two irreducible information spaces.
Diagram
Embedding space excels at the left side; graph structure at the right. Neither is a lossless encoding of the other. Agentic orchestration becomes useful when a task must cross between them — coordination across capabilities, not replacement of them.
The goal is not the most sophisticated retrieval pipeline. It is the least complicated pipeline that still preserves the evidence needed for the answer.
an unknown or changing sequence of retrieval steps
Agentic RAG
And remember the two failure conditions that make a single-paradigm architecture brittle:
Not everything is reachable through connections.
Not everything can be preserved as a semantic vector.
The strongest system is not the one that pushes everything into a graph, everything into vectors, or everything through an agent. It is the one that refuses to destroy useful information just to standardize on one retrieval paradigm — and that is the architectural role RushDB occupies: a shared context layer where structured data, relationships, semantic retrieval, and agent-driven querying coexist over the same records. Semantic Search handles meaning; Smart Search plans schema-aware natural-language queries; Hybrid Retrieval combines structural constraints with semantic ranking; and GraphRAG shows the multi-stage vector-seed → graph-expansion pattern.