The ability to scale out a database is crucial, in this short post I would like to walk through how FalkorDB scales out.

As a quick recap I should mention that FalkorDB is a native graph database, developed as a Redis module, Falkor can manage thousands of individual graphs on a single instance.

We start out with a single FalkorDB instance, let’s call it primary, this instance handles both READ and WRITE operations.

# create primary database

docker run –name primary –rm -p 6379:6379 falkordb/falkordb

As a next step we would like to isolate our reads queries from our writes, to do so we fire up a new FalkorDB instance, let’s name it secondary and define it as a replica of primary.

Once initial replication between the two servers is done we can divert all of our read queries to secondary and only hand off write queries to primary.

# create replica

docker run –name secondary –rm -p 6380:6380 falkordb/falkordb –port 6380 –replicaof 172.17.0.2 6379

It is worth mentioning that we’re not limited to just a single READ replica, but we can create as many READ replicas as we need, e.g. a single primary and three read replicas: replica-1, replica-2 and replica-3.

A load balancer can distribute the read load among these three replicas.

In the former example we’ve distributed the entire dataset from the primary database to multiple replicas, in cases where multiple graphs are managed on a single server e.g. primary-1 holds graphs: G-1, G-2 and G-3.
We can distribute the graphs among multiple servers, for example primary-1 would manage G-1 and a new server primary-2 would host G-2 and G-3.

Write operations will be routed to the appropriate server depending on the accessed graph key.
Of course each one of these primary servers can have multiple read replicas. e.g. primary-1 can have two read replicas and primary-2 will replicate its dataset to just a single replica.

FalkorDB version 4 introduce a quick and efficient way of replicating queries between primary and its replicas.

Up until recently a WRITE query (which ran to completion and modified a graph) would be replicated as-is to all replicas, causing each replica to re-run the query, although such a r