Check out how ScaleOut In-Memory Database running open-source Redis compares with other implementations of Redis:

Features ScaleOut In-Memory Database Other Redis Implementations
Clustering Servers “One button scaling; up or down:” Just connect a server to the cluster; it automatically joins the membership, creates replicas, and rebalances the load. Same for leaving a server. Clustering requires that you manually create and configure shards on each server and distribute hash slots. This process is complicated, time consuming, and error prone.
# of Servers Required Servers host both primary and replica objects within a single service process. This minimizes the number of servers needed. Redis recommends separate master and replica servers for high availability. That requires more servers for a given data set.
Failure / Recovery Process After a server or network failure, ScaleOut automatically promotes replica objects to primaries AND creates new replicas to “self-heal.” The cluster automatically re-balances the workload. No manual intervention is required. After a failure, Redis promotes replica objects to primaries but does not create new replicas. Recovery requires manual intervention to restore replicas. If both a primary shard and its replica fail, the entire cluster becomes inoperable.
Data Consistency Provides full (strong) data consistency with patented technology; ScaleOut never serves stale data. Redis uses eventual data consistency to updates replicas and can serve stale data to applications.
Multi-Threading Runs Redis commands using multi-threaded processing to automatically take advantage of all processing cores using one process per server. Redis uses single-threading and runs one command at a time. It requires you to license multiple shards per server to use additional cores.
Supported OS Runs natively on Linux or Windows. OSs can be mixed in a single cluster. Redis has no native Windows support and runs select versions of Linux.
Backup / Restore “One button backup and restore:” Provides fully parallel backup and restore. Allows a different cluster configuration when restoring data. Users must separately save each node’s database to disk and must restore them to exactly the original cluster configuration.

Many of the limitations described above apply to both open-source Redis and Redis Enterprise. For example, users need to manage shards and hashslots, and they need to deploy additional shards for hi-av and multi-core speedup. ScaleOut In-Memory Database automatically takes care of all this and delivers higher performance with lower TCO. In fact, ScaleOut In-Memory Database has up to 10X lower TCO than Redis Enterprise.

 

Other Resources: