What’s New in Valkey 9.0: Key Features and Improvements

Introduction: The Valkey Project Marches Forward

In the world of in-memory data stores, Valkey has solidified its role as a thriving, community-driven fork of Redis over the past 1.5 years, committed to remaining open source under the Linux Foundation. A broad union of contributors now drives its development, showcasing the power of its collaborative model.

Following our previous analysis of Redis 8.0 vs. Valkey 8.1, which highlighted improvements in both projects, Valkey is set for its next major release, 9.0, which will introduce powerful new features. This release moves beyond core optimizations to deliver a suite of user-friendly capabilities and enhancements. Valkey 9.0 is a clear testament to a healthy, competitive ecosystem that ultimately benefits all users by accelerating the pace of innovation.

Deep Dive on Valkey 9.0’s Key Features

In my opinion, Valkey 9.0 is an incremental update but packed with features that address specific, long-standing challenges for developers and system operators. Let’s break down the key additions and explore why they matter.

Hash Field-Level Expiration: Granular Control Arrives

Until now, expiring data in a hash required setting a TTL on the entire key in Valkey, which was a major limitation. If you had a hash storing user sessions with multiple attributes and wanted to expire only the auth_token after 15 minutes while keeping the rest of the session data, you were out of luck. The common workarounds, such as using separate keys or complex Lua scripts, added overhead and complexity.

Following Redis, Valkey is introducing the ability to expire individual fields within a hash key. This new capability is implemented through commands like HEXPIRE, HSETEX, and others. As demonstrated below, when a user logs in, we can set a token and auto-expire that field within an existing hash:

# The hash stored on 'user:123' may have other user profile or session attributes.
# However, when we set the 'auth_token' field, we want it to expire after 15 minutes.
valkey$> HSETEX user:123 EX 900 FIELDS 1 auth_token "eyJhbGciOiJ..."
(integer) 1

Behind the scenes, this is powered by a sophisticated data structure called volatile set, which efficiently tracks expiring fields without consuming significant memory or degrading the performance of standard hash data type operations. Field-level expiration for hash values enables more straightforward management of use cases like feature flag systems, cached API responses with mixed lifespans, and dynamic user session management.

The DELIFEQ Command: Easier Distributed Locks

Implementing robust distributed locks has always required careful handling, with a core principle being that a client can only release locks it has acquired itself. The traditional solution involves storing a unique random value in the lock and using a Lua script to verify that value before deletion. While this pattern is effective and atomic (forming the basis of algorithms like Redlock), it adds a layer of complexity and overhead.

// Yes, we do need to manage Lua scripts in other programming languages...
//
// https://github.com/go-redsync/redsync -> mutex.go
var deleteScript = redis.NewScript(1, `
	local val = redis.call("GET", KEYS[1])
	if val == ARGV[1] then
		return redis.call("DEL", KEYS[1])
	elseif val == false then
		return -1
	else
		return 0
	end
`)

Valkey 9.0 simplifies this with the introduction of DELIFEQ (delete-if-equal). This built-in command makes the pattern atomic, simple, and script-free by only deleting the key if its current value matches the provided string.

valkey$> SET mylock ca304fec-bdd2-438d-8b69-3f9fa1ef9018
valkey$> DELIFEQ mylock ca304fec-bdd2-438d-8b69-3f9fa1ef9018 # Returns 1, key is deleted.

valkey$> SET mylock ca304fec-bdd2-438d-8b69-3f9fa1ef9018
valkey$> DELIFEQ mylock nope # Returns 0,key remains.

This single command can eliminate a whole class of potential scripting issues (i.e., different libraries may have similar but different scripts for the “compare-and-delete” operation shown above), making lock management both safer and more idiomatic.

MPTCP Support: Boosting Network Resilience

Modern applications demand high availability and efficient data transfer. Valkey 9.0 introduces support for MultiPath TCP (MPTCP), which is an advancement for replication and client connections in supported environments.

Multipath TCP (MPTCP) in the Protocol Stack

MPTCP allows a single TCP connection to use multiple network paths simultaneously. For Valkey replication, this means increased resilience: if one network path fails, the connection can seamlessly continue over another without dropping. It can also aggregate bandwidth, potentially speeding up large data synchronization between nodes. This is a crucial step towards building more robust, fault-tolerant data stores.

Safe Shutdown: Preventing Operational Mistakes

In a Valkey cluster, accidentally shutting down an important primary instance (i.e., a voting primary in a cluster during a failover process) can have catastrophic consequences and potentially cause service disruption. Valkey 9.0 introduces a safe shutdown mode to prevent this.

For example, when a node is sent a SHUTDOWN SAFE command (or started with safe shutdown options), it will refuse to shut down if it is a primary node responsible for at least one slot within a cluster. This simple but powerful safeguard acts as a critical check, preventing an easy-to-make operational error from bringing down a production environment. This can be a feature that system administrators will quickly come to rely on.

Even More to Come

Beyond these features, Valkey 9.0 includes a host of other improvements and advancements, from new commands to performance optimizations under the hood. Moreover, a few cluster-related improvements, such as multi-database support and atomic slot migration, will be included in the new release as well. For a comprehensive list of every new feature, bug fix, and change, we encourage you to keep an eye on the official Valkey 9.0 project board on GitHub and the final release notes when they are published.

The Ecosystem in Focus: A Nod to Dragonfly

The innovations in Valkey 9.0 reflect a healthy, competitive ecosystem where different projects tackle similar challenges in different ways. This parallel development validates user needs while pushing the entire field forward.

The introduction of hash field-level expiration in Valkey 9.0 is a prime example. Dragonfly is one of the first in-memory data stores to support this feature for both hashes and sets by introducing the FIELDEXPIRE command. Later on, similar functionalities are added in Redis and now Valkey, demonstrating that we all recognize field-level expiration as a critical need for modern applications managing complex data with varying lifespans.

However, the ecosystem’s true strength lies in its diversity of innovations. Valkey 9.0 brings unique contributions like the DELIFEQ command for safer distributed locks, which is not available in Dragonfly or Redis yet. This shows how competition drives exploration of different approaches to user problems.

Rather than mere imitation, we’re seeing complementary innovation that benefits everyone. As projects recognize each other’s successes, the entire ecosystem evolves faster, giving developers better tools and more choices for their specific needs.

The Virtuous Cycle of Competition & A Look Ahead

Valkey 9.0 shows how different projects can push the entire ecosystem forward. The project has quickly grown from a fork of Redis into a capable and innovative data store, adding important features that solve real problems for developers and platform engineers. This progress demonstrates that when multiple projects evolve independently, it benefits everyone by accelerating the pace of innovation. The future of in-memory data stores looks promising, with several strong options driving progress in different, valuable ways.

This brings us to a compelling question for the future. Now we’ve seen what Valkey is bringing to the table with its 9.0 release, what’s the next feature you want to see in Dragonfly? Share your thoughts with us on Discord on what you’d like to see next.