Google Cloud: Memorystore for Redis vs. Valkey - Which in-memory database should you choose now?
This is Kobayashi (@berlinbytes) from the Service Reliability Group (SRG) of the Media Division.
#SRGThe Service Reliability Group primarily provides comprehensive support for the infrastructure surrounding our media services, focusing on improving existing services, launching new ones, and contributing to open-source software (OSS).
This article compares and contrasts the managed in-memory database services offered by Google Cloud.
IntroductionServices to compareVerification environment and methodsThe instance that applies the loadThe instance being subjected to the loadTesting methodVerification resultsperformancepriceConsiderationAbout performanceUse cases and cost performanceValkey's advantages and concernssummaryIn conclusion
Introduction
Redis is a high-speed in-memory key-value store widely used for various purposes such as caching and messaging.
Redis underwent a major development on May 1, 2025, with version 8, being relaunched as an open-source project under the name "Redis Open Source."
While the future development of Redis and Valkey remains uncertain, it can be said that developers now have more options.
This article focuses on Memorystore, a managed in-memory database service provided by Google Cloud.
- Memorystore for Redis
- Memorystore for Redis Cluster
- Memorystore for Valkey
We will compare and review these three services.
Services to compare
Memorystore for RedisThis service provides a standalone Redis instance.
While it offers flexibility in granular configuration of availability and capacity, it uses a non-sharded configuration without Redis Cluster mode, and its persistence options are limited.
Memorystore for Redis ClusterThis service supports Redis Cluster mode, achieving high scalability and availability by distributing data across multiple shards.
Memorystore for ValkeyThis service utilizes Valkey as its engine, supporting cluster mode similar to Redis Cluster, while also leveraging Valkey's unique features for efficient operation.
Furthermore, it offers the flexibility to be used as a standalone configuration by disabling cluster mode.
These services differ in instance types and pricing structures, making a direct comparison difficult.
However, to ensure the conditions are as consistent as possible, we compared all three services using a configuration of one shard and one replica set.
Please note that, as of the time of writing, the Redis engine version for Memorystore for Redis Cluster is fixed at 7.0, so please keep this in mind when viewing the results.
Verification environment and methods
The instance that applies the load
The following Google Compute Engine instances were used to generate the load:
| Instance type | c4a-standard-2 |
| CPU | 2core |
| memory | 8.0 GB |
The instance being subjected to the load
The configuration of the Memorystore instance being compared is as follows:
| service | Memorystore for Redis | Memorystore for Redis Cluster | Memorystore for Valkey |
| Instance type | Standard Tier | redis-standard-small | standard-small |
| CPU | 2 I/O Threads | 2 vCPU | 2 vCPU |
| memory | 5 GiB | 6.5 GB (5.2 GB writable) | 6.5 GB (5.2 GB writable) |
| Number of shards | 1 | 1 | 1 |
| Number of replicas | 1 | 1 | 1 |
| engine | Redis 7.2 | Redis 7.0 | Valkey 7.2 |
Testing method
memtier_benchmark- We will populate each Redis/Valkey instance with data up to approximately 60% of its memory capacity. This is to measure performance in a condition that closely resembles a real-world production environment.
memtier_benchmark
- We will perform benchmarks using the following three types of workloads.
- Write Only
- Read Only
- Read:Write = 1:1 (equal read/write ratio)
- For each workload, we will perform five sets of 3-minute tests and take the average value.
- As comparison metrics, we will use operations per second (Ops/sec) and P99 latency (99th percentile latency). For the test procedure, see below.Previous articlePlease also refer to this.
Verification results
performance
The results for operations per second (Ops/sec) and P99 latency for each service and workload are as follows:
price
asia-northeast1| service | Memorystore for Redis | Memorystore for Redis Cluster | Memorystore for Valkey |
| Instance type | Standard tier (5GB) | redis-highmem-medium | highmem-medium |
| Number of shards | 1 | 1 | 1 |
| Number of replicas | 1 | 1 | 1 |
| On-demand pricing (per hour) | $0.4 | $0.366 | $0.366 |
| On-demand pricing (monthly) | $292.00 | $267.18 | $267.18 |
| Region | asia-northeast1 | asia-northeast1 | asia-northeast1 |
Furthermore, the following are examples of pricing for configurations with smaller specifications, such as those used for testing purposes.
| service | Memorystore for Redis | Memorystore for Redis Cluster | Memorystore for Valkey |
| Instance type | Basic Tier(1GB) | redis-shared-core-nano | shared-core-nano |
| Number of shards | 1 | 1 | 1 |
| Number of replicas | 0 | 0 | 0 |
| On-demand pricing (per hour) | $0.065 | $0.0408 | $0.0408 |
| On-demand pricing (monthly) | $47.45 | $29.78 | $29.78 |
| Region | asia-northeast1 | asia-northeast1 | asia-northeast1 |
In addition to the instance fees listed above, the following charges may apply:
- Memorystore for Redis
- Network charges (for communication across zones and regions)
- Memorystore for Redis Cluster / Valkey
- AOF persistence fee (if AOF persistence is enabled)
- Network charges (for communication across zones and regions)
- Backup fee (if you use backup)
Consideration
About performance
Comparing Memorystore for Redis (standalone) and Memorystore for Redis Cluster, we see a significant performance improvement with Redis Cluster.
In particular, the difference was approximately 2.6 times in write performance (Write Only) and approximately 1.8 times in read performance (Read Only).
Although the engine versions are different, this difference is mainly thought to be due to Redis Cluster achieving high throughput by distributing data processing across multiple nodes (in this case, one shard, but due to architectural differences).
Next, comparing Memorystore for Redis Cluster (Redis 7.0) and Memorystore for Valkey (Valkey 7.2), Valkey Cluster shows an even higher performance, approximately 5% to 10% better.
This is likely due to Valkey being optimized based on Redis 7.2.4, as well as its newer engine version.
Regarding latency, Redis Cluster and Valkey Cluster performed better than standalone Redis.
Based on P99 latency, Cluster-based services showed significantly lower values, especially for Read Only and Read:Write workloads, suggesting stable response performance.
This is likely due to load balancing through clustering and optimizations in Valkey.
Use cases and cost performance
Based on our testing, Memorystore for Redis may offer sufficient performance for small traffic volumes or simple caching applications.
Especially for read-heavy operations with infrequent writes, it offers flexible scaling capabilities thanks to the ability to add up to five read replicas.
However, if increased write load is expected as the service grows, or if higher throughput and lower latency are required, Memorystore for Redis Cluster and Memorystore for Valkey are strong options.
These services allow for more flexible and significant scaling out by increasing or decreasing the number of shards in addition to increasing or decreasing the number of replicas.
Increasing the number of shards also helps minimize downtime during maintenance.
In terms of cost, for similar specifications (5GB memory, 1 shard, 1 replica) compared in this study, Memorystore for Redis Cluster and Valkey were slightly cheaper than Memorystore for Redis alone.
However, their processing power is significantly higher. Considering the balance between performance and cost, cluster-based services, especially Valkey, appear more attractive for new deployments.
This result suggests that the advantages of actively choosing the traditional Memorystore for Redis are diminishing.
Valkey's advantages and concerns
Memorystore for Valkey not only demonstrates performance advantages but also stands out as a migration path from Redis.
Even if you are currently using Redis in a non-cluster mode and migrating to cluster mode without application modifications is difficult, Memorystore for Valkey can be used in a standalone configuration by disabling cluster mode.
While this configuration has limitations, such as the inability to create sharded configurations and a maximum of two replicas, the ability to try migrating to Valkey at a low cost while minimizing the impact on existing applications is a significant advantage.
On the other hand, a disadvantage of Valkey, as mentioned at the beginning, is that the impact of Redis's relaunch as "Redis Open Source" is still unclear.
It is necessary to closely monitor how development of both Redis Open Source and Valkey progresses, and how the communities will evolve.
Until this uncertainty is resolved, even if you adopt Valkey, it might be wise to stick to the Valkey 7.2 series, which boasts full compatibility with Redis OSS 7.2.
summary
Based on these findings, if you require high performance and scalability, Memorystore for Redis Cluster or Memorystore for Valkey are strong contenders.
Memorystore for Valkey, in particular, offers a migration path from Redis 7.2 while providing superior performance, flexible configuration options, and competitive cost-effectiveness.
However, it's important to pay attention to the future developments of the Redis and Valkey ecosystems.
With Redis relaunched as open source, it's still unclear which project will become dominant or whether they will coexist in the future.
Our current recommendation is:
- If you want to minimize application modifications when migrating from an existing standalone Redis, use Memorystore for Valkey (with cluster mode disabled).
- For new builds or when higher performance and scalability are required, use Memorystore for Valkey (with cluster mode enabled).
- If you want to more carefully assess the trends in the Redis ecosystem, consider the proven Memorystore for Redis Cluster (note that the engine version is older).
I think it will look something like this.
In conclusion
SRG is looking for new team members.
If you are interested, please contact us here.