Graph RAG does not need a graph database. It needs a database that does everything.

Author: Matthew Penaroza How SurrealDB compares to Neo4j, Amazon Neptune, and ArangoDB for production graph RAG. Graph RAG is the right idea. Using relationships between entities to scope and improve retrieval produces better results than vector similarity alone. The research is clear on this. What the research does not address is where those operations execute, and that turns out to be the question that actually matters in production. Here is what happens when you try to build production graph RAG across a typical multi-database stack, and what changes when every operation composes in a single system. The gap: what graph RAG actually needs in production Most graph RAG implementations follow the pattern from Microsoft's GraphRAG paper: extract entities from documents, build a knowledge graph of those entities and their relationships, then traverse that graph at query time to pull relevant context. The graph is derived from the content. It is an inferred structure that helps you find do