Valkey 8.0: What's New, Release History & Support Lifecycle

What Does Async I/O Threading Mean for Valkey 8.0 Throughput?

Valkey 8.0 introduces async I/O threading, meaning network reads and writes can now be offloaded from the main event loop to dedicated I/O threads, giving the server significantly more headroom under high concurrency. This is one of the most impactful changes in this release for teams running Valkey on multi-core machines.

In practice, this does not change the single-threaded command execution model. Commands are still processed sequentially on the main thread. What changes is that the cost of moving bytes to and from clients is distributed across threads, which is often the actual bottleneck under high connection counts or large value sizes.

To enable I/O threading, configure the number of I/O threads in your valkey.conf:

# valkey.conf
io-threads 4
io-threads-do-reads yes

Watch out for over-provisioning threads. On a 4-core host, setting io-threads to 8 typically hurts more than it helps due to context switching overhead. A good starting point is (number of physical cores / 2), then benchmark your actual workload.

How Does Dual-Channel Replication Improve Full Sync in Valkey 8.0?

Valkey 8.0 introduces a dual-channel replication path that separates the RDB snapshot transfer from the replication backlog, allowing replicas to receive live write commands during a full sync instead of buffering them entirely on the primary. This directly reduces the risk of backlog overflow and primary memory pressure during large or slow full syncs.

Most teams running large datasets with busy write rates have encountered the painful scenario where a full sync causes the replication buffer to overflow, forcing yet another full sync in a loop. Dual-channel replication addresses the root cause by streaming replication commands on a separate channel while the RDB is still being transferred.

This feature is enabled by default and requires no configuration change. Replicas must be running Valkey 8.0 or later to negotiate the dual-channel protocol; older replicas fall back to the traditional single-channel path transparently.

What Is the New CLUSTER SLOT-STATS Command in Valkey 8.0?

CLUSTER SLOT-STATS is a new command that exposes per-slot metrics including key count, CPU utilization, network bytes in, and network bytes out, giving operators visibility into hot slot patterns that were previously invisible without external instrumentation.

This matters if you are running a Valkey cluster and have suspected uneven load distribution but lacked the data to confirm it. With CLUSTER SLOT-STATS, you can now pinpoint exactly which hash slots are receiving the most traffic, identify which keys are mapping to those slots, and rebalance your key design or sharding strategy accordingly.

CLUSTER SLOT-STATS SLOTSRANGE 0 16383

The command supports filtering by slot range and returns structured data suitable for scraping into your monitoring pipeline. Teams using Prometheus can pull this data periodically and alert on outlier slots before they cause latency spikes or OOM conditions.

What Behavior Changes in Valkey 8.0 Could Break Existing Applications?

Valkey 8.0 ships several behavior changes that teams should validate in staging before promoting to production. The most operationally significant is that BITCOUNT and BITPOS now return errors for non-existing keys instead of returning zero, which is a silent semantic change that can break application code relying on the old default-zero behavior.

• BITCOUNT / BITPOS on missing keys: Previously returned 0. Now returns an error. Review any code paths that call these commands without a prior EXISTS check.
• Nested MULTI / WATCH: Calling MULTI or WATCH inside an open transaction now aborts the transaction immediately. This closes a long-standing ambiguity but may affect client libraries that issue WATCH defensively.
• Replica flush on RDB load: Replicas now flush old data only after validating the incoming RDB file rather than before. This prevents partial data loss if the primary crashes mid-transfer but changes the window during which old data is visible on the replica.
• pidfile and syslog-ident defaults: Default pidfile is now valkey.pid and syslog-ident is valkey. Any init scripts, systemd units, or log parsers referencing the old redis.pid or redis syslog identity will need updating.
• Sentinel config rename: The sentinel.conf option master-reboot-down-after-period has been renamed to primary-reboot-down-after-period. Old configs must be updated before restarting sentinel nodes.

What Memory and Command-Level Performance Improvements Ship in Valkey 8.0?

Valkey 8.0 delivers a broad set of micro-optimizations that compound into meaningful gains at production scale. The headline numbers are a 41% improvement for SUNION and a 27% improvement for SDIFF, achieved by optimizing how temporary set objects are allocated and freed during those operations.

Below the surface, the release also embeds dictionary keys directly in the main hash table entry structure, eliminating a pointer indirection that previously added allocation overhead for every key stored. Combined with a shared query buffer for client reads -- meaning multiple clients share a single allocated buffer rather than each maintaining their own -- memory fragmentation under high connection counts is noticeably reduced.

Additional wins include:

• Thread-local storage for memory metric updates reduces atomic operations on hot paths.
• CRC64 computation is parallelized for large batches, improving RDB save and replication throughput.
• ZRANGE now uses skip list jumps to locate offsets rather than linear traversal, benefiting large sorted sets.
• CLUSTER SLOTS responses are cached, reducing CPU overhead for topology-heavy client libraries.
• Per-client network and command metrics are now exposed in CLIENT LIST and CLIENT INFO, enabling precise traffic attribution without external proxies.