Valkey Performance Benchmarks: Ops/Sec and Latency (2026)

Valkey’s performance isn’t just about how fast it can crunch numbers; it’s about how gracefully it handles those numbers under pressure.

Let’s see Valkey in action, specifically focusing on redis-benchmark, the go-to tool for stress-testing Valkey instances. We’ll simulate common operations like SET and GET to see what kind of throughput and latency we can achieve.

# Run a basic benchmark for SET operations
redis-benchmark -t SET -n 100000 -c 50

# Run a basic benchmark for GET operations
redis-benchmark -t GET -n 100000 -c 50

# Run a benchmark with mixed GET and SET operations (50/50 split)
redis-benchmark -t GET,SET -n 100000 -c 50

When you run these commands, you’ll see output that looks something like this:

SET: 100000 requests processed in 2.500000 seconds
SET: 40000.00 requests per second
SET: 25.00 milliseconds per request

This output tells us two critical things:

• Operations Per Second (Ops/Sec): This is the raw throughput. How many commands can Valkey execute in one second? Higher is generally better.
• Latency (ms per request): This is the responsiveness. How long does it take, on average, for Valkey to process a single command? Lower is always better.

The interplay between these two metrics is where the real story of performance lies. You can have an instance that churns out millions of ops/sec, but if each operation takes 500ms, it’s practically useless for real-time applications. Conversely, an instance with sub-millisecond latency that can only handle 1,000 ops/sec might be fine for a low-traffic service, but will buckle under load.

The Mental Model: Valkey as a Busy Waiter

Imagine Valkey is a waiter in a bustling restaurant.

• Ops/Sec is how many customers the waiter can serve (take orders, deliver food) in an hour.
• Latency is how long each customer waits from the moment they place their order until they get their food.

If the waiter is super fast (low latency) but the kitchen is slow, they can only serve a few tables (low ops/sec). If the kitchen is lightning fast but the waiter is constantly getting distracted, customers will still be waiting a long time (high latency) even if the waiter is technically moving a lot.

The goal is a waiter who can efficiently move between tables, get orders to a fast kitchen, and deliver food quickly, maximizing the number of tables served per hour while minimizing individual wait times.

The Levers You Control

Several factors influence these metrics:

• Hardware: This is the foundation. Faster CPUs, more RAM, and especially faster network interfaces (10GbE or higher is common for high-performance Valkey) are crucial. Disk I/O is less critical for in-memory Valkey but matters for persistence.
• Valkey Configuration (valkey.conf):
  • maxmemory: If you hit this, Valkey might start evicting keys, which adds overhead.
  • tcp-backlog: Controls the queue size for incoming connections. Too low, and new connections might be rejected under heavy load.
  • maxclients: Limits the number of concurrent connections.
  • appendfsync and save (for persistence): Synchronous writes to disk can dramatically impact performance. Using appendfsync no or appendfsync everysec is generally better for raw throughput than always.
• Network: Latency between your client and the Valkey server is a major factor. Network congestion, MTU mismatches, and inefficient TCP configurations can all add milliseconds.
• Client-side: The efficiency of your client library and how it batches commands can significantly impact observed performance. Using pipelining is essential for high ops/sec.
• Workload: The complexity of the commands you’re running (e.g., LRANGE on a large list takes longer than GET on a small string) and the size of your data (larger keys/values mean more data to transfer and process).

The Real Bottleneck Nobody Talks About

Most benchmarks focus on GET and SET because they’re simple. But real-world applications often involve complex data structures like sorted sets, hashes, and lists, or operations that require iterating over many elements. When you benchmark these, you’ll often find that the network bandwidth between the client and the server becomes the limiting factor. Valkey itself might be able to process thousands of these complex commands per second, but if each command involves transferring megabytes of data, your network connection will saturate first, dramatically lowering your observed ops/sec and increasing latency. This is why understanding your actual workload and testing those specific operations is paramount.

The next step in understanding Valkey performance is exploring how to tune these configurations for specific workloads and how to diagnose performance issues beyond basic benchmarking.