Valkey 9.1 landed on May 19 with three commands Redis never shipped, a 10% memory reduction that requires zero configuration changes, and a client library now covering C# and PHP — two ecosystems that were, until this week, relying on Redis-compatible clients that were not Valkey-native. Two years after the license split, the gap between Valkey and its predecessor is no longer just a matter of principles. It is technical.
Three Commands That Solve Real Problems
The headline additions are three atomic commands, each targeting a pattern that previously required transaction blocks or multiple round-trips.
HGETDEL reads and deletes one or more hash fields in a single operation. Before 9.1, the equivalent was a MULTI/EXEC block wrapping HGET and HDEL — which is a footgun. Between the GET and the DELETE, another client can modify the field. HGETDEL eliminates that window. The command returns the field values and removes them from the hash atomically, deleting the key entirely when its last field is consumed.
HSET myhash f1 v1 f2 v2 f3 v3
HGETDEL myhash FIELDS 1 f2
# Returns: "v2" (f2 is deleted atomically)
The canonical use case is job queue processing: read a task’s parameters and mark it consumed in one step. Session cleanup, one-time token redemption, and consume-and-remove patterns all fit. See the HGETDEL command reference for full syntax.
MSETEX sets multiple keys with a shared expiration time in a single atomic operation. The previous approach — MSET followed by EXPIRE, or N separate SETEX calls — left a consistency gap. If the process died after MSET but before EXPIRE, keys would persist forever. With MSETEX, all keys get the same TTL or none of them do.
MSETEX 2 session:user1 "{...}" session:user2 "{...}" EX 3600
# Returns: 1 (both keys set, both expire in exactly 1 hour)
Session management is the obvious target, but batch configuration writes and temporary feature flags work just as well. The NX option adds a conditional: the entire operation fails if any of the target keys already exist — useful for distributed lock initialization. Full syntax is in the MSETEX command reference.
CLUSTERSCAN brings unified key iteration to Valkey Cluster deployments. Previously, scanning a cluster required running SCAN on each node independently and merging results. CLUSTERSCAN handles cluster topology internally, supports pattern matching and type filtering, and allows parallel scans across slots. For anyone doing cluster-wide maintenance, audits, or data migrations, this is the command you have been waiting for.
The Memory Numbers Are Worth Paying Attention To
Valkey 9.1 delivers up to 20% memory reduction for strings under 128 bytes — which covers the overwhelming majority of typical cache workloads. Short user IDs, session tokens, feature flag values, JSON blobs under a few dozen bytes: all benefit without touching a single configuration file. Sorted sets get up to 10% reduction via skiplist optimizations. Across mixed workloads, the overall reduction lands around 10%.
On throughput, the redesigned I/O threading model pushes peak performance to 2.1 million requests per second on 512-byte payloads with 9 IO threads and a pipeline depth of 10. The threading redesign alone accounts for up to 17% throughput improvement. Stream operations (XRANGE, XREVRANGE) are up to 30% faster via range hot path optimizations, and string GET throughput is up to 30% higher from an increased string embedding size threshold. None of this requires config changes — it ships as the new default behavior.
“Our goal as a project is to ensure that Valkey delivers new functionality while behaving very predictably.”
Madelyn Olson, Valkey maintainer at AWS
GLIDE 2.4 Reaches C# and PHP
Valkey GLIDE — the official client library written in Rust with language bindings — now covers C# and PHP as of version 2.4. This matters because C# and PHP are massive enterprise ecosystems that were previously using Redis-compatible clients (StackExchange.Redis and PHPRedis respectively) that were never Valkey-native.
For C# developers, Valkey.Glide is API-compatible with StackExchange.Redis v2.8.58. Migration is essentially two steps: swap the NuGet package, run regression tests. For PHP developers, the GLIDE PHP migration guide shows the client mirrors the PHPRedis API — replace your connection initialization and the commands stay the same. Both libraries bring the Rust core’s reliability, built-in connection pooling, client-side caching, and mTLS support. The C# GLIDE repo is already available on NuGet.
The PHP angle is particularly significant. WordPress powers over 43% of the web, and a large portion of production WordPress deployments use Redis for object caching. Native Valkey clients for PHP removes the last friction point for operators who want to migrate those workloads off Redis-licensed infrastructure.
Security Tightened Across the Board
The security changes in 9.1 target multi-tenant deployments and certificate management. Database-level ACLs let administrators restrict user access per database — useful for SaaS applications sharing a Valkey instance across tenants. TLS certificate expiration is now visible via the INFO command, and certificate rotation no longer requires a restart. Lua scripting has been moved into a separately loadable module, which means operators can disable it entirely if their workload does not use scripting — a meaningful reduction in attack surface.
The Practical Takeaway
Valkey 9.1 is not a maintenance release. The three new commands address correctness problems that Redis developers have been working around with MULTI/EXEC blocks. The memory improvements are immediate and configuration-free. GLIDE 2.4 closes the language coverage gap for two major enterprise ecosystems. The fork has matured past its political origins.
The full release notes cover the complete change list, including observability additions (JSON log format, thread usage metrics) and CLI improvements for cluster rebalancing. Separately, Valkey Search 1.2 pulls full-text and vector search into the same system as the cache — worth a separate look if your workload is moving toward AI-adjacent query patterns.













