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

What Is New in Valkey 8.1

Valkey 8.1 is a minor version release with upgrade urgency LOW, meaning it is fully compatible with all previous Valkey releases and Redis OSS 7.2.4. The focus areas are performance, observability, cluster reliability, and developer usability -- with no breaking changes that require migration effort for most production deployments.

How does the new hash table implementation improve performance in Valkey 8.1?

Valkey 8.1 ships a fully redesigned internal hash table that replaces the legacy dict structure across all core data types -- including hashes, sets, and sorted sets -- with a more memory and cache-efficient implementation. The new table reduces pointer indirection, embeds hash values directly in hash data type entries, and integrates prefetching during iteration to make full-scan operations (HSCAN, SSCAN, KEYS) significantly faster.

In practice, deployments with large keyspaces or frequent full-scan operations will see the most benefit. The embedded hash value optimization alone reduces per-entry memory overhead, which compounds on instances storing millions of hash fields. The prefetch-accelerated iterator means iterator-heavy workloads -- like background TTL sweeps or SCAN-based migrations -- generate fewer CPU cache misses.

# No config change needed -- the new hash table is used automatically.
# You can verify memory improvement after restart with:
INFO memory
# Look for: used_memory_human, mem_allocator

Watch out for the Streams data type, which now uses an additional 8 bytes per stream to track internal size. On deployments with millions of stream keys, this slightly increases memory usage -- factor this into capacity planning.

What is COMMANDLOG and how does it differ from SLOWLOG in Valkey 8.1?

COMMANDLOG is a new built-in observability feature in Valkey 8.1 that records slow command executions AND large request/reply payloads -- two dimensions that SLOWLOG alone cannot cover. Most teams discover oversized payloads only when they cause network or memory issues; COMMANDLOG surfaces them proactively through configurable thresholds.

You configure COMMANDLOG with dedicated thresholds for execution time, request size, and reply size. This is particularly valuable in environments where a client is accidentally sending multi-megabyte payloads that are fast to execute but expensive to serialize and transfer.

# Example: enable COMMANDLOG for commands slower than 10ms
# or with requests/replies larger than 1MB
commandlog-execution-slower-than 10000
commandlog-request-larger-than 1048576
commandlog-reply-larger-than 1048576

# Inspect the log at runtime:
COMMANDLOG GET
COMMANDLOG LEN
COMMANDLOG RESET

This matters if you are running shared Valkey instances across multiple application teams and need to attribute latency to specific callers without relying entirely on application-side instrumentation. Combined with the extended CLIENT LIST (which now shows client capabilities and import-source flags), tracing the offending client is much faster.

What cluster failover and reliability improvements ship in Valkey 8.1?

Valkey 8.1 significantly tightens cluster failover behavior, reducing both failover time and the probability of election conflicts under real-world network conditions.

• Ordered elections: Replicas now elect based on failed primary rank, preventing simultaneous votes that delay convergence.
• Immediate forced failover: Manual failover triggers an election as soon as possible and resets any on-going election to avoid interference.
• No two-times-node-timeout cap: Both manual and automatic failover votes are no longer capped at twice the node timeout, allowing faster recovery when the cluster is under load.
• Configurable manual failover timeout: The new cluster-manual-failover-timeout config gives operators explicit control over how long a manual failover waits before aborting.
• Faster epoch propagation: Config epochs are now broadcast immediately on change, and a PONG is sent to all nodes when a role changes -- reducing the window where stale topology causes misrouted commands.
• TCP_NODELAY on cluster connections: Engine-initiated cluster and replication connections now enable TCP_NODELAY, reducing latency on small packet exchanges (gossip, replication heartbeats).

In practice, teams running Valkey Cluster in AWS or similar multi-AZ environments will see faster automatic recovery from primary failures. The ordered election change is especially impactful in clusters with 6 or more nodes where voting contention was previously common.

What new API and configuration options does Valkey 8.1 add for operators?

Valkey 8.1 adds several quality-of-life improvements to commands and configuration that reduce the number of workarounds operators have to maintain in production scripts.

SET IFEQ -- conditional check-and-set for strings: The SET command gains a new IFEQ argument that performs a conditional update only if the current value matches a provided comparison value. This is a native check-and-set (CAS) pattern for STRING keys, removing the need for Lua-based CAS scripts in many use cases.

# Set "newvalue" only if current value equals "expectedvalue"
SET mykey newvalue IFEQ expectedvalue

# Returns OK on success, or nil if the condition does not match

BGSAVE CANCEL: You can now cancel an in-progress background save with BGSAVE CANCEL. This is useful when a BGSAVE was triggered unintentionally or is consuming too much I/O during a traffic spike.

import-mode config: The new import-mode configuration disables key expiration and eviction during data import/sync operations -- preventing data loss when importing datasets that contain keys with TTLs already in the past.

rdb-version-check: The new rdb-version-check config allows relaxed RDB version verification, useful when restoring backups across minor version boundaries in controlled environments.

log-format and log-timestamp-format: Log output format is now configurable, which simplifies integration with structured log pipelines (e.g., JSON-based log aggregators).

Deprecations to clean up: io-threads-do-reads is deprecated because I/O threads now always handle reads. dynamic-hz is deprecated because adaptive server cron scheduling is now the default. Both configs are safe to remove from your valkey.conf.

What critical bugs were fixed in Valkey 8.1 that affect production stability?

Several of the bug fixes in Valkey 8.1 address conditions that could cause crashes or hangs in production environments -- not just edge cases in test setups.

• ACL LOAD crash on replicas: Running ACL LOAD on a connected replica could crash the node. This affects any deployment where ACL rules are reloaded without a restart -- a common pattern in dynamic multi-tenant environments.
• RANDOMKEY infinite loop: When all clients were paused (e.g., during a CLIENT PAUSE) and all keys had expiry, RANDOMKEY could enter an infinite loop. This is now fixed.
• rax crash with large keys: Keys larger than 512MB caused a crash in the rax internal data structure. While rare in normal use, this could be triggered by misbehaving clients.
• TLS replica disconnection: Replicas using TLS could intermittently disconnect during replication. Deployments with TLS-encrypted replication should prioritize this upgrade.
• File descriptor leak in dual-channel replication: Aborting dual-channel replication on error leaked file descriptors, eventually exhausting the process FD limit on busy primaries.
• Lua cjson OOM: A unicode optimization in the bundled Lua cjson library could cause out-of-memory errors when processing very large strings in Lua scripts. The optimization has been removed.
• Module API crash: VM_GetCurrentUserName crashed when called with no valid username -- a regression that affected custom modules relying on username introspection.