What is GraphRAG?

GraphRAG · 7 min read

GraphRAG is retrieval-augmented generation where the retrieval step traverses a knowledge graph. Instead of pulling the top-k most similar text chunks and hoping the answer is in them, the model follows typed relationships between entities — so it can answer questions that span several hops and cite exactly where each fact came from.

RAG, in one paragraph

Retrieval-augmented generation gives a language model facts it wasn't trained on by retrieving relevant context at query time and putting it in the prompt. Classic RAG does this with vector similarity: embed your documents, embed the question, and fetch the chunks whose embeddings are nearest. It's simple, it works for a huge class of questions, and for a lot of applications it's all you need.

Where similarity-only retrieval runs out

Similarity finds text that reads like the question. It struggles when the answer requires connecting facts that don't sit near each other in embedding space: "which suppliers are two hops upstream of the component that just failed," "what did we decide about X and what depends on that decision now." Those are relationship questions, and a bag of independently-retrieved chunks has no relationships in it.

It also can't easily say why it retrieved something. Provenance is a metadata blob attached to a chunk, not a path you can inspect — which matters when an answer has to be auditable.

Represent the knowledge as a graph

GraphRAG models the domain as entities and typed relationships — a knowledge graph. People, documents, systems, decisions, products become nodes; AUTHORED, DEPENDS_ON, MENTIONS, SUPERSEDES become edges. Now the connections the model needs are stored explicitly, and retrieval can follow them.

Retrieval becomes a traversal — bounded and citable

Given an entry point, the retriever walks the neighbourhood: from an entity to the facts about it, to their sources, to what depends on them. The answer set is bounded by the neighbourhood you traverse rather than the size of the whole corpus, which is why graph retrieval stays compact as the knowledge base grows — dumping a 2,000-entity knowledge base into context costs about 202,285 tokens, where traversing to the relevant subgraph costs about 2,668, roughly 98.7% fewer. And because the answer is a path, every fact arrives with its provenance attached.

Retrieve what's known about an entity, with sources, newest firstcypher
MATCH (e:Entity {name: $entity})<-[:ABOUT]-(f:Fact)-[:SOURCED_FROM]->(doc)
RETURN f.statement, doc.title, f.observed_at
ORDER BY f.observed_at DESC
LIMIT 25

Where CognoDB fits — the graph half of the stack

CognoDB is the graph and traversal layer. It doesn't compute embeddings or run vector search — pair it with your existing vector store for that. The common, honest pattern is hybrid: use vectors to find good entry-point entities by semantic similarity, then traverse the CognoDB graph to expand and explain them. CognoDB also ships full-text BM25 search inside the database, so keyword entry points don't need a separate service.

And because CognoDB ships an MCP server, an agent can do the traversal itself: read the schema, write Cypher, and cite the nodes it used — no bespoke retrieval pipeline to build first.

Questions

Common questions.

What is GraphRAG in simple terms?

It's RAG where retrieval traverses a knowledge graph instead of only fetching similar text chunks. That lets the model answer multi-hop questions — ones that require connecting several facts — and return an auditable path showing where each fact came from.

Does GraphRAG replace vector RAG?

No — the mature pattern is hybrid. Vectors are good at finding relevant entry points from unstructured text; the graph is good at expanding and explaining them across relationships. Vector RAG alone is often cheaper and enough; add the graph when questions span multiple hops or need provenance. See our graph RAG vs vector RAG comparison.

Does CognoDB do embeddings or vector search?

No, and we won't imply it does. CognoDB is the graph/traversal layer — keep your vector store for similarity search and let the graph handle structure. CognoDB does include full-text BM25 search for keyword lookups inside the graph.

How do I build the knowledge graph?

Load from where your data already lives — object storage, warehouses, Postgres, Kafka — using MERGE so re-ingestion stays idempotent. Model entities as nodes and the relationships you care about as typed edges; start small and add relationship types as questions demand them.

How does an AI agent query the graph?

Over CognoDB's MCP server. Any MCP-compatible client — Claude, Cursor and others — inspects the schema and runs Cypher against the instance, so the agent traverses and cites the graph directly without an integration layer.

Keep reading

GraphRAG

Graph RAG vs vector RAG

Vector RAG retrieves by similarity; graph RAG retrieves by traversing relationships. A side-by-side comparison, where each wins, and why the 2026 answer is usually a hybrid of the two.

Read

Concepts

What is a graph database?

A graph database stores data as nodes and relationships instead of tables and joins. Here's how the model works, why traversals beat joins for connected data, and when to use one.

Read

Cypher

What is Cypher?

Cypher is a declarative query language for graphs where the query looks like the pattern you're matching. A quick tour of MATCH, MERGE, variable-length paths and full-text search — all runnable on CognoDB.

Read

Start now

~98.7%

token efficiency at 2,000 entities — see the footnotes above

Try the ideas on a real graph.

A free instance takes about a minute and no card. Every Cypher snippet on this page runs against it unchanged.

Start free Read the quickstart

First-graph path

Live

  1. Create a free instance

    No card. Ready in about a minute.

  2. Connect your driver

    bolt+ssc:// URI into the driver you already use.

  3. Write two MERGEs

    That's the entire shape of agent memory.

  4. Point an agent at it

    One MCP config block. No integration code.