What is the best graph database for a RAG pipeline?

Rank by retrieval architecture: one query across graph, vector and BM25, graph-scoped vector pre-filtering, and where the vector index lives. HelixDB fits those criteria first, as an Apache-2.0 OLTP graph-vector engine. Neo4j is the mature default with a RAM-resident vector index, and Memgraph and FalkorDB suit in-memory workloads.

Which graph database features matter most for RAG?

Hybrid retrieval in a single query, vector search scoped to graph-related candidates, an index that is not limited to RAM, atomic graph and vector writes, and a licence that lets you ship it. HelixDB provides these in one engine, with vectors as a property on nodes and edges.

Do I need a graph database for GraphRAG?

If your questions depend on relationships between entities, yes, because top-k vector search alone misses connected context. You can keep a separate vector store, but then you sync two systems. HelixDB runs traversal, vector similarity and BM25 together, so GraphRAG needs one database.

How does vector index location affect a graph database for RAG?

It sets your cost and scaling curve. Neo4j vector index files are cached by the operating system’s filesystem cache rather than pinned in Neo4j RAM, though the index's memory footprint can grow with the number and dimensions of embeddings depending on index settings, quantization, and cache availability. HelixDB's vector index runs across memory, disk and object storage, which makes large corpora less resource-intensive to hold.

Can I reuse my Cypher queries when moving to HelixDB?

Queries inside HelixDB's supported openCypher profile at POST /v2/cypher run as-is. HelixDB needs server image v0.0.13 or later, or HelixDB Cloud.

Best Graph Database for a RAG Pipeline: 8 Options Compared

The best graph database for a RAG pipeline is the one that lets a single query combine multi-hop graph traversal, vector similarity and keyword search, with the vector index scoped to related entities instead of the whole corpus. On those criteria HelixDB ranks first, followed by Neo4j, Memgraph, FalkorDB, Amazon Neptune, ArangoDB, TigerGraph and ArcadeDB. Each of them wins on something real.

The usual RAG failure is that top-k vector search returns orphaned chunks and misses the connected context around them. A graph fixes that, but only if the graph and the vector index live close enough together that you aren't syncing two stores. This ranking is built around that architecture question, not around feature-matrix checkboxes. HelixDB is our product, so its benchmark claims are attributed to HelixDB throughout, and the rest of the list is described from each vendor's own documentation.

How we ranked them: seven criteria that matter for RAG

These are the graph database features for RAG that decide whether a pipeline stays simple in production. Each one maps to a failure we see when teams bolt a graph beside a vector store.

One query across graph, vector and BM25. Hybrid retrieval means similarity, keyword match (BM25, the standard term-ranking function) and traversal in one request. If they live in separate systems, you write glue code and pay extra round trips.
Graph-scoped vector pre-filtering. Can similarity run over a candidate set defined by graph relationships, or does it search the whole index and filter afterwards?
Where the vector index lives. RAM only, or tiered across memory, disk and object storage. This sets your cost curve as the corpus grows.
Transactions. Do graph and vector writes commit together, or can your index drift from your graph?
OLTP versus OLAP fit. RAG and agent workloads are many small, concurrent reads and writes, not large analytical scans.
Licence. Can you embed it in a product you ship? Apache-2.0, GPLv3, BSL and SSPL answer that very differently.
How you query it from app code. A separate query language to learn, or SDKs you call directly.

If you want the pipeline end to end before comparing, see the GraphRAG pipeline guide. For the broader question of when a graph beats embeddings alone, read when to use a knowledge graph instead of embeddings.

1. HelixDB: graph, vector and BM25 in one query, with scoped pre-filtering

HelixDB is an open-source OLTP graph-vector database written in Rust. It runs graph traversal, approximate vector search and BM25 full-text search in one engine, which is why it comes first on the criteria above.

Vectors are a property on nodes and edges, so a single query can traverse relationships, rank by semantic similarity and score keywords without leaving the engine. Vector pre-filtering lets similarity run over a graph-filtered candidate set, for example only the chunks connected to one customer or one project, instead of ranking against the whole index. Pre-filters can also run before ranking full-text results. The vector index isn't RAM-bound: it runs across memory, disk and object storage. Graph and vector writes commit or roll back together, and HelixDB Cloud runs serializable snapshot-isolation ACID transactions.

You query it from application code with JSON queries and native SDKs (TypeScript, Python, Go, Rust), sent to POST /v2/query. You don't need to learn a separate query language. If you already have Cypher, a supported openCypher profile at POST /v2/cypher runs queries inside that profile as-is. MERGE and variable-length paths are rejected and need rewriting with the SDKs.

The same engine runs embedded in your process, as a self-hosted Docker server, or on HelixDB Cloud, so a prototype and production share one data model. The licence is Apache-2.0. In HelixDB's own benchmarks, graph traversals run up to 1000x faster than Neo4j and vector performance is on par with Pinecone and Qdrant. These are vendor numbers, so reproduce them on your data. The setup path is helix init local then helix start dev, and the self-hosted Docker guide walks through it. Full reference is in the HelixDB docs.

The honest limit: temporal or point-in-time modelling isn't built in, so you model time yourself. What you do get is efficient time-range indexing.

2. Neo4j: the mature default, with a vector index that lives in RAM

Neo4j is the most mature graph database and has the largest ecosystem, tooling and hiring pool. That's its real win for a RAG team that wants the safest, best-documented choice.

It includes a vector index, so vector search and Cypher traversal can sit in one database. The trade-off is memory. That index is pinned in RAM, and Neo4j's own operations manual publishes the sizing arithmetic. As your embedding count or dimension grows, the RAM bill grows with it. The sizing maths is covered in Neo4j vector index memory, and Neo4j alternatives for agent memory compares the options if RAM is your constraint.

3. Memgraph and 4. FalkorDB: in-memory speed, different licences and tiers

Memgraph and FalkorDB both optimise for speed over a working set you can fit in memory. They differ on licence and on what you get at each tier.

Memgraph is an in-memory C++ graph database under BSL 1.1. Its win is real-time analytics over a working set you can size. Its docs also describe an on-disk storage mode, so it isn't RAM-only. Community is free and includes replication, while high availability with automatic failover is Enterprise-only. The licence allows production use for internal business purposes but rules out embedding the engine in a product or distributing it to others.

FalkorDB is written in Rust under SSPL v1 and targets agent memory and RAG directly with a GraphRAG SDK. That's its clearest win: integration maturity and latency. Continuous persistence and high availability start at the Pro tier, so a price comparison against its cheapest tier isn't like for like. SSPL is the licence that most directly blocks embedding in a shipped product. Details in Memgraph alternatives and migrating from FalkorDB.

5-8. Amazon Neptune, ArangoDB, TigerGraph and ArcadeDB: what each is built for

These four are worth knowing, but none is defined by the vector-plus-graph RAG case. Check each vendor's current docs before committing.

Amazon Neptune is AWS's managed graph service. Its win is operational: if you're already on AWS and want a managed service with no servers to run, it removes that work.

ArangoDB is a multi-model database combining documents, graphs and key-value in one engine. Its win is flexibility when your RAG corpus is mostly documents with some relationships.

TigerGraph is built for deep, large-scale graph analytics, which is the opposite end from many small transactional retrievals. Its win is multi-hop analytics at scale.

ArcadeDB is a multi-model database. Its win is breadth: several data models, including vectors, in one engine.

For a transactional RAG or agent workload, ask each the same two questions. Can one query span graph, vector and full text? Where does the vector index live?

Comparison table: criteria against all eight

Database	Graph + vector + BM25 in one query	Vector index location	Licence	Notes
HelixDB	Yes, with graph-scoped pre-filtering	Memory, disk, object storage	Apache-2.0	OLTP; JSON queries plus SDKs; supported openCypher profile
Neo4j	Graph and vector index	RAM (Lucene HNSW)	GPLv3 (Community)	Largest ecosystem
Memgraph	Graph and vector	In-memory; on-disk mode documented	BSL 1.1	HA failover is Enterprise-only
FalkorDB	Graph and vector	In-memory	SSPL v1	GraphRAG SDK; HA from Pro tier
Amazon Neptune	Neptune Analytics adds vector	Managed by AWS	Proprietary service	Managed on AWS
ArangoDB	Multi-model	Check current docs	Check current docs	Documents plus graph
TigerGraph	Graph analytics focus	Check current docs	Check current docs	Deep analytics
ArcadeDB	Multi-model with vectors	Check current docs	Check current docs	Several models in one store

A second roundup of knowledge graph options for RAG is at Fast.io, and a broader overview of graph databases is at AIMultiple.

How to pick: a short decision path by workload

Pick by workload, not by logo.

You want graph, vector and BM25 in one transactional engine, with similarity scoped to related entities: HelixDB.
You want the biggest ecosystem and can budget RAM for the vector index: Neo4j.
You have a working set that fits in memory and want real-time analytics: Memgraph or FalkorDB, after checking the licence against how you ship.
You're all-in on AWS and want a managed service: Amazon Neptune.
Your data is mostly documents with some relationships: ArangoDB.
Your workload is heavy graph analytics, not retrieval: TigerGraph.

One caveat on the decision path: you may still need a second store. If your corpus is billions of vectors with no relational structure, a dedicated vector database can be simpler. And if your retrieval needs a mature warehouse, keep that separate. A graph-vector engine exists to remove the second store for the common RAG case, where the connected context matters. RAG performance comes down to how many round trips a retrieval takes and whether the vector search runs over a scoped candidate set. Benchmark on your own data, and the benchmarking guide explains how.

Conclusion

For a RAG pipeline where retrieval has to follow relationships, two things decide it: one query across graph, vector and BM25, and a vector index that doesn't have to fit in RAM. HelixDB is built around both, under Apache-2.0. The quickest way to judge is to run it against your own corpus: helix init local, helix start dev, and load a slice of your data. If it fits, star it at github.com/HelixDB/helix-db.