FalkorDB is a graph database built for GraphRAG: a queryable property graph engine that represents graphs as sparse adjacency matrices and runs traversals as GraphBLAS matrix operations, instead of the pointer-chasing most graph databases rely on. According to FalkorDB’s own design documentation, the engine reports over 1 million nodes created in under half a second, with 500,000 relationships formed in under 0.3 seconds. It’s the direct successor to RedisGraph, forked in July 2023, more than a year before RedisGraph’s January 2025 end-of-life, and rewritten from C to Rust in 2026. This page reconciles FalkorDB’s own conflicting Neo4j benchmark numbers, states its SSPL license reality plainly, and closes on the business-semantic question neither engine’s own access controls answer.
FalkorDB’s own benchmark numbers against Neo4j differ across its own properties, and its GitHub community has an open, unanswered dispute over whether “open source” is the right label for an SSPL license. Both are stated plainly further down this page, dated and attributed rather than repeated as a single headline number. Amazon Neptune covers the managed-cloud side of this same GraphRAG-infrastructure question, and Neo4j GraphRAG versus LlamaIndex and LangChain’s graph transformer covers the construction-library side; this page covers the purpose-built, GraphBLAS-native engine side.
- The architecture claim: FalkorDB replaces pointer-chasing graph traversal with sparse-matrix linear algebra via GraphBLAS, the mechanism behind its speed claims
- The benchmark problem: FalkorDB’s own P50/P99 figures against Neo4j aren’t consistent across its own marketing, and only one independent test surfaced in this research to check them against
- The license question: FalkorDB’s homepage labels the project open source; its own GitHub community disputes that, since SSPL isn’t an OSI-approved license
- The open question: a fast graph engine still doesn’t decide what an entity means across teams, or what an AI agent is allowed to retrieve from it
- A related but different question: knowledge graph construction is the step upstream of which engine ends up storing the result
Below: what FalkorDB is, how its architecture actually works, how its speed claims hold up against Neo4j, whether it’s really open source, how accurate it is for GraphRAG, real production use, and where a governed context layer fits above whatever graph engine a team runs.
| Field | Detail |
|---|---|
| What it is | A graph database using sparse-matrix linear algebra (GraphBLAS) instead of pointer-chasing for graph traversal |
| Key benefit | Reports O(1) relationship insertion: over 1 million nodes created in under 0.5 seconds, 500,000 relationships in under 0.3 seconds |
| Best for | Low-latency, multi-hop GraphRAG retrieval; teams already running Redis |
| License | SSPLv1, “Source Available,” not an OSI-approved open source license, disputed on FalkorDB’s own GitHub |
| Origin | Direct successor to RedisGraph, forked July 2023 (RedisGraph EOL January 2025); rewritten from C to Rust, 2026 |
| Core components | GraphBLAS sparse matrices, OpenCypher, Bolt/RESP dual protocol, native vector, full-text, and range indexes |
Get the AI Context Stack
See how teams think about the layer that carries context above every graph, warehouse, and lakehouse they run, whatever engine builds the graph.
Get the AI Context StackWhat is FalkorDB?
FalkorDB is a graph database purpose-built for GraphRAG, using sparse-matrix linear algebra instead of the pointer-chasing traversal most graph databases rely on. It has 6.2k stars on its official GitHub repository as of September 2026, is licensed under SSPLv1, and GitHub reports its primary language as Rust.
FalkorDB isn’t a new project so much as a relaunch. FalkorDB’s own documentation states that FalkorDB is RedisGraph’s successor, built by the team behind the original RedisGraph project, and dates RedisGraph’s end-of-life to January 31, 2025. The FalkorDB repository was created in July 2023 and the fork was announced that August, so the project was already running well before RedisGraph was switched off. The engine went through a second transformation in 2026, a move from C to Rust aimed at memory safety and performance rather than a change to the underlying sparse-matrix design; FalkorDB’s own design documentation still describes a “native C implementation”, so the docs trail the codebase.
The three co-founders, Roi Lipman, Guy Korland, and Avi Avni, came out of Redis, where Lipman built RedisGraph. FalkorDB publishes no funding figures. Guy Korland, FalkorDB’s CEO and co-founder, described the project’s purpose plainly on the two-year anniversary of the relaunch: “a database built to reason over connections between data.”
That framing matters for how the rest of this page reads. FalkorDB is infrastructure for connecting and traversing data fast, a real and specific engineering achievement, not a claim about what those connections mean once an application or an AI agent is built on top of them. The distinction becomes concrete once the architecture and the benchmark numbers are on the table, which the next two sections cover before this page reaches the part FalkorDB’s own marketing doesn’t touch: knowledge graphs for AI agents more broadly, and where FalkorDB fits into that picture.
How does FalkorDB’s architecture work?
Under the hood, FalkorDB represents a graph as a sparse adjacency matrix and runs graph queries as matrix multiplication through the GraphBLAS library, rather than chasing pointers from node to node the way most graph databases traverse relationships.
Specifically, FalkorDB’s design documentation describes a compressed sparse column (CSC) format: one global adjacency matrix for the whole graph, plus one additional matrix per relationship type. The same page calls that storage format provisional, “subject to change.” A multi-hop query, the kind GraphRAG retrieval relies on most, becomes a linear-algebra operation on those matrices instead of a sequence of pointer lookups. That design is also what underlies FalkorDB’s O(1) relationship-insertion claim: the same documentation reports over 1 million nodes created in under half a second, and 500,000 relationships formed in under 0.3 seconds.
On top of that storage model, FalkorDB speaks OpenCypher over a dual Bolt and RESP protocol, so teams already running Redis can query it with familiar tooling. It also ships three native index types: full-text, vector, and range, all inside the same engine that handles graph traversal. That “graph plus vector in one system” combination is the specific pattern independent reviewers repeatedly highlight as a practical advantage over running a separate vector database alongside a graph store, the same tradeoff FalkorDB’s own integrations with LangChain-based agents run into once retrieval spans both patterns at once.
None of this is a how-to for building a GraphRAG pipeline on FalkorDB; the GraphRAG-SDK repository is the better starting point for implementation steps, and how to build a knowledge graph for AI agents covers the construction process this page assumes. What matters here is the mechanism: a sparse-matrix engine changes the performance profile of graph queries, but it doesn’t change what a node or an edge means to the business asking the question, a distinction what a knowledge graph is starts to draw and this page returns to later.
(Image brief flagged for a follow-up commit: a two-panel technical diagram, “Neo4j: pointer-chasing / index-free adjacency” on the left, “FalkorDB: sparse adjacency matrix + GraphBLAS” on the right, with a small annotation reading “multi-hop query = matrix multiplication” on the FalkorDB side. Clean and technical, no decorative treatment. See this page’s final summary for the full brief; no image tag is placed in this draft per this cohort’s no-inline-SVG rule.)
How fast is FalkorDB compared to Neo4j?
FalkorDB’s own benchmark numbers against Neo4j aren’t consistent across its own properties, so this section lays the dated claims side by side with the one independent test found, instead of repeating a single headline multiple.
According to FalkorDB’s own benchmark, published December 2, 2024, FalkorDB ran an 82% read, 18% write mix of 11 templated queries against the SNAP Pokec dataset on an 8-core/16-thread, 32GB Linux GitHub Actions runner. It reported a P50 latency of 55ms against Neo4j’s 577.5ms, and a P99 of 136.2ms against Neo4j’s 46,923.8ms. Akshay Pachaar, Co-Founder of DailyDoseOfDS, framed FalkorDB as “496x faster than Neo4j” at the P99 tail in a widely shared LinkedIn breakdown. That multiple comes from FalkorDB’s homepage figures, 83ms against 41,157ms, not from this December 2024 benchmark, whose own P99 ratio works out closer to 344x. So the restatement circulates FalkorDB’s own claim rather than confirming it, and it doesn’t even circulate the same numbers.
The one independent, non-vendor test found in this research points in the same direction, at smaller multiples. AIMultiple’s April 2026 benchmark, authored by Ekrem Sarı, ran FalkorDB, Neo4j, and Memgraph against a synthetic 381,000-node, 804,000-edge dataset on an 8-vCPU RunPod instance. FalkorDB peaked at 6,693 queries per second against Neo4j’s 1,010 QPS, with a 1.1ms cold start against Neo4j’s 90ms. Memory usage told a more mixed story: FalkorDB used 496MB against Neo4j’s 2,668MB, but Memgraph used the least of the three at 415MB.
Read those two sets together and the pattern is clear enough: FalkorDB’s own marketing states one multiple, and the one independent test found here confirms the direction at a much smaller one. FalkorDB’s homepage, its dedicated Neo4j comparison page, and this December 2024 blog post each state a different figure for the same underlying claim. Dating and attributing each number, rather than repeating whichever one is newest, is the only way to know which is current.
Graph layout, pointers versus sparse matrices, is what changes how multi-hop traversals run on modern hardware. Source: Atlan.
| Metric | FalkorDB’s own benchmark (Dec 2024, vs. Neo4j) | AIMultiple independent benchmark (Apr 2026, vs. Neo4j/Memgraph) | Source |
|---|---|---|---|
| P50 latency / peak throughput | 55ms | 6,693 QPS peak (FalkorDB) vs. 1,010 QPS (Neo4j) | FalkorDB blog; AIMultiple |
| P99 latency / cold start | 136.2ms | 1.1ms cold start (FalkorDB) vs. 90ms (Neo4j) | FalkorDB blog; AIMultiple |
| Memory usage | Not reported in this test | 496MB (FalkorDB) vs. 2,668MB (Neo4j) vs. 415MB (Memgraph, lowest) | AIMultiple |
This page doesn’t re-run the full feature-by-feature Neo4j comparison; two sibling pages already own that depth. Neo4j for agent context graphs covers Neo4j on its own terms, and knowledge graphs for AI agents covers the broader question of why any of these engines get chosen at all.
Is FalkorDB open source?
FalkorDB’s homepage labels the project “OPEN SOURCE”, but its license is SSPLv1, a distinction its own GitHub community has disputed and FalkorDB hasn’t answered.
An open GitHub Discussions thread, opened October 25, 2025 and still unanswered by FalkorDB as of this research, argues that FalkorDB’s website “wrongfully states its software is open-source.” That thread quotes the wording the homepage carried at the time, “FULLY OPEN-SOURCE”; the page reads “OPEN SOURCE” today, so the label appears to have been softened since the dispute was raised. The argument itself is specific: SSPL is not recognized as open source by the Open Source Initiative, the Free Software Foundation, or the Debian Free Software Guidelines. GitHub’s own repository metadata classifies the license as “Other” rather than as a recognized open source license. It’s the same category dispute that dogged MongoDB when it adopted the same license years earlier.
The distinction is worth being precise about, because “free” and “open source” aren’t the same claim. FalkorDB does offer a free tier, which answers one common question directly: yes, a team can use FalkorDB at no cost. Whether that free, source-available software also meets the specific definition of open source that OSI, FSF, and Debian use is a separate question, and by that specific definition, SSPL doesn’t qualify. FalkorDB is also, separately, an in-memory-first database by design, meaning its primary working representation of a graph lives in memory rather than on disk, which is part of why its latency numbers in the previous section run as low as they do.
None of this is a case against using FalkorDB. It’s a fact a team should know before it builds a compliance argument, a procurement checklist, or a vendor comparison on the premise that FalkorDB is open source in the OSI sense, when its own community says otherwise and FalkorDB hasn’t corrected it.
How accurate is FalkorDB for GraphRAG?
FalkorDB’s accuracy case rests on two of its own posts: its 2025 GraphRAG SDK update, and its relay of a benchmark published by Diffbot, another knowledge-graph vendor.
According to FalkorDB’s own accuracy blog, published April 7, 2025, the 2025 GraphRAG SDK update added schema retrieval with lower latency, which FalkorDB reports pushed its own enterprise accuracy on schema-heavy queries past 90%. The same post relays Diffbot’s KG-LM Accuracy Benchmark, published by Diffbot in late 2023 and run against 43 business-relevant questions: ungrounded LLMs scored 16.7% accuracy against 56.2% with knowledge-graph grounding, a 3.4x improvement, and vector-only retrieval scored 0% in the Metrics & KPIs and Strategic Planning categories. Note what that test did and did not measure. It compared LLM accuracy with and without graph grounding in general, so FalkorDB was not the system under test, and Diffbot sells a knowledge graph, which makes it one knowledge-graph vendor’s evidence for the value of knowledge graphs rather than an independent evaluation of either product. The gap is a large part of why GraphRAG exists as a category at all: some questions simply can’t be answered from similarity search over disconnected chunks, a limitation both AI agent accuracy and AI agent hallucination cover from the model-output side of the same problem.
FalkorDB’s own GraphRAG-SDK 1.0 announcement reports 63.73 on GraphRAG-Bench Novel and 75.73 on the Medical corpus, and claims first place on both public leaderboards. Read those two figures with the method attached. FalkorDB ran its own numbers, stating that “all tests ran on a MacBook Air (Apple M3, 24 GB) using GPT-4o-mini via Azure OpenAI,” and took the competitor figures from the published leaderboard, so the ranking is self-computed rather than leaderboard-certified. The post was published April 2026 and updated August 2026, and the leaderboard itself keeps moving, so any single score needs a date attached to it.
| Metric | Without GraphRAG grounding | With GraphRAG grounding | Source |
|---|---|---|---|
| Accuracy on 43 enterprise questions (Diffbot KG-LM benchmark) | 16.7% | 56.2% (3.4x improvement) | FalkorDB blog, 2025-04-07 |
| Vector-only retrieval, schema-heavy categories (metrics, KPIs, strategic planning) | 0% | Not tested in this benchmark | FalkorDB blog, 2025-04-07 |
Not sure what your agents can already reach?
Run a quick assessment on how governed your current context layer is before scaling agent workloads on top of any graph.
Take the Maturity AssessmentWhat are FalkorDB’s real-world use cases?
Two named production deployments show what FalkorDB’s speed claims look like once a real GraphRAG system is running: SERGAS Group’s legal-escalation reduction, and Securin’s multi-hop query latency.
FalkorDB’s case studies report that SERGAS Group cut legal escalations by roughly 50% after shipping a FalkorDB-backed knowledge graph as a Claude Skill, with cited answers delivered in under a minute. Securin reports a 0.3-second latency on complex 7-hop queries after migrating to FalkorDB, eliminating a prior 25% query-failure rate on its previous solution. Both cases describe FalkorDB operating as a fast retrieval engine underneath an application someone else built, not as something that decided what the underlying data meant.
That last point has one honest exception worth naming directly rather than skipping. FalkorDB does ship engine-level access control: its pricing page lists graph access control and multi-graph multi-tenancy on every tier, including the free one. That governs which isolated graph a given credential can touch, a narrower question than what an entity means across teams, or whether a specific AI agent’s role should be allowed to see it. The next section draws that distinction out in full.
Both case studies sit inside the broader landscape of context graph tools for AI agents, where a fast retrieval engine is one piece of a larger agent context graph rather than the whole system.
How Atlan approaches context for graphs like FalkorDB
A real, engine-level access-control feature already exists here. FalkorDB’s own pricing page lists graph access control and multi-graph multi-tenancy on every tier, which governs who can read or write which of its isolated graphs. That’s a different question from what an entity means across teams or what an agent’s business-role-scoped policy allows it to retrieve.
That distinction is worth drawing plainly rather than overstating. FalkorDB’s access control operates at the graph-instance level: control over which isolated graph a given credential can touch, a narrower question than what a context graph carries versus what a context store holds. It isn’t business-semantic governance, meaning it doesn’t track whether a definition is current, whether two teams mean the same thing by the same node label, or whether a specific agent’s role should be allowed to retrieve a specific piece of retrieved context. That’s the same distinction Amazon Neptune’s IAM policies draw against Atlan’s glossary-plus-access-policy layer; the engine underneath changes, the gap above it doesn’t.
Atlan’s Enterprise Data Graph connects assets, lineage, business glossary terms, and ownership into one governed graph that sits above whatever engine stores and traverses the underlying data, FalkorDB or otherwise, the same distinction context layer versus knowledge graph draws directly. Atlan’s MCP Server delivers that governed context to AI agents the same way regardless of which engine sits underneath, the same pattern behind how to implement an enterprise context layer for AI and context engineering more broadly. Agents built with LangGraph or CrewAI hit the same pattern once they query a graph like FalkorDB’s: the framework decides how an agent reasons, not what it’s allowed to retrieve. This isn’t a claim that Atlan replaces or competes with FalkorDB. FalkorDB is construction-side infrastructure, fast and purpose-built for GraphRAG retrieval; Atlan governs what gets delivered from whatever it builds, the same relationship that shows up once a team moves past a single agent into a full AI agent harness or a semantic layer for AI agents spanning more than one system.
No customer has published a case study naming FalkorDB or a comparable sparse-matrix engine specifically. BNY Mellon’s work consolidating context into an enterprise data graph and Optum’s automatic lineage and context generation speak to the same governed-context pattern in general, business glossary and MCP-delivered context at enterprise scale, rather than to FalkorDB by name.
See the context layer in action
Watch how Atlan governs the retrieval layer that graph databases like FalkorDB feed into, whatever query language sits underneath.
Watch the Demo SeriesThe context question FalkorDB’s speed doesn’t answer
FalkorDB is real, fast, purpose-built infrastructure for GraphRAG’s construction side: sparse-matrix traversal, low latency, a direct RedisGraph successor now rewritten in Rust, and it makes no claim to the other half of the problem.
The open question sits above the graph engine, not inside it: who decides what an entity means once a knowledge graph is running in production, and what an AI agent is allowed to retrieve from it. That question doesn’t change based on which vendor built the graph, whether it’s FalkorDB’s sparse matrices, Neo4j’s index-free adjacency, or Amazon Neptune’s managed service. A team evaluating vector stores against graph databases for agent memory, or comparing vector databases and knowledge graphs more broadly, will land on the same answer either way: what agent memory actually needs to persist matters more than which storage pattern holds it, a question the best AI agent memory frameworks of 2026 and how to choose an AI agent memory architecture both work through in more depth than this page needs to repeat.
Put a number on the context gap
See what a governed context layer above FalkorDB, or any graph, is worth before you scale agent workloads on top of it.
Calculate Your ROIFAQs about FalkorDB graph database
1. Is FalkorDB free?
Yes, FalkorDB offers a free tier, and its core software is source-available under SSPLv1. That’s a distinct category from OSI-approved open source, a difference FalkorDB’s own GitHub community has disputed with the way FalkorDB describes itself on its homepage.
2. Which graph database is the best?
FalkorDB’s sparse-matrix architecture favors low-latency, multi-hop GraphRAG retrieval, while Neo4j’s more mature tooling and ecosystem favor teams that need broader driver and integration support already in place. Which one is better fits a given workload rather than a universal ranking.
3. Is FalkorDB in memory?
Yes, FalkorDB is designed as an in-memory-first graph database, which is part of why it reports low query latency and fast relationship insertion. Persistence to disk is supported, but the primary working representation of the graph lives in memory.
4. What is the difference between FalkorDB and RedisGraph?
FalkorDB is RedisGraph’s direct successor, built by the team behind the original project. The FalkorDB repository was created in July 2023 and the fork was announced that August, carrying the same sparse-matrix architecture forward under a new name and a separate company. RedisGraph itself reached end-of-life on January 31, 2025, well after the fork.
5. Is FalkorDB open source?
FalkorDB is licensed under SSPLv1, which is source-available rather than an OSI-approved open source license. Its homepage labels the project “OPEN SOURCE”. An open GitHub discussion from October 2025, still unanswered by FalkorDB, quotes the then-current “FULLY OPEN-SOURCE” wording and argues it doesn’t match that license reality.
6. Does FalkorDB support vector search?
Yes, FalkorDB includes native vector indexing alongside full-text and range indexes, all on top of its graph traversal engine. That combination is a large part of why practitioners describe it as a graph-plus-vector system rather than a graph-only database.
7. FalkorDB vs. Memgraph: which is faster?
An independent AIMultiple benchmark found FalkorDB fastest on peak throughput and cold start, while Memgraph used the least memory of the three engines tested. There’s no single winner across every metric; the right choice depends on which constraint, latency or memory, matters more for the workload.
8. Can FalkorDB run on AWS?
Yes. FalkorDB can be self-managed or run containerized, and its own pricing page names Google Cloud Platform, Amazon Web Services, and Microsoft Azure as supported deployment targets. It isn’t an AWS-native managed service the way Amazon Neptune is, so a team is responsible for its own deployment, scaling, and operations.
Sources
- FalkorDB, official GitHub repository
- FalkorDB Docs, official documentation
- FalkorDB Design, official documentation
- FalkorDB vs Neo4j: Graph Database Performance Benchmarks, FalkorDB blog, 2024-12-02
- Graph Database Benchmark: Neo4j vs FalkorDB vs Memgraph, AIMultiple, 2026-04-15
- GraphRAG vs Vector RAG: Accuracy Benchmark Insights, FalkorDB blog, 2025-04-07
- GraphRAG SDK 1.0: Production-Grade GraphRAG, FalkorDB blog, 2026-04-29
- FalkorDB website wrongfully states that its software is open source, GitHub Discussions, 2025-10-25
- FalkorDB Case Studies, FalkorDB
- FalkorDB Pricing, FalkorDB
- GraphRAG-SDK, official GitHub repository
