How High Can Redis Really Scale? Real-World QPS Limits Explained

Redis QPS Overview

Redis performance is often expressed in queries per second (QPS). The achievable QPS depends on the deployment mode, hardware, command mix, and configuration.

1. Single‑node, single‑thread limits

On a typical cloud or physical server with default settings, a single Redis instance handling simple GET / SET operations on small string keys can sustain roughly 100 k–200 k QPS . This range assumes:

One I/O thread (the default).

CPU cores are not saturated by other workloads.

Network latency is low (e.g., within the same data‑center).

When the io-threads option is enabled (commonly 4–8 threads) and the client opens many concurrent connections, the same workload can reach 200 k–500 k QPS , with some stress‑test results exceeding 700 k QPS.

2. More complex data structures

Operations on richer data types such as ZSET, LIST, or HASH involve additional CPU work. In practice these workloads typically achieve 60 k–100 k QPS on a single node.

3. Example configuration for higher single‑node throughput

# Example Redis 7.x configuration snippet
# Enable multithreaded I/O (4 threads)
io-threads 4
# Increase the number of client connections allowed
maxclients 100000
# Tune TCP backlog and keepalive for low‑latency networks
tcp-backlog 511
tcp-keepalive 60
# Use a small maxmemory policy if the dataset fits in RAM
maxmemory 8gb
maxmemory-policy allkeys-lru

These settings are a starting point; actual performance should be validated with a benchmark tool (e.g., redis-benchmark or memtier_benchmark) that mimics the target command mix and concurrency level.

Redis Cluster / Sharding Capacity

When a single node cannot meet the required throughput, horizontal scaling with Redis Cluster is the standard approach. Data is sharded across N master nodes, each handling a subset of the key space.

In an ideal scenario the total cluster QPS grows roughly linearly with the number of shards:

10‑node cluster → ~1 M QPS (10 × 100 k QPS per node).

100‑node cluster → ~10 M QPS.

Real‑world deployments must consider the following factors that can reduce the theoretical throughput:

Shard imbalance: Uneven key distribution leads to hot masters.

Cross‑slot requests: Commands that involve multiple keys in different slots incur extra network hops.

Resharding overhead: Adding or removing nodes triggers data migration, temporarily consuming bandwidth and CPU.

Client‑side sharding strategy: Libraries that compute hash slots incorrectly can generate unnecessary cross‑slot traffic.

Network topology: Latency between cluster nodes and between clients and nodes caps achievable QPS.

Typical production clusters use the following practices to approach the linear scaling target:

Allocate dedicated network interfaces for intra‑cluster traffic.

Enable io-threads on each master (and optionally on replicas).

Deploy a sufficient number of replicas for read‑scaling while keeping write load on masters.

Monitor key distribution with CLUSTER KEYSLOT and rebalance when hot spots appear.

Practical Guidance

To evaluate the QPS limits for a specific workload:

Identify the command mix (percentage of GET / SET vs. complex data‑type commands).

Select appropriate hardware (CPU cores, RAM, network bandwidth).

Configure io-threads if the kernel and Redis version support it.

Run a benchmark that matches the expected concurrency level (e.g., 100 k concurrent clients).

Observe CPU, memory, and network utilization; adjust maxclients and tcp-backlog as needed.

If the measured QPS approaches the single‑node ceiling, consider scaling out with Redis Cluster.

By following these steps and accounting for the listed caveats, engineers can reliably estimate whether a single Redis instance suffices or a sharded cluster is required to meet their performance targets.