Google Cloud has made Memorystore for Valkey 9.1 generally available, claiming up to 3x queries per second (QPS) at microsecond latency compared with Memorystore for Redis Cluster. The post positions Valkey as an open-source alternative backed by Google Cloud and the Linux Foundation after Redis Inc. shifted away from the permissive BSD license in 2024, and it is aimed at organizations running AI and microservices workloads that need high throughput with microsecond response times.

The main performance work in Valkey 9.1 is a rethinking of thread communication. Earlier Valkey assigned client sockets to I/O threads in round-robin fashion, and the main thread continuously polled lists of pending clients. Valkey 9.1 replaces that with a lock-free, multi-queue messaging architecture using three complementary queues: a single-producer multi-consumer (SPMC) queue for main-thread-to-I/O-thread dispatch, allowing free workers to pull tasks via dynamic work-stealing; a multi-producer single-consumer (MPSC) queue for completed tasks returning to the main thread; and single-producer single-consumer (SPSC) queues for thread-affine memory cleanup and high-volume epoll offloading. The post says this eliminates cross-thread CPU waste from busy-wait list iteration. A two-phase dynamic scaling engine is also introduced: when main-thread CPU crosses 30%, the engine activates the first background I/O thread before queue bottlenecks form; then it scales active I/O workers up or down based on real-time SPMC queue backlog, parking extra cores when idle.

On the developer side, Valkey 9.1 adds database-level ACLs alongside existing IAM-based ACL support. Administrators can restrict users to specific numeric databases within the ACL framework, for example production user db=0, staging user db=1, dev user db=2, without key prefixing. The ACL feature includes centralized 1:N policy-to-cluster mapping, least-privilege multi-tenancy, versioned policy revisions, and audit logging. The new CLUSTERSCAN command provides a topology-aware cursor that encodes current slot, local hashtable fingerprint, and local cursor, allowing scans to continue across slot migrations and node failovers. It supports sequential full-cluster scans and parallelized scans using the SLOT argument to partition all 16,384 slots across workers. Mismatching slot and cursor returns an error, and scan completion is signaled by cursor 0. New commands include HGETDEL for atomic fetch-and-delete of a hash field, MSETEX for setting multiple keys with one shared expiration, and HSETEX with NX/XX conditional flags for setting a field only if it does or does not already exist.

The release builds on earlier Memorystore for Valkey 9.0 updates: native JSON support and Bloom filters, plus six new node sizes. Small nodes Custom-Pico (1.25 GB), Custom-Micro (2.5 GB), and Custom-Mini (3.5 GB) are for lightweight microservices and dev/test, available only with cluster mode disabled. HighCPU-Medium (8 vCPU/13 GB) and Standard-Large (8 vCPU/26 GB) target CPU-heavy workloads, and Highmem-XXLarge offers 110 GB RAM and 16 vCPUs per node. The post notes the figures are based on open-source benchmarks and actual performance will vary.

A generally available migration workflow moves self-managed Redis OSS or Valkey to Memorystore for Valkey in four steps: provision the target instance, establish continuous dual-sync online replication, validate data synchronization, and execute cutover by switching application endpoints. The post describes it as fully managed and requiring only a configuration change on the application.

Customer evidence is included: MLB uses Memorystore for Valkey to handle real-time stats and traffic spikes, and Target uses it for low-latency, resilient caching for personalization services. The post also states that over 95% of the top 100 Google Cloud customers already rely on Google Cloud Memorystore for high-throughput workloads, with increasing numbers using Memorystore for Valkey. The closing frames microsecond latency as a baseline across banking, AI-native development, digital streaming, and telecommunications, but no additional quantitative data is provided for those sectors.