Redis Cluster Sizing

Give the dataset size and the memory per node. The result assumes only part of each node is usable for data, because replication buffers, client buffers and the fork a save performs all live outside maxmemory.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Calculate. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

A large dataset

400 GB across 64 GB nodes with one replica each

dataset: 400gb
node-memory: 64gb
replicas: 1

No replicas

The same cluster with no failover, which is a cluster that cannot survive a node loss

dataset: 400gb
node-memory: 64gb
replicas: 0

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Setting maxmemory to the machine's memory

    Replication buffers, client output buffers and the copy-on-write during a BGSAVE all sit outside it. The process is then OOM killed during a save.

    Instead:60 to 70% of the machine is the usual starting point.

  2. Running a cluster with fewer than three primaries

    Failover needs a majority of primaries to agree a node is down, which is impossible below three.

    Instead:Three primaries minimum, even when one would hold the data.

  3. Assuming an even slot split means even load

    Slots are the unit of assignment, not of work. A hash tag concentrating a large tenant puts all of it on one node.

    Instead:Check per-node memory, not slot counts.