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 Headquarters.
#SRG(Service Reliability Group) mainly provides cross-sectional support for the infrastructure of our media services, improving existing services, launching new ones, contributing to OSS, etc.
This article is a comparative review of managed in-memory database services provided by Google Cloud.
IntroductionServices to be comparedVerification environment and methodThe instance that is applying the loadThe instance under loadHow we testedTest ResultsperformancepriceConsiderationPerformanceUse cases and cost performanceValkey benefits and concernssummaryConclusion
Introduction
Redis is a fast in-memory key-value store that is widely used for a variety of purposes, including caching and messaging.
However, there has been a major move for Redis: starting with version 8 on May 1, 2025, it will be relaunched as an open source project under the name "Redis Open Source".
Although it is still unclear how Redis and Valkey will develop in the future, it can be said that developers now have more options.
In this article, we will focus on Memorystore, a managed in-memory database service provided by Google Cloud,
- Memorystore for Redis
- Memorystore for Redis Cluster
- Memorystore for Valkey
Let's compare and verify these three services.
Services to be compared
Memorystore for Redisis a service that provides a standalone Redis configuration.
It offers the flexibility to configure availability and capacity in detail, but does not support sharded configurations and has limited persistence options.
Memorystore for Redis Clusteris a service that supports Redis Cluster mode, and achieves high scalability and availability by distributing data across multiple shards.
Memorystore for Valkeyis a service that uses Valkey as its engine, and like Redis Cluster, it supports cluster mode while taking advantage of Valkey's features.
It also has the flexibility to disable cluster mode and use it as a standalone configuration.
These services have different instance types and pricing structures, which makes a pure comparison difficult.
However, in order to keep the conditions as similar as possible, we compared all three services with one shard and one replica set.
Note that at the time of writing this article, the Redis engine version of Memorystore for Redis Cluster is fixed at 7.0, so please take this into consideration when looking at the results.
Verification environment and method
The instance that is applying the load
The following Google Compute Engine instances were used for load generation:
| Instance type | c4a-standard-2 |
| CPU | 2core |
| Memory | 8.0 GB |
The instance under load
The configuration of the Memorystore instances for comparison 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 |
How we tested
memtier_benchmark- We populate each Redis/Valkey instance with data to approximately 60% of its memory capacity in order to measure performance in a realistic production environment.
memtier_benchmark
- We will run the benchmarks on the following three workloads:
- Write Only
- Read Only
- Read:Write = 1:1 (equal read and write)
- For each workload, five three-minute tests are performed and the average is calculated.
- The comparison metrics used are operations per second (Ops/sec) and P99 latency (99th percentile latency). For test procedures, seePrevious ArticlePlease also refer to the following.
Test Results
performance
The operations per second (Ops/sec) and P99 latency results 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 Price (hourly) | $0.4 | $0.366 | $0.366 |
| On-Demand Price (Monthly) | $292.00 | $267.18 | $267.18 |
| Region | asia-northeast1 | asia-northeast1 | asia-northeast1 |
In addition, the pricing examples for configurations with smaller specifications, such as for verification purposes, are as follows.
| 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 Price (hourly) | $0.065 | $0.0408 | $0.0408 |
| On-Demand Price (Monthly) | $47.45 | $29.78 | $29.78 |
| Region | asia-northeast1 | asia-northeast1 | asia-northeast1 |
In addition to the instance fees listed above, you may incur the following charges:
- Memorystore for Redis
- Network charges (communication across zones and regions)
- Memorystore for Redis Cluster / Valkey
- AOF persistence fee (if you use AOF persistence)
- Network charges (communication across zones and regions)
- Backup fee (if you use backup)
Consideration
Performance
Comparing Memorystore for Redis (Standalone) and Memorystore for Redis Cluster, we can see that Redis Cluster has significantly improved performance.
In particular, there was a difference of about 2.6 times in write performance (Write Only), and about 1.8 times in read performance (Read Only).
Although the engine versions are different, this difference is mainly due to Redis Cluster achieving high throughput by distributing and processing data across multiple nodes (one shard in this case, but the architecture is different).
Next, comparing Memorystore for Redis Cluster (Redis 7.0) and Memorystore for Valkey (Valkey 7.2), Valkey Cluster shows 5% to 10% higher performance.
This is likely due to the fact that Valkey is based on Redis 7.2.4 and has been optimized, and that the engine version is newer.
In terms of latency, Redis Cluster and Valkey Cluster also performed better than standalone Redis.
The P99 latency shows that Cluster services show significantly lower values, especially for Read Only and Read:Write workloads, so you can expect stable response performance.
This is also thought to be the result of load balancing through clustering and Valkey optimization.
Use cases and cost performance
Based on the test results, Memorystore for Redis may provide sufficient performance for small-scale traffic or simple caching purposes.
In particular, if read processing is the main focus and write frequency is low, the ability to scale out by adding up to five read replicas provides flexible support.
However, if you expect an increase in write load as your service grows, or if you require higher throughput and low latency, Memorystore for Redis Cluster and Memorystore for Valkey are viable options.
These services allow for more flexible and significant scale-out by increasing or decreasing the number of shards in addition to increasing or decreasing replicas.
Being able to increase the number of shards also helps minimize downtime during maintenance and other such situations.
In terms of cost, for the similar specs compared here (5GB memory, 1 shard, 1 replica), Memorystore for Redis Cluster and Valkey were slightly cheaper than Memorystore for Redis.
And yet their processing power is significantly higher, so when considering the balance between performance and cost, Cluster-based services, especially Valkey, look more attractive for new installations.
From these results, it seems that the benefits of actively choosing the traditional Memorystore for Redis are fading.
Valkey benefits and concerns
Memorystore for Valkey not only demonstrates superiority in terms of performance, but is also noteworthy as a migration path from Redis.
Even if you are currently using Redis that is not in Cluster mode and it is difficult to migrate to Cluster mode without modifying your application, Memorystore for Valkey can be used as a standalone configuration by disabling cluster mode.
In this case, you cannot set up a shard configuration and there are restrictions on the number of replicas, limited to a maximum of two, but the major advantage is that you can try migrating to Valkey at low cost while minimizing the impact on your existing applications.
On the other hand, a disadvantage of Valkey is that, as mentioned at the beginning, it is still unclear what the impact of Redis's relaunch as "Redis Open Source" will be.
It will be necessary to keep an eye on how the development of Redis Open Source and Valkey progresses and how the communities move forward.
Until this uncertainty is resolved, even if you decide to adopt Valkey, it may be a good idea to stick with the Valkey 7.2 series, which boasts full compatibility with Redis OSS 7.2.
summary
The results of this test show that if you are looking for high performance and scalability, Memorystore for Redis Cluster or Memorystore for Valkey are the best options.
In particular, Memorystore for Valkey offers better performance and flexible configuration options while having a migration path from Redis 7.2, and is also cost-competitive.
However, we need to pay attention to the future trends of the Redis and Valkey ecosystems.
With Redis relaunching as open source, it is still unclear which project will become mainstream or whether they will coexist in the future.
The current recommendation is:
- If you are migrating from an existing standalone Redis and want to minimize application modifications, use Memorystore for Valkey (cluster mode disabled).
- For new construction or when higher performance and scalability are required, Memorystore for Valkey (cluster mode enabled)
- If you want to keep a close eye on the Redis ecosystem, try the proven Memorystore for Redis Cluster (note that the engine version is older).
I think it will look something like this.
Conclusion
SRG is looking for people to work with us. If you are interested, please contact us here.