Redis Sentinel vs Redis Cluster: Which Should You Use?

Redis offers two distinct high-availability architectures: Sentinel and Cluster. They solve different problems, and picking the wrong one leads to unnecessary complexity or limitations down the line.

This guide breaks down when to use each, how they work under the hood, and the trade-offs you need to consider.

The Short Answer

Use Redis Sentinel if you need high availability for a single dataset that fits in memory on one server. Sentinel monitors your Redis instances and handles automatic failover when the primary goes down.

Use Redis Cluster if you need to shard data across multiple nodes because your dataset is too large for a single server, or you need write throughput beyond what one node can handle.

Most applications should start with Sentinel. It's simpler to operate, easier to debug, and sufficient for the vast majority of caching, session storage, and real-time data use cases.

How Redis Sentinel Works

Redis Sentinel is a monitoring and failover system that runs alongside your Redis instances. It doesn't change how Redis stores data — you still have one primary that handles all writes, with replicas that receive a copy of the data via streaming replication.

The architecture looks like this:

1 Redis primary — handles all reads and writes
1+ Redis replicas — receive replicated data from the primary
3+ Sentinel processes — monitor Redis health and coordinate failover

When the primary fails, Sentinels detect it through regular health checks. Once a quorum of Sentinels agrees the primary is down, they elect a new primary from the available replicas. Clients connected via Sentinel-aware drivers automatically discover the new primary.

Key characteristics of Sentinel

No data sharding — all data lives on every node (primary + replicas)
Single write endpoint — all writes go to one primary
Read scaling — replicas can serve read traffic
Automatic failover — typically completes in 10-30 seconds
Simple client configuration — most Redis clients support Sentinel natively

How Redis Cluster Works

Redis Cluster distributes data across multiple primary nodes using hash slots. The keyspace is divided into 16,384 slots, and each primary node owns a subset of those slots. Each primary can have its own replicas for failover.

The architecture looks like this:

3+ primary nodes — each owns a portion of the hash slot range
1+ replica per primary — provides failover for each shard
No separate coordination — nodes communicate via a gossip protocol

When you write a key, Redis Cluster hashes it to determine which slot (and therefore which node) owns it. Multi-key operations only work if all keys hash to the same slot (you can force this using hash tags like {user:123}.session).

Key characteristics of Cluster

Data sharding — data is distributed across multiple nodes
Multiple write endpoints — each shard handles writes independently
Horizontal scaling — add more shards to increase capacity
Automatic failover — per-shard failover via gossip protocol
Client complexity — clients must handle redirects and hash slot mapping

Side-by-Side Comparison

Feature	Sentinel	Cluster
Data model	Single dataset, fully replicated	Sharded across multiple nodes
Max dataset size	Limited by single server memory	Sum of all shard memory
Write throughput	Single primary bottleneck	Distributed across shards
Failover time	10-30 seconds	Sub-second to seconds
Multi-key operations	Full support	Only within same hash slot
Lua scripts	Full support	Limited to single slot
Transactions	Full support	Limited to single slot
Pub/Sub	Full support	Per-node only (not global)
Client complexity	Low	Higher (redirects, slot mapping)
Operational complexity	Low	Medium-high
Minimum nodes	3 (1 primary + 1 replica + sentinels)	6 (3 primaries + 3 replicas)

When to Choose Sentinel

Sentinel is the right choice for most applications. Use it when:

Your dataset fits on one server. If your data fits in the memory of a single machine (even a large one — cloud servers go up to 256GB+ RAM), Sentinel keeps things simple.
You use multi-key operations. Commands like MGET, SUNION, pipeline batches across keys, and Lua scripts that touch multiple keys work without restriction in Sentinel. In Cluster, these only work within a single hash slot.
You need straightforward Pub/Sub. Sentinel gives you global Pub/Sub across all connected clients. Cluster scopes Pub/Sub to individual nodes.
You're running caching or session storage. These are the most common Redis use cases, and they rarely need the scale-out that Cluster provides.
You want simpler operations. Sentinel has fewer moving parts. Debugging replication issues, managing backups, and understanding data flow is straightforward.

When to Choose Cluster

Cluster makes sense in specific scenarios:

Your dataset exceeds single-server memory. If you need 500GB of Redis data, you can't fit it on one machine. Cluster lets you spread it across multiple nodes.
You need write throughput beyond one node. If a single Redis primary can't keep up with your write volume (rare — Redis handles 100K+ ops/sec per core), Cluster distributes writes.
You can design around hash slot limitations. Your application needs to group related keys using hash tags, and you're comfortable with the constraint that multi-key operations only work within a slot.

Common Mistakes

"We might need to scale later, so let's use Cluster now"

This is premature optimization. A single Redis instance handles enormous workloads. Start with Sentinel, and if you actually hit its limits, migrating to Cluster is a well-documented process. The operational overhead of Cluster isn't worth paying for hypothetical future scale.

"Cluster gives us better failover"

Sentinel failover is plenty fast for most applications (10-30 seconds). If your application can't tolerate 10-30 seconds of Redis being unavailable, you likely need to design for Redis being unavailable regardless of your HA architecture — because network partitions and other failure modes can affect both setups.

"We need Cluster for read scaling"

Sentinel replicas can serve reads too. If you need to distribute read load, add more Sentinel replicas. You don't need Cluster's sharding just for read scaling.

Cost Comparison

A minimal Sentinel setup (3 nodes) costs significantly less than a minimal Cluster setup (6 nodes):

Setup	Hetzner (monthly)	AWS (monthly)
Sentinel (3 nodes, 16GB each)	~$45	~$300
Cluster (6 nodes, 16GB each)	~$90	~$600

With Sentinel, you also get more usable memory per dollar since every node holds the full dataset — you're paying for redundancy, not distribution overhead.

How sshploy Deploys Redis Sentinel

sshploy deploys a production-ready Redis Sentinel setup in under a minute:

Redis primary + replicas across your chosen servers
3 Sentinel processes for quorum-based failover
HAProxy for automatic master routing — your app connects to a single endpoint
Cross-region replicas for geo-distributed reads and disaster recovery
Configurable persistence — RDB, AOF, or both

You configure your topology, point sshploy at your servers, and it handles the Ansible automation, configuration, and networking.

FAQ

Can I migrate from Sentinel to Cluster later?

Yes. The migration involves setting up a new Cluster, migrating data (using tools like redis-cli --cluster or application-level migration), and updating your clients. It's not zero-downtime by default, but it's a well-understood process.

Does Sentinel support SSL/TLS?

Yes. Redis 6+ supports TLS natively, and Sentinel works with TLS-enabled Redis instances. sshploy configures TLS when you enable it.

What happens to writes during a Sentinel failover?

Writes to the old primary after failure detection but before failover completion are lost (Redis replication is asynchronous). The window is typically a few seconds. If you need stronger guarantees, configure min-replicas-to-write and min-replicas-max-lag to reject writes when replicas are too far behind.

How many Sentinels should I run?

Always run an odd number — 3 is standard, 5 for larger deployments. Sentinel needs a majority to agree on a failover, so 3 Sentinels can tolerate 1 failure, 5 can tolerate 2.

Is Valkey a better alternative to both?

Valkey is a fork of Redis with an open-source license. It supports both Sentinel and Cluster modes with the same trade-offs described in this guide. The architectural decision is the same regardless of whether you run Redis or Valkey.