Last checked and updated on 01 Jun 2026
What Is New in Valkey 9.0
| Category | Highlights |
|---|---|
| New Features | Hash field expiration (HSETEX / HGETEX family); atomic slot migration in cluster mode; multi-database support in cluster mode; DELIFEQ command; GEOSEARCH BYPOLYGON option; MPTCP support for server and replicas; dynamic io-threads reconfiguration; TLS certificate-based automatic client authentication; SHUTDOWN SAFE option; extended CLIENT command filtering with negative filter support |
| Improvements | Broad SIMD acceleration (AVX512, ARM NEON) for BITCOUNT, HyperLogLog, hash table lookups, and string-to-integer conversion; background RDB save on replicas; direct response writing to clients; dynamic hashtable shrinking; improved ZCOUNT, SCAN family, and GEORADIUS performance; replication traffic prioritization on replicas; LTTng tracing support; cluster link connection rate limiting; RDB analysis reports in valkey-cli |
| Bug Fixes | Lua VM crash after FUNCTION FLUSH ASYNC + FUNCTION LOAD; memory corruption in sharded pubsub; use-after-free during active expiration with hashtable shrink; crash during TLS handshake with I/O threads; double MOVED reply on unblock at failover; HSETEX FXX incorrectly creating keys; memory leak with CLIENT LIST/KILL duplicate filters; invalid memory access during safe hashtable iteration |
| Breaking Changes | AUTH check is now evaluated before command existence, arity, and protected-mode checks; error messages inside MULTI/EXEC now include the full command name |
What does hash field expiration mean for Valkey 9.0 and how do you use it?
Hash field expiration is one of the most anticipated data-model additions in Valkey 9.0 -- individual fields inside a hash can now carry their own TTL without requiring a separate key per field or a sorted-set workaround. The feature is exposed through the new HSETEX command family and the matching HGETEX / HTTL / HPERSIST commands.
In practice this removes a very common application-side pattern where teams would mirror hash fields into a sorted set keyed by expiry time and run a background sweeper. That workaround was error-prone and added write amplification. Native field expiration handles eviction inside the server with no extra round-trips.
Watch out for the FXX flag semantics: HSETEX with FXX will not create a field if it does not already exist -- a bug fix included in the GA release tightened this behavior, so existing RC1/RC2 clients that relied on the old incorrect behavior need to be updated.
# Set field "session" with a 300-second TTL
HSETEX user:1001 300 session "abc123"
# Read the field and reset its TTL atomically
HGETEX user:1001 EX 300 FIELDS 1 session
# Inspect remaining TTL on a field
HTTL user:1001 FIELDS 1 sessionHow does atomic slot migration improve Valkey cluster operations?
Atomic slot migration replaces the old two-phase (MIGRATING / IMPORTING) model with a single atomic operation that transfers an entire slot -- all its keys -- in one coordinated step, eliminating the window during which a slot exists in a half-migrated state.
The old approach meant that a crash or network partition mid-migration could leave a slot in an inconsistent state requiring manual intervention via CLUSTER SETSLOT. With atomic migration the operation either completes or is rolled back cleanly, making resharding far safer in production clusters running rolling maintenance windows.
Two companion fixes land alongside this feature in the GA release: incorrect slot accounting after a completed atomic migration is corrected, and a crash when aborting a slot migration while a child snapshot is active is resolved. Most teams running cluster mode on 8.x should plan to test resharding workflows after upgrading.
What SIMD performance improvements does Valkey 9.0 deliver?
Valkey 9.0 ships the most aggressive round of SIMD acceleration in the project's history, targeting both x86 (AVX512) and ARM (NEON) platforms across several hot paths. The changes are transparent -- no configuration is required -- but the throughput gains are measurable under load.
Key areas optimized:
- BITCOUNT -- AVX512 on x86 and NEON on ARM, with separate PRs for each architecture
- HyperLogLog commands -- ARM NEON vectorization reduces merge and count latency
- Hash table lookups -- SIMD bucket scanning speeds up key lookups at high load
- String-to-integer conversion -- AVX512 path with a load-time IFUNC resolver so the binary selects the best code path automatically at startup
- SCAN / SSCAN / HSCAN / ZSCAN -- internal list replaced with a vector, reducing allocations per call
- ZCOUNT -- rank calculation merged with range search, halving traversal work
This matters most on cache-heavy workloads where BITCOUNT, HyperLogLog, and scan operations run frequently. Benchmarks on ARM Graviton and x86 Ice Lake chips show meaningful throughput improvement without any application changes.
What cluster and replication improvements does Valkey 9.0 include?
Valkey 9.0 delivers several cluster reliability and operational improvements that reduce the toil of running large deployments. Multi-database support is now available in cluster mode, removing one of the last feature gaps between standalone and clustered deployments.
Additional cluster improvements worth noting:
- CLUSTER REPLICATE NO ONE -- a replica with no data can now be promoted directly to a primary, useful for bootstrapping new primaries without a full sync
- CLUSTER FLUSHSLOT -- new command to explicitly flush all keys in a given slot, handy during topology changes
- Manual failover on SIGTERM -- cluster primaries now attempt a graceful manual failover on shutdown, minimizing unavailability during rolling restarts
- cluster-manual-failover-timeout -- new config knob to control how long the node waits for a failover to complete before proceeding with shutdown
- Cluster link connection rate limiting -- new connections per event loop cycle are now capped, preventing gossip storms during large cluster reforms from starving client I/O
On the replication side, replicas now save RDB snapshots to disk using a background thread, keeping the main event loop free during full sync. Replication traffic is also deprioritized relative to client traffic on replicas -- previously a heavy replication stream could starve read clients on replica nodes.
What behavior changes and new commands should operators know about in Valkey 9.0?
Valkey 9.0 includes a small number of behavior changes that can surface as unexpected errors if clients send malformed or unauthenticated requests. The AUTH check order has changed: authentication is now validated before command existence and arity checks. This means unauthenticated clients will always receive NOAUTH, never a command-not-found or wrong-arity error -- a cleaner and more secure default.
Error messages within MULTI/EXEC blocks now include the full command name (e.g., OBJECT ENCODING instead of just OBJECT), which improves debuggability but may require updates to test harnesses that match error strings exactly.
Two new commands worth adding to your runbooks:
- DELIFEQ key value -- deletes a key only if its current value equals the provided value, a true atomic compare-and-delete useful for lock release patterns without Lua
- SHUTDOWN SAFE -- rejects a shutdown request if the node is in an unsafe state (e.g., the only copy of data with no replica), preventing accidental data loss during operational scripts
MPTCP (Multipath TCP) support is now available for both client-to-server and replica-to-primary connections, configurable via MPTCP in the bind directive. This matters if your infrastructure uses multi-homed hosts and you want to take advantage of bandwidth aggregation or failover at the TCP layer.
Frequently Asked Questions about Valkey 9.0
Is Valkey 9.0 backward compatible with existing Valkey 8.x clients and data?
Yes, Valkey 9.0 is backward compatible with 8.x clients at the protocol level. The main behavior changes -- AUTH check ordering and MULTI/EXEC error message format -- only affect clients that rely on specific error message strings or intentionally send unauthenticated commands to probe for command availability.
How do I enable hash field expiration in Valkey 9.0?
No configuration is needed. The feature is available as soon as you upgrade. Use HSETEX to set a field with a TTL in seconds, HPEXPIRE for milliseconds, HTTL to query remaining TTL, and HPERSIST to remove a field TTL. For example: HSETEX mykey 60 field1 value1 sets field1 to expire in 60 seconds.
Does Valkey 9.0 require any configuration changes when upgrading from 8.x?
For most deployments no changes are required. Operators running cluster mode who want multi-database support need to enable it explicitly. Teams using custom TLS setups should review the new automatic client authentication via TLS certificate fields if they want to simplify their auth pipeline. The new cluster-manual-failover-timeout and auto-failover-on-shutdown configs are optional but recommended for production clusters.
Will the SIMD optimizations in Valkey 9.0 work on my hardware automatically?
Yes. The AVX512 string-to-integer path uses a load-time IFUNC resolver that detects CPU capabilities at startup and selects the optimal code path. ARM NEON paths are compiled in when building for aarch64. No flags or environment variables are needed -- the server picks the best available implementation automatically.
What is atomic slot migration in Valkey 9.0 and how does it differ from the old approach?
Atomic slot migration moves all keys in a cluster slot in a single coordinated operation rather than the old two-phase MIGRATING/IMPORTING handshake. This eliminates the half-migrated state that previously required manual recovery after a crash mid-migration. Use CLUSTER MIGRATE with the new atomic flag; the GA release also fixes a crash that could occur when aborting a migration while a child snapshot was in progress.
What is the DELIFEQ command and when should I use it instead of a Lua script?
DELIFEQ key value deletes a key only if its current string value matches the provided value, all in a single atomic operation. It is the preferred replacement for the common Lua compare-and-delete lock release pattern because it avoids Lua overhead and is fully compatible with cluster mode without needing to route a EVAL call. A typical use is: DELIFEQ lockkey my-unique-token, which releases the lock only if this client still holds it.