Graph databases: Neo4j vs Memgraph vs FalkorDB vs TigerGraph

1. Executive summary

The first question is not "which graph database" — it is "do I need a graph database, or a graph?" For a bounded corpus — a few hundred to a few thousand documents, a fixed knowledge base — the graph fits in memory and rebuilds deterministically from source, and a build-time static graph beats operating a database. I have written that up in detail, and it is the honest default for the small case. The four engines here earn their operational cost when the graph is large, mutable, queried interactively, or all three.

Neo4j is the default I measure the others against, and its scores say why: the deepest graph-algorithm library (GDS), the most mature ecosystem and drivers, the strongest first-party GraphRAG tooling, and enterprise governance. Cypher — now converging on the ISO GQL standard — is the lingua franca of the space, and its native vector index makes it a single store for graph plus embeddings. Its soft spots are horizontal write scale and cost.

Memgraph is the answer when the workload is real-time: in-memory, Cypher-compatible, streaming-first with native Kafka/Pulsar ingestion and dynamic algorithms that update as the graph changes. You buy sub-millisecond reads on the hot set and pay for it by sizing to RAM. FalkorDB takes a different route to speed — it represents the graph as sparse matrices and runs traversals as linear algebra (GraphBLAS), which makes multi-hop reads exceptionally fast and, with an in-graph vector index, makes it a purpose-built GraphRAG engine for teams that already run Redis. TigerGraph is the one built for genuine scale: a distributed, massively-parallel engine for billion-edge deep-link analytics, addressed in GSQL rather than Cypher — more power and a steeper, less transferable skill.

2. Positioning

These four are usually lined up as "Neo4j and the alternatives," which hides the fact that three of them are shaped for a specific workload the incumbent is merely good at.

The pattern is that Neo4j is the generalist and each of the other three is a specialist that beats it on one axis and trails it on ecosystem. Memgraph wins real-time, FalkorDB wins traversal latency and compactness, TigerGraph wins scale — and all three ask you to give up some of Neo4j's tooling maturity, its algorithm breadth, or, in TigerGraph's case, the transferable skill of Cypher.

What these scores are not is a throughput leaderboard. Vendor benchmarks on this page each show their sponsor winning, and the neutral open benchmarks move with workload shape. What decides a real graph selection is query-language skill on the team, how the graph is written and updated, whether it needs to be distributed, and how much of the algorithm and GraphRAG ecosystem you would otherwise rebuild. Those are the axes below.

3. Radar criteria — the reasoning

Query language & ergonomics

Neo4j 4.6 — Cypher is the de facto standard and is converging on ISO GQL, so the skill transfers and the tooling assumes it. Memgraph 4.4 and FalkorDB 4.2 are Cypher-compatible, which is most of that benefit with minor dialect gaps. TigerGraph 3.4 — GSQL is powerful (accumulators, genuine procedural control) but proprietary and a scarcer, less portable skill; it is the axis where the scale winner pays.

Traversal performance

FalkorDB 4.7 — running traversals as sparse-matrix multiplication (GraphBLAS) makes multi-hop reads its headline strength; vendor and independent runs put it ahead on 2- and 3-hop queries. Memgraph 4.6, in-memory with sub-millisecond hot-set reads. TigerGraph 4.3, fast at scale through parallelism. Neo4j 4.0 — perfectly good, and the one most likely to need index and query tuning on deep traversals.

Write & ingestion

Memgraph 4.4 — in-memory writes and first-class streaming ingestion. TigerGraph 4.2, strong bulk loading built for large initial loads. FalkorDB 4.0. Neo4j 3.9 — solid, with heavy write bursts and large transactions the thing to size and test.

Scale & distribution

TigerGraph 4.7 — the reason to choose it: distributed and sharded from the start, built to hold and traverse billion-edge graphs that do not fit one machine. Neo4j 3.4 and FalkorDB 3.4 scale through clustering and Redis respectively but are happiest when the working set fits a node. Memgraph 3.2 — the honest floor, bounded by RAM on a single primary.

Graph analytics & algorithms

Neo4j 4.7 — the Graph Data Science library is the broadest, best-documented algorithm suite anywhere (centrality, community, pathfinding, embeddings, ML pipelines). TigerGraph 4.4, deep-link analytics and a strong algorithm library. Memgraph 4.0 (MAGE, plus dynamic algorithms that react to change). FalkorDB 3.6 — fast primitives, a narrower algorithm catalogue than GDS.

Real-time / streaming

Memgraph 4.7 — this is its whole design: native Kafka/Pulsar/RedPanda consumers and dynamic algorithms that update incrementally as edges arrive, rather than a full recompute. FalkorDB 4.2, low-latency and Redis-native. Neo4j 3.6 and TigerGraph 3.6 — both ingest streams, neither is streaming-first, and TigerGraph leans batch-analytical.

GraphRAG / GenAI fit

Neo4j 4.6 — the most complete story: a native vector index alongside the graph and a maintained first-party GraphRAG package with entity extraction and hybrid retrievers. FalkorDB 4.5 — built for this: an in-graph vector index and sub-5ms structural retrieval, positioned squarely at AI agents. Memgraph 4.0, a single-store vector index and a GraphRAG flow in 3.x. TigerGraph 3.6 — vector and CoPilot exist, less mature than the others.

Operations & ecosystem

Neo4j 4.6 — the most mature by a distance: Aura managed service, Bloom and Browser, drivers in every language, the largest community and hiring pool. Memgraph 3.6 and FalkorDB 3.6 — capable tooling, smaller ecosystems (FalkorDB benefits when Redis is already operated). TigerGraph 3.2 — the heaviest to run, a distributed system with the operational surface that implies.

Governance & security

Neo4j 4.5 — fine-grained RBAC, role and property-level security, SSO, audit; the enterprise story is mature. TigerGraph 4.2, enterprise RBAC and multi-graph isolation. Memgraph 3.6 and FalkorDB 3.4 — real access control, less of the fine-grained enterprise depth (FalkorDB inherits Redis ACLs).

TCO / cost & licensing

FalkorDB 4.2 — compact (matrix representation), efficient, open-source, cheap where Redis is already running. Memgraph 3.8, open-core, with RAM as the real cost lever. TigerGraph 3.4, commercial with heavy infrastructure. Neo4j 3.2 — the lowest here: GPL Community with meaningful limits, Enterprise licensing that scales with the deployment, and a page-cache appetite for memory. Cost is the axis the incumbent loses.

4. Radar scorecard

How these scores are arrived at — the rings, the 0–5 scale, and the evidence rules — is written up in the radar methodology. This table and the chart below are generated from one file, scorecards.json: the source of truth, machine-readable, and kept separate so two copies of the same numbers cannot drift apart between editions. Neo4j is the primary column as the incumbent every selection is measured against. Last reviewed 2026-Q3.

Comparator scores (same axis order — Query, Traversal, Writes, Scale, Analytics, Real-Time, GraphRAG, Ops/Eco, Governance, Cost). Memgraph: 4.4 / 4.6 / 4.4 / 3.2 / 4 / 4.7 / 4 / 3.6 / 3.6 / 3.8. FalkorDB: 4.2 / 4.7 / 4 / 3.4 / 3.6 / 4.2 / 4.5 / 3.6 / 3.4 / 4.2. TigerGraph: 3.4 / 4.3 / 4.2 / 4.7 / 4.4 / 3.6 / 3.6 / 3.2 / 4.2 / 3.4.

5. The radar

Ten graph axes; higher is better on all. The shapes are the argument. Neo4j is the roundest — strong nearly everywhere, dipping only on scale and cost. Memgraph and FalkorDB are spikes: Memgraph peaks on real-time and traversal, FalkorDB on traversal and GraphRAG, both short on ecosystem and governance. TigerGraph is the outlier, tall on scale and collapsed on query ergonomics and ops. Click any name in the legend to toggle it — comparing two shapes at a time is far more legible than four at once.

6. Workload-specific analysis

7. Decision tree & reference architecture

The selection collapses to a few branching questions. Answer them in order and the choice is usually made before you reach a benchmark.

graph TD
  A["Need graph traversals"] --> B{"Bounded, rebuildable
corpus?"}
  B -->|"Yes — hundreds to
a few thousand docs"| S["Build-time static graph
(no database)"]
  B -->|"No — large / mutable /
interactive"| C{"Billion-edge, must be
distributed?"}
  C -->|"Yes"| TG["TigerGraph"]
  C -->|"No"| D{"Graph changes constantly,
need sub-ms reads?"}
  D -->|"Yes — streaming"| MG["Memgraph"]
  D -->|"No"| E{"Latency-critical GraphRAG,
Redis already in stack?"}
  E -->|"Yes"| FK["FalkorDB"]
  E -->|"No — default"| N4["Neo4j"]

Where a graph database does earn its place, the pattern I would build keeps it behind the same swappable retriever interface as a vector store, so graph and vector retrieval compose rather than compete:

graph LR
  SRC[("Source data")] --> ETL["Extract entities + relations"]
  ETL --> GDB[("Graph database
Neo4j / Memgraph / FalkorDB")]
  EMB["Embeddings"] --> GDB
  Q["Query"] --> RET["Retriever interface"]
  RET -->|"graph traversal"| GDB
  RET -->|"vector search"| VEC[("Vector index")]
  GDB --> CTX["Grounded context + citations"]
  VEC --> CTX
  CTX --> LLM["LLM answer"]

The same 2-hop retrieval reads almost identically across the Cypher engines — the portability that GSQL gives up:

// Cypher (Neo4j / Memgraph / FalkorDB): entities two hops from a seed,
// ranked by a precomputed centrality score. Parameters are bound ($seed),
// never string-concatenated — query input is model-controlled in GraphRAG.
MATCH (s:Entity {id: $seed})-[*1..2]-(n:Entity)
WHERE n.score IS NOT NULL
RETURN DISTINCT n.name, n.score
ORDER BY n.score DESC
LIMIT 10;

8. POC plan (4 weeks)

• Week 1 — try to avoid a database. If the corpus is bounded and rebuildable, build the graph as a static file and see whether the traversals you actually need are already served. If they are, stop — you have saved yourself a stateful system.
• Week 2 — write your real graph, your real way. Load your real data at real size with your real update pattern (bulk once, or streaming continuously). This is where in-memory and streaming-first engines separate from disk-based ones, and where TigerGraph's bulk loader earns its place.
• Week 3 — run the traversals and algorithms that matter, then operate the failure. Benchmark your deepest real query, not a vendor's; run the graph-data-science algorithm you actually need (and check it exists); then restart a node, restore a backup, and roll an upgrade. The ecosystem gap between Neo4j and the specialists shows up here.
• Week 4 — price it and write the ADR. Model licensing and infrastructure at 12-month scale — Neo4j Enterprise, TigerGraph's cluster, or the RAM bill for an in-memory engine — and record which engine, at which threshold, and why.

9. Final recommendation

Ask whether you need a database before you pick one; then default to Neo4j and move to a specialist only when a specific axis forces it — TigerGraph for distributed scale, Memgraph for real-time, FalkorDB for latency-critical GraphRAG.

For a bounded, rebuildable corpus, a build-time static graph is the honest answer and none of these four is needed — the graph fits in memory and regenerates from source, and you skip the backups, upgrades and on-call a database brings. When the graph is genuinely large, mutable or interactively queried, Neo4j is the low-regret default: it scores highest here on algorithms, ecosystem, GraphRAG tooling and governance, and Cypher is the transferable skill. Its weak axes are horizontal write scale and cost, and those are exactly the signals to look at a specialist.

Choose TigerGraph when the graph is genuinely billion-edge and must be distributed, and budget for GSQL and the operational weight of a cluster. Choose Memgraph when the graph changes constantly and reads must be sub-millisecond, sizing to RAM. Trial FalkorDB when GraphRAG latency is the constraint and Redis is already operated — its GraphBLAS traversal and in-graph vector index are purpose-built for it, against a younger ecosystem. And keep the graph behind a retriever interface so graph and vector retrieval compose.

I would re-assess when Neo4j's horizontal write scaling closes the gap to TigerGraph, and when the specialists' ecosystems mature — either would move where the graduation thresholds sit.

References

Vendor benchmarks in this space each favour their sponsor; I have leaned on primary docs and treated any single throughput number as directional.

Scores are my own architect-level judgment for the stated use case, calibrated to mid-2026 — not a vendor ranking, and not a throughput benchmark. Graph-workload axes, higher is better. NOT comparable with any other assessment here. Re-score against your own POC numbers before you commit.