Yes, a Redis-based graph database can scale for enterprise AI when workloads are designed around bounded graph traversals, multiple isolated graphs, and a read/write architecture that uses replicas for read-heavy traffic. FalkorDB clusters distribute graph keys across master shards, while replicas provide failover and read scaling. Capacity still depends on graph shape, memory sizing, query depth, tenant count, and write volume.
What is multigraph topology?
Multigraph topology stores each tenant or workload in its own isolated graph key. In a FalkorDB cluster, those graph keys can be distributed across master shards while each individual graph remains on one shard. This architecture supports tenant isolation, predictable query boundaries, and throughput growth across many independent graph workloads.
Recap
FalkorDB’s team assessed how a multi-tenant graph database handles an access-permission workload and whether throughput scales when moving from a single server to a clustered deployment. The workshop used a real-world pattern—“Does user X have permission to file Y?”—and measured query-per-second (QPS) under three hardware configurations.
What does Redis-based mean for a graph database?
FalkorDB is a graph database built as a Redis module. It runs inside a Redis process and exposes graph operations as Redis commands, so a graph is addressed as a Redis key and queried with Cypher.
Redis compatibility is what that buys you operationally: the RESP protocol, the Redis clients your team already uses in most languages, and familiar tooling for persistence, replication, monitoring, and cluster management. That is an integration and operations benefit. It is not, by itself, evidence of query performance.
It is also not merely a cache or a key-value layer with graph naming on top. FalkorDB stores graph structures in memory and represents adjacency using sparse matrices, so traversals are executed as linear-algebra operations over those matrices rather than as pointer chasing through key lookups.
Because of that, traversal performance tracks the work a query actually does. Graph shape, traversal depth, fan-out at each hop, available memory, index coverage, and query design all matter. A shallow, indexed, well-anchored lookup and an unbounded multi-hop traversal over the same graph behave very differently, on any hardware.
What scales in a FalkorDB cluster?
A FalkorDB cluster scales by distributing graphs, not by splitting an individual graph.
- Graph keys are distributed across master shards. Different graphs hash to different slots, so they can be spread across multiple masters.
- A graph is a single Redis key and stays on one shard. All of a graph’s data lives on the master that owns its slot.
- Multiple masters increase throughput across many graphs. Aggregate capacity grows as you add masters, because concurrent queries against different graphs land on different nodes.
- Replicas scale read-heavy workloads and provide failover. Each master can have replicas that serve read-only queries and can be promoted if the master is lost.
- Writes remain primary-bound. A graph’s write capacity is the capacity of its master.
- A cluster does not split one graph across multiple shards. Horizontal scale comes from having many graphs, not from partitioning a single one.
- Cross-graph queries are not supported within one query execution. Combining data from several graphs is an application-layer concern.
This shape suits multi-tenant systems well, and it suits a single enormous graph poorly. Setup and scaling steps are covered in the FalkorDB cluster architecture documentation.
Measured enterprise scaling results
The figures below were measured in a FalkorDB workshop that tested whether throughput scales when the same workload moves from one server to a cluster, and then to a cluster with read replicas.
Methodology. The workload modelled an access-permission query of the form “Does user X have permission to access file Y?” — a bounded, anchored traversal executed against many small isolated tenant graphs, 629 of them in the single-instance test. Throughput is reported as mean queries per second (QPS) under sustained load across three hardware configurations.
| Test setup | Total cores | Graph layout and test conditions | Mean QPS (measured) | Scaling observation |
|---|---|---|---|---|
| Single instance (baseline) | 16 | 629 isolated graphs on one node; single master, no replicas | ≈ 25 k | Baseline |
| 3-master cluster | 48 | Graphs distributed by key-space slots across three masters; no replicas | ≈ 60 k | Tripling compute raised throughput ~2.4×, close to linear |
| 3 masters + 3 replicas | 96 | Masters handle writes; three replicas added as read targets | ≈ 120 k | Doubling compute again doubled read throughput, sustaining the linear trend in this test |
Treat these figures as benchmark or workshop results for one workload shape, not as a universal capacity guarantee or an enterprise SLA. They show how throughput responded when this specific access-permission workload was scaled out; they do not establish that any workload will scale the same way.
Measured results on your own system will differ with:
- Graph size and topology
- Number of tenants
- Query complexity
- Traversal depth and fan-out
- Read/write ratio
- Hardware
- Memory availability
- Network conditions
- Client and deployment configuration
Key Observations
Throughput grew close to linearly in this test. Each roughly 32-core increment raised measured capacity approximately in proportion to the added compute, which indicates low coordination overhead across shards for this access pattern.
Graph isolation at query time. Every query targets a single graph key, removing the need for second-label filters and reducing the risk of cross-tenant data leakage.
Replica lag was small for reads under this load. The team observed only a brief propagation delay from master to replica; write integrity remains master-bound. Replication is asynchronous, so lag should still be monitored under heavier write volumes.
How read and write scaling work
FalkorDB uses a single-primary model: each shard has one master that owns its graphs, plus optional replicas.
- Masters handle writes. Every write to a graph goes to the master that owns that graph’s hash slot.
- Replicas serve read-only traffic. A replica will reject writes, so read queries can be routed to it safely.
- Replication is asynchronous. The master acknowledges a write and then streams it to its replicas, so a replica can briefly return a slightly older view of the graph.
- Replicas can improve read throughput and provide failover capacity. Adding read targets increases the aggregate read capacity behind a master and gives you a node that can be promoted if that master is lost.
- Monitor replication lag under heavy write load. If lag matters for a given query, send that query to the master rather than a replica.
- Replicas do not increase write throughput. Write capacity for a graph is bounded by its primary, regardless of how many replicas are attached.
- High availability needs an explicit configuration. Replication alone is not automatic failover; you need an appropriate cluster or failover setup to promote a replica without manual intervention.
The master–replica setup is documented in FalkorDB replication and read scaling.
What does not scale automatically?
Several things do not improve just by adding hardware. These constraints matter more than headline throughput when you are sizing an enterprise deployment.
- One graph is not split across multiple shards. A graph is a single Redis key, so it lives entirely on one master. A single very large graph is bounded by the capacity of the shard that holds it.
- Cross-graph queries cannot be combined into one query execution. A query targets one graph; results from several graphs must be joined in the application layer.
- Replicas do not increase write throughput. Read scaling and write scaling are separate problems, and only the first is solved by adding replicas.
- Memory usage increases as graphs and data volume increase. Graph data is held in memory, so capacity planning is primarily memory planning.
- Snapshot time can increase as data volume grows. That affects persistence windows, backup duration, and recovery time objectives.
- Deep or high-fan-out traversals require tuning. An unbounded multi-hop traversal can do far more work than a bounded, anchored one on the same graph, and no amount of sharding fixes an unbounded query.
- Enterprise capacity must be validated against your own workload. Published benchmarks describe the workload that was measured, not the workload you intend to run.
How this applies to enterprise AI and GraphRAG
The multigraph-plus-replica topology maps onto several enterprise AI patterns, because most of them are read-heavy, tenant-scoped, and anchored on a known starting entity.
- Multi-tenant knowledge graphs. One graph per tenant gives isolation at the key level, so a query cannot accidentally traverse into another tenant’s data.
- Permission-aware retrieval. The benchmarked access-check pattern has the same shape as filtering retrieval by entitlement before content reaches the model.
- GraphRAG context retrieval. A bounded traversal from an anchor node assembles a context subgraph, which is a more targeted input than a flat list of similar chunks.
- Agent memory. Agents can persist entities, relationships, and history as a graph and read it back with structured queries instead of re-embedding everything.
- Low-latency relationship queries. In-memory adjacency keeps short, indexed traversals cheap enough to sit inside a request path.
- Read-heavy inference workloads. Retrieval traffic can be directed to replicas where slightly stale reads are acceptable.
Whether relationship traversal or vector similarity is the right primitive for a given retrieval step is a separate design decision — see this graph and vector database comparison.
In practice, scaling AI retrieval depends less on cluster size than on keeping each retrieval bounded:
- Anchor-node selection. Start from a specific, indexed entity rather than scanning for a starting point.
- Hop limits. Set an explicit maximum traversal depth in the query.
- Fan-out limits. Cap how many neighbours are expanded per hop so a hub node cannot blow up the result set.
- Property indexes. Index the properties used for anchor lookup and filtering.
- Tenant-aware graph selection. Resolve the tenant to a graph key before the query runs.
- Read replicas where appropriate. Route retrieval reads to replicas when asynchronous replication is acceptable for that call.
- p95 and p99 latency monitoring. Track tail latency rather than averages, because tail behaviour is what users and agent loops actually experience.
These practices make retrieval cost predictable. They do not guarantee that any particular latency or throughput target will be met — that has to be measured against your own workload.
Enterprise sizing and load-testing checklist
Use this checklist to gather the inputs needed to size a deployment and to design a load test that reflects real traffic.
- Number of tenants or graphs, now and at your planning horizon
- Nodes and edges per graph, including the largest expected graph
- Expected graph growth rate
- Concurrent reads at peak
- Concurrent writes at peak
- Read/write ratio
- Average and maximum traversal depth
- Query fan-out per hop
- p95 and p99 latency targets
- Memory requirements, including headroom for growth and snapshots
- Snapshot and recovery requirements, including recovery time objectives
- Replication lag tolerance per query class
- Failover objectives and who or what performs promotion
- Cross-region or multi-zone requirements
- Authentication and tenant-isolation requirements
Test with representative, production-shaped data rather than synthetic averages alone. Averaged test data tends to hide the cases that actually cause trouble: hub nodes with very high degree, unusually large tenants, and skewed access patterns where a small number of graphs receive most of the traffic.
Frequently asked questions
Can a Redis-based graph database scale for enterprise AI workloads?
How does FalkorDB scale across multiple graph databases?
Can FalkorDB split one graph across multiple shards?
How does FalkorDB support read scaling?
Do replicas increase FalkorDB write throughput?
Can I add more replicas to achieve more operations per second?
What happens if a FalkorDB master fails?
Is there full isolation between masters and replicas?
How does multigraph architecture support SaaS tenant isolation?
Are multi-tenant graphs a good mechanism for sharding?
Can I run a query distributed between multiple graphs and return one result set?
Is there any overhead when adding more graphs?
Is the multigraph functionality available in the open-source version of FalkorDB?
Can FalkorDB run GraphRAG workloads at scale?
What are the limitations of FalkorDB clustering?
How should I benchmark FalkorDB for an enterprise AI workload?
Build fast and accurate GenAI apps with GraphRAG SDK at scale
FalkorDB offers an accurate, multi-tenant RAG solution based on our low-latency, scalable graph database technology. It’s ideal for highly technical teams that handle complex, interconnected data in real-time, resulting in fewer hallucinations and more accurate responses from LLMs.
