Multigraph Topology for Scalable, Isolated Graph Workloads

Recap

FalcorDB’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.

Test setup	Cores	Graph layout	QPS (mean)	Scaling reasoning
Single instance	16	629 isolated graphs on one node	≈ 25 k	Baseline
3-master cluster	48	Graphs distributed by key-space slots across three masters	≈ 60 k	Deductive: tripling compute raised throughput ~2.4×, close to linear
3 masters + 3 replicas	96	Masters handle writes; replicas added as read targets	≈ 120 k	Inductive: doubling compute again doubled read throughput, sustaining linear trend

Key Observations

Linear throughput growth. Each 32-core increment raised capacity roughly in proportion to added compute, indicating minimal coordination overhead across shards.
Graph isolation at query time. Every query targets a single graph key, removing the need for second-label filters and reducing risk of data leakage.
Replica lag is negligible for reads. The team noted only a brief propagation delay from master to replica; write integrity remains master-bound.

Workshop Q&A

Can I add more replicas to achieve more operations per second?

Yes. You can add multiple replicas per master to scale read operations. Each replica increases read throughput proportionally.

Is the multigraph functionality available in the open-source version of FalkorDB?

Yes. The multigraph feature is fully available in the open-source version without distinction from the managed service.

Is there full isolation between masters and replicas?

Yes. Queries run locally on the target master or replica. Read queries don’t affect other nodes; only writes trigger replication to replicas.

Are multi-tenant graphs a good mechanism for sharding?

No. Multi-tenancy manages multiple graphs on a single instance. Sharding refers to splitting key-space across machines for horizontal scaling.

Can I run a query distributed between multiple graphs and return one result set?

No. Queries in FalkorDB target a single graph. Cross-graph queries are not supported within one query execution.

Is there any overhead when adding more graphs?

Memory usage increases and snapshots take longer, but query latency remains unaffected since each query targets a single graph.

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.

Roi Lipman

Roi Lipman serves as CTO at FalkorDB, leading the development of ultra-low-latency graph database platforms for generative AI and retrieval-augmented generation (RAG) workflows. He brings over 20 years of database engineering expertise from roles at Forter, StreamRail, Maglan, AVG and the Israel Intelligence Corps. As creator and lead architect of RedisGraph for the past eight years, he optimized Cypher-based knowledge graph performance for enterprise-scale AI applications.

USE CASES

SOLUTIONS

GraphRAG-SDK

Code Graph

Browser

Ultra-fast, multi-tenant graph database using sparse matrix representations and linear algebra, ideal for highly technical teams that handle complex data in real-time, resulting in fewer hallucinations and more accurate responses from LLMs.

COMPARE

FalkorDB reduces computational overhead by leveraging sparse matrices and linear algebra operations, minimizing vCPU usage, lowering infrastructure costs, and reducing licensing expenses.

RESOURCES

COMMUNITY