Redis Sentinel vs Redis Cluster

Redis (and Valkey) give you two very different ways to make a deployment resilient, and the two are constantly confused because both improve availability. The short version: Redis Sentinel keeps a single dataset highly available; Redis Cluster shards that dataset across many nodes so it can also scale. They are alternatives, not layers — you choose one based on whether your data still fits on a single node.

This page explains what each one does, how they differ, when to choose each, and how to connect to either from Java.

Redis Sentinel High availability for one dataset Redis Cluster Sharding + high availability Sentinel × 3 — monitor & fail over Master holds keys A–Z Replica copy of A–Z Replica copy of A–Z One master holds the whole dataset; replicas are full copies. Sentinel promotes a replica on failure — HA, but no sharding. Master 1 shard A–H Master 2 shard I–P Master 3 shard Q–Z replica replica replica Data is split across masters (shards). Each shard has its own replica and built-in failover — HA plus horizontal scale.

What Is Redis Sentinel?

Redis Sentinel is the high-availability system that ships with Redis. You run a small set of Sentinel processes alongside a single master and its replicas. The Sentinels monitor the master, agree by quorum when it has failed, and automatically promote one of the replicas to take its place. Clients discover the current master through Sentinel, so a failover is transparent to your application.

What Sentinel does not do is split your data. Every key still lives on one master, and the replicas are full copies of it. Sentinel gives you failover, not scale.

What Is Redis Cluster?

Redis Cluster takes a different approach. It partitions your keyspace across multiple masters using 16,384 hash slots — a technique known as sharding. Each master owns a slice of the slots and holds only the data for those slots, and each master has its own replica. Because both the data and the read/write load are spread across nodes, the deployment can hold far more than a single machine and serve more throughput.

Redis Cluster also includes failover built in: if a master goes down, its replica is promoted automatically, with no separate Sentinel process involved.

Key Differences

The distinction that matters most is replication versus sharding. Sentinel replicates one dataset for availability; Cluster partitions the dataset for scale, then replicates each partition for availability on top. Everything else follows from that:

  • Scaling. Sentinel is capped by a single node's memory and CPU — replicas add read capacity and redundancy, not room for more data. Cluster grows by adding masters.
  • Failover. Sentinel relies on separate monitoring processes; in Cluster, the masters monitor each other and a replica of a failed master is promoted automatically.
  • Client requirements. A Sentinel-aware client asks Sentinel for the master's address. A cluster-aware client follows MOVED and ASK redirects to the right shard and needs hash tags to keep multi-key operations on a single slot.
  • Complexity. Sentinel is simpler to run and reason about; Cluster adds slot management, redirects, and multi-key constraints.

Redis Sentinel vs Redis Cluster: Side-by-Side

Redis SentinelRedis Cluster
PurposeHigh availability for a single datasetHorizontal scaling + high availability
Data shardingNo — one master holds every keyYes — keys partitioned across masters via 16,384 hash slots
Horizontal scalingNo — bounded by one nodeYes — add masters to grow capacity and throughput
FailoverSeparate Sentinel processes promote a replicaBuilt in — a replica is promoted automatically (no Sentinel needed)
MastersOne (plus replicas)Multiple (three or more), each owning a slot range
Data capacityLimited to a single nodeCombined capacity of all masters
Client requirementsSentinel-aware (discovers master via Sentinel)Cluster-aware (follows MOVED/ASK; hash tags for multi-key ops)
Operational complexityLowerHigher
Best forData fits one node; you need failoverData or throughput outgrows one node

When to Use Redis Sentinel

Choose Sentinel when your entire dataset comfortably fits on one node and your goal is simply to survive a node failure. It is the right tool when you want high availability without the operational overhead of sharding — typical of caches, session stores, and most small-to-medium workloads. You get automatic failover, you keep the simplicity of a single master, and any Sentinel-aware client handles the rest.

When to Use Redis Cluster

Choose Cluster when your data or throughput has outgrown a single node. If you cannot fit everything in one machine's memory, or a single master can no longer keep up with your request volume, Cluster's sharding is what you need — it scales horizontally by adding masters and still gives you failover per shard. The price is added complexity: cluster-aware clients, hash-tag discipline for multi-key operations, and more nodes to operate.

A simple rule of thumb: start with Sentinel, and move to Cluster when one node is no longer enough.

Do You Need Sentinel With Redis Cluster?

No — and this is the most common point of confusion. Redis Cluster has its own failover mechanism built in, so you do not run Sentinel on top of a cluster. The two are mutually exclusive choices:

  • A non-sharded deployment (one master plus replicas) uses Sentinel for failover.
  • A sharded deployment uses Cluster, which already includes failover.

If you are on Sentinel today and later outgrow one node, the path forward is to migrate to Cluster — not to bolt Cluster onto Sentinel.

Connecting to Sentinel or Cluster From Java

Whichever topology you choose, the application-side story with Redisson is almost identical — the difference is a single configuration method.

For Sentinel:

Config config = new Config();
config.useSentinelServers()
      .setMasterName("mymaster")
      .addSentinelAddress("redis://127.0.0.1:26379");
RedissonClient redisson = Redisson.create(config);

For Cluster:

Config config = new Config();
config.useClusterServers()
      .addNodeAddress("redis://127.0.0.1:7000", "redis://127.0.0.1:7001");
RedissonClient redisson = Redisson.create(config);

From there your application code is the same on both — the same 50+ distributed objects and the same Sync/Async/Reactive/RxJava3 APIs:

RMap<String, String> map = redisson.getMap("sessions");
map.put("user:42", "active");

Redisson handles failover transparently in either mode: it discovers the topology, follows a Sentinel promotion or a Cluster slot failover, and reconnects on its own. That symmetry also makes migration low-risk — moving from Sentinel to Cluster (or to a Valkey Cluster) is largely a configuration change, not an application rewrite. See the step-by-step guides for connecting to Redis Sentinel in Java and connecting to Redis Cluster in Java, plus the walkthrough on migrating from Redis Cluster to Valkey Cluster.

Frequently Asked Questions

When Should I Use Redis Sentinel vs Redis Cluster?

Use Sentinel when your data fits on one node and you only need automatic failover. Use Cluster when your data or throughput outgrows one node and you need to shard across multiple masters.

Does Redis Cluster Need Sentinel?

No. Redis Cluster has built-in failover, so Sentinel is neither required nor used with it. Sentinel is for non-sharded deployments — a single master with replicas.

What Is Sentinel Mode in Redis?

Sentinel mode runs Redis as a monitoring process rather than a data node. Sentinels watch a master and its replicas, detect failure by quorum, and promote a replica automatically.

When Should I Use Redis Cluster Mode?

Enable Cluster mode when a single node can no longer hold your dataset or serve your request volume — Cluster shards data across multiple masters to scale horizontally.

Is Redis Sentinel High Availability?

Yes. Sentinel provides high availability through monitoring and automatic failover, but it does not provide sharding or horizontal scaling.