Memorystore for Valkey 9.1 Targets Higher Throughput and Lower Latency

Caching systems sit on the critical path of many applications. They store frequently accessed data, manage sessions, support leaderboards, coordinate background jobs, and reduce the number of requests that reach a primary database. When a cache becomes a bottleneck, even small improvements in command processing can affect application throughput and response times.

Google Cloud Memorystore for Valkey now supports Valkey 9.1, which became generally available in the managed service on September 24, 2026. The release includes internal optimizations to I/O threading and string handling that can increase overall throughput by up to 17% and GET throughput by up to 30%, according to Google Cloud's documentation. <Cite refs={["turn836163search0","turn836163search1"]}/>

Valkey 9.1 also introduces database-level access control through access control lists (ACLs), along with commands such as HGETDEL, MSETNX, and CLUSTERSCAN.

For developers and platform engineers, the release provides two reasons to evaluate an upgrade: performance improvements for read-heavy workloads and additional capabilities for applications that need more precise access control or atomic data operations.

However, these improvements are not automatic guarantees of lower end-to-end latency. The results depend on the workload, command mix, connection behavior, data size, and existing infrastructure configuration.

What Is Memorystore for Valkey?

Memorystore for Valkey is Google Cloud's managed service for running Valkey, an open-source in-memory data store compatible with the Redis OSS protocol.

Applications use it for workloads that benefit from fast access to data without repeatedly querying a primary database. Common examples include:

• Caching database query results and frequently accessed application data.

• Storing temporary session information.

• Maintaining counters, rankings, and leaderboards.

• Supporting queues and lightweight coordination patterns.

• Performing selected data operations close to the application.

Because the service is managed, teams do not need to operate the underlying Valkey infrastructure themselves. They still need to design their data structures, configure access, manage connections, monitor performance, and plan upgrades.

Valkey 9.1 adds capabilities to the existing service rather than changing the fundamental role of a cache or in-memory data store.

Valkey 9.1 Performance Improvements

The main performance changes in Valkey 9.1 focus on internal I/O threading and string handling.

Google Cloud documents potential improvements of up to 17% in overall throughput and up to 30% for GET operations. These are maximum reported gains, not guaranteed improvements for every instance or application.

More throughput for read-heavy workloads

A read-heavy workload repeatedly retrieves cached values. Examples include product catalog lookups, session retrieval, configuration reads, and frequently requested reference data.

The improved GET throughput can be particularly relevant when an application sends a large number of small read operations.

Consider an application that retrieves user preferences from Valkey on nearly every request. If the cache is approaching its processing limit, additional command throughput could allow the same infrastructure to serve more operations.

However, the actual benefit depends on where the bottleneck exists. If the application is limited by network round trips, connection-pool contention, client-side serialization, or another downstream dependency, faster command processing alone may not substantially improve response time.

Better overall command processing

I/O threading and string-handling optimizations can also benefit workloads beyond simple reads, depending on the operations they execute.

A cache workload that mixes reads, writes, and other commands should be evaluated using its actual command distribution. A benchmark dominated by GET operations may not represent an application that spends substantial time updating hashes, maintaining counters, or running scripts.

Measure both throughput and latency percentiles before deciding whether the upgrade provides enough benefit to justify the operational work.

New Commands in Valkey 9.1

The release adds several commands that can simplify common data operations. Their availability can reduce application-side work, but each command should be used according to its documented semantics.

HGETDEL: Retrieve and Delete a Hash Field Atomically

The HGETDEL command retrieves a field's value from a hash and deletes that field as a single atomic operation.

This can be useful when an application needs to consume a value once and remove it from the data structure.

For example, consider a hash storing temporary processing tokens:

HSET processing:job-1042 token "abc123"
HGETDEL processing:job-1042 token

The second command retrieves the value of token and removes that field from the hash in one operation.

The example assumes that the hash and field exist. If the field does not exist, the command's documented missing-field behavior applies.

The advantage is that the application does not need to perform a separate read followed by a delete. Separate operations could allow another client to modify the field between the two requests.

Atomic retrieval and deletion can simplify certain workflows, but it is not a substitute for a complete job-processing protocol. If the application needs durable acknowledgments, retries, or guaranteed delivery, it must implement those requirements separately.

MSETNX: Set Multiple Keys Only When They Do Not Exist

MSETNX sets multiple keys only when none of the specified keys already exists.

Valkey 9.1 adds support for assigning a shared expiration time to the keys set by the command. This can be useful when an application needs to create a related group of temporary values with consistent expiration behavior.

For example, an application might store a group of temporary coordination keys that should be created together. Using a command that checks the existence condition atomically can prevent partial creation when one of the keys already exists.

This differs from issuing separate writes and expiration commands, where another client may observe or modify the data between operations.

Before adopting the command, confirm the precise syntax supported by the Valkey version and client library you use. Also consider what should happen when any one of the keys already exists, because the all-or-nothing condition may be important to the application's correctness.

CLUSTERSCAN: Scan Keys Across Cluster Nodes

In a clustered Valkey deployment, data is distributed across multiple nodes. A key scan that covers only one node may not provide a complete view of the cluster.

Valkey 9.1 introduces CLUSTERSCAN, which can scan keys across all nodes of an instance.

This can help with administrative tasks, data inspection, and certain maintenance workflows that need broader visibility across a cluster.

For example, a team investigating keys associated with a particular application namespace might need to inspect matching keys across the entire deployment.

Scanning is not a substitute for an efficient application data model. Avoid using cluster-wide scans as a routine request-path operation, particularly when the dataset is large. For regular application queries, design predictable key access patterns instead.

Database-Level Access Control

Valkey 9.1 also adds database-level access control through ACLs.

Access control is particularly relevant when several applications share an in-memory data store or when different components should have different permissions.

For example, a service that only reads cached product data should not automatically receive permission to delete keys or execute every available command. A background worker that updates selected data may need a different permission set.

Database-level access controls can help enforce these boundaries, subject to the capabilities supported by the managed service and its configured access-control model.

When designing access policies, consider three dimensions:

• Key access: Which keys or key patterns can a client access?

• Command access: Which operations can the client execute?

• Database access: Which databases can the client use?

Start with the minimum access needed by each application. Then test the policy using the actual client library and connection configuration.

Do not assume that introducing ACLs automatically makes a shared cache secure. Network access, authentication, secret management, application identity, and key isolation still need to be configured appropriately.

Upgrade an Existing Memorystore Instance to Valkey 9.1

Memorystore for Valkey supports upgrading an existing instance to a newer engine version. Google Cloud's version-upgrade documentation also warns that an upgraded instance cannot be downgraded to an earlier version. <Cite refs={["turn836163search1","turn836163search5"]}/>

That restriction makes compatibility testing important before changing a production instance.

Step 1: Check the current version

Inspect the instance details in the Google Cloud console or use the Google Cloud CLI.

gcloud memorystore instances describe my-instance \
  --project=my-project \
  --location=us-central1

Replace the example instance name, project, and region with your actual configuration.

Review the reported engine version and the instance's other relevant settings before planning the upgrade.

Step 2: Review client compatibility

Check the application libraries and commands used by your services.

Pay particular attention to applications that use custom command wrappers, Lua scripts, connection pools, or assumptions about older Valkey behavior.

If the application does not need the new commands, the upgrade may still be useful for performance reasons. However, the existing workload should be tested against the new engine version before production rollout.

Step 3: Upgrade the instance

The documented Google Cloud CLI command uses --engine-version to select the target version.

gcloud memorystore instances update my-instance \
  --project=my-project \
  --location=us-central1 \
  --engine-version=VALKEY_9_1

Use the correct instance identifier and region. Confirm that the planned change is supported by the current instance configuration and follow the applicable maintenance and upgrade procedures.

Because downgrading is not supported, establish a recovery plan before applying the change. Depending on the workload, that plan may include tested backups, a compatible migration path, or the ability to rebuild cached data from the authoritative source.

Do not assume that a cache can always be recreated cheaply. Some deployments also hold session state, coordination data, or other information whose loss can affect application behavior.

Benchmark Before and After the Upgrade

The reported maximum throughput gains provide a reason to benchmark Valkey 9.1, but they should not be used as a substitute for workload-specific measurements.

Create a baseline before upgrading. Use a representative dataset, realistic value sizes, the same connection behavior, and a command mix that resembles production.

Measure at least the following:

Run the benchmark long enough to observe steady-state behavior. Include realistic concurrency and avoid comparing results from tests with different data sizes or connection settings.

For read-heavy applications, compare the performance of GET operations. For mixed workloads, measure the complete command distribution rather than extrapolating from read-only results.

A higher maximum throughput does not necessarily mean lower latency at every load level. Under heavy contention, an application can still experience high tail latency even if the engine processes more operations overall.

Common Upgrade Mistakes

Expecting every workload to improve by the published maximum: The reported gains describe potential improvements, not a guarantee for each application. Benchmark the actual workload.

Upgrading without testing clients: Verify that client libraries and command wrappers work correctly with the target engine version.

Assuming the upgrade is reversible: Memorystore does not support downgrading an instance to an earlier version after an upgrade. Plan recovery accordingly.

Using cache commands as a replacement for durable messaging: Atomic commands help with specific data operations, but they do not automatically provide durable queues, acknowledgment protocols, or end-to-end exactly-once processing.

Ignoring security configuration: New ACL capabilities are useful only when permissions, authentication, and network access are configured and tested correctly.

Benchmarking only average latency: Average values can hide p99 latency regressions. Evaluate percentiles and error rates alongside throughput.

Summary

Memorystore for Valkey 9.1 brings performance optimizations, database-level access control, and additional commands to Google Cloud's managed Valkey service.

The release can deliver up to 17% higher overall throughput and up to 30% higher GET throughput under the conditions described by Google Cloud. New commands such as HGETDEL, MSETNX, and CLUSTERSCAN also provide useful capabilities for atomic field operations, conditional multi-key writes, and cluster-wide key scanning.

Before upgrading, check the current engine version, validate client compatibility, benchmark representative workloads, and prepare a recovery strategy. The inability to downgrade makes this preparation particularly important.

For applications that are constrained by cache command processing, Valkey 9.1 is worth evaluating. The right decision should come from measured improvements in throughput, tail latency, reliability, and operational simplicity rather than version numbers alone.