Redis Cluster vs Sentinel on a Single VPS: The Memory and Ops Tradeoff

Redis Cluster solves a problem most single-VPS deployments do not have: more data than one machine’s RAM, or more write throughput than one core can serve. It adds a cluster bus, 16,384 slot assignments and a gossip protocol that must converge after every topology change — memory and operator attention spent without removing the single point of failure the box itself represents. Sentinel keeps one primary and several replicas, votes on failure, and leaves data distribution alone.

What the cluster bus actually costs

Every cluster node opens a TCP link to every other node on port 16379 (client port plus 10,000) — an O(N²) mesh where three nodes give six links and six nodes give thirty. Each link carries gossip traffic at 10 packets per second. The memory cost comes from three places:

• Slot metadata: each node holds a 16,384-bit map of slot ownership plus per-slot migration state.
• Cluster state and node table: one entry per known node, including replicas and failed nodes still in the table.
• Per-client cluster redirections: MOVED and ASK responses generated for every wrong-node access, each a full RESP reply.

redis-cli -p 7000 info memory | egrep 'used_memory_human|used_memory_dataset|used_memory_overhead'
redis-cli -p 7000 cluster info
redis-cli -p 7000 cluster nodes | wc -l
redis-cli -p 7000 info clients
redis-cli -p 7000 memory usage 

On a small dataset the gap is stark. A three-master, three-replica cluster holding 200 MB typically shows 45-80 MB of used_memory_overhead across the primaries — replication buffers, client output buffers and slot bookkeeping. A Sentinel-monitored primary with the same data shows 10-20 MB. That is the cluster tax, and on a 2 GB VPS it is real money.

Sentinel quorum and what it does not solve

Sentinel is a separate process, not a Redis mode. Three Sentinels is the smallest reliable quorum, each costing roughly 8-15 MB RSS, plus the replication backlog and full data copy on each replica.

sentinel.conf:
  sentinel monitor mymaster 10.0.0.11 6379 2
  sentinel down-after-milliseconds mymaster 5000
  sentinel failover-timeout mymaster 60000
  sentinel parallel-syncs mymaster 1

Quorum of 2 means two of three Sentinels must agree the primary is unreachable. Failover is a leader election among Sentinels, then SLAVEOF promotion on the chosen replica. Clients must be Sentinel-aware or sit behind a proxy; a client pointed at a fixed IP keeps retrying the dead node. On one VPS, three Sentinels and two Redis processes also compete for the same memory and the same disk — and the failure they cannot protect against, the whole VPS disappearing, takes all three with it.

Failover behaviour compared on one box

The key row is the second. Cluster refuses writes when it loses contact with a majority of slot-owning masters — correct across machines, useless when four of six nodes live on one host. If the box reboots, both topologies come back from the same persistent store and the “high availability” delivered nothing during the outage that actually happened.

When cluster is pointless, and when it is not

A one-master cluster with zero replicas has no failover, still pays for the bus and slot bookkeeping, and refuses writes whenever it loses contact with that master. With one master and one replica on the same VPS it behaves like Sentinel with more moving parts. Cluster is defensible on one box only when you are staging a topology for later multi-host deployment, or when you are genuinely CPU-bound: Redis executes commands single-threaded and tops out near 100,000-150,000 simple ops/s per instance on a modern core, so two shards on a 4 vCPU box can double that. Benchmark before adopting it.

redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 1000000 -t get,set -q
redis-cli --latency-history -i 5
redis-cli -p 7000 --cluster check 127.0.0.1:7000

If the single instance saturates at 90,000 ops/s and your peak is 20,000, sharding buys nothing but RSS. If your key space exceeds roughly 60 percent of RAM after replication and fragmentation, a bigger plan is the cheaper answer — cluster does not add memory. Our notes on sizing VPS memory for in-memory datastores cover that headroom rule.

How to measure the RSS difference for your own dataset

Load your real key distribution into both topologies rather than trusting blog numbers. The procedure takes an hour and settles the question permanently.

# 1. snapshot the dataset
redis-cli -p 6379 --rdb /tmp/dump.rdb
# 2. load into single instance, measure
redis-cli -p 6380 debug reload
redis-cli -p 6380 info memory | grep used_memory:
# 3. load into 3-master cluster with hash tags you actually use
redis-cli --cluster create 127.0.0.1:7000 ... --cluster-replicas 0
for f in /tmp/dump.rdb; do redis-cli --pipe < /tmp/load.txt; done
redis-cli -p 7000 info memory | grep used_memory:
# 4. subtract dataset size reported by MEMORY STATS
redis-cli -p 7000 memory stats | egrep 'dataset.bytes|overhead.total'

Include the replica: a real deployment needs one copy for failover, so the true requirement is dataset × 2 × 1.3 (fragmentation) plus overhead. On a 4 GB VPS with 1 GB of data, cluster overhead can push you into swap — worse for latency than the failover you were avoiding.

Choosing between them

Two questions decide it. Does the data fit in one instance with a replica? If yes, Sentinel is the default: one primary, one replica, three small Sentinels, a client library that understands them. Is the workload CPU-bound in a way a second Redis process would fix? If yes, and the data still fits, sharding may be worth the complexity.

• Data < 50% of RAM with replica → Sentinel, three Sentinels on loopback with distinct ports.
• Data > 50% of RAM → resize the VPS; cluster does not add memory.
• CPU-bound above 100k ops/s → benchmark sharding before committing.
• Testing a multi-host topology → cluster, but accept it is a staging exercise.

Reserve cluster for the point where the data or the write rate genuinely exceeds one machine. On a single VPS running multiple services, the memory you reclaim from skipping the bus and slot bookkeeping is usually better spent on the application that reads from Redis.