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) is a group that mainly provides cross-sectional support for the infrastructure of our media services, improving existing services, launching new ones, and contributing to OSS.
This article compares and contrasts the managed in-memory database services offered by Google Cloud.
IntroductionServices to be comparedVerification environment and methodThe instance that applies the loadThe instance under loadTesting MethodologyVerification 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, a major move has been made: Redis will be relaunched as an open source project under the name "Redis Open Source" starting with version 8 on May 1, 2025.
While 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 flexibility in configuring 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, achieving 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 in a standalone configuration.
These services differ in instance types and pricing structures, making a pure comparison difficult.
However, in order to keep the conditions as similar as possible, we compared all three services with a configuration of one shard and one replica set.
At 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 method
The instance that applies 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 instance used 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 |
Testing Methodology
memtier_benchmark- Each Redis/Valkey instance is filled to approximately 60% of its memory capacity with data, in order to measure performance in a realistic production environment.
memtier_benchmark
- Benchmarks are performed on the following three workloads:
- Write Only
- Read Only
- Read:Write = 1:1 (equal read and write)
- For each workload, five 3-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.
Verification 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 example for configurations with smaller specifications, such as for verification purposes, is 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 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 are using 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 offers significantly better performance.
In particular, there was a difference of approximately 2.6x in write performance (Write Only) and approximately 1.8x in read performance (Read Only).
Although the engine versions are different, this difference is thought to be 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, when comparing Memorystore for Redis Cluster (Redis 7.0) and Memorystore for Valkey (Valkey 7.2), Valkey Cluster shows an additional 5% to 10% higher performance.
This may be due to the fact that Valkey is based on Redis 7.2.4 and has been optimized, as well as the newer engine version.
In terms of latency, Redis Cluster and Valkey Cluster also performed better than standalone Redis.
Based on P99 latency, Cluster services showed significantly lower values, particularly for Read Only and Read:Write workloads, and stable response performance can be expected.
This is also thought to be the result of load balancing via clustering and Valkey optimizations.
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 your database mainly uses read processing and writes infrequently, you can scale out by adding up to five read replicas, allowing for flexible response.
However, if you expect your write load to increase as your service grows, or if you require higher throughput and low latency, Memorystore for Redis Cluster or 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 events.
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 they have significantly higher processing power, so when considering the balance between performance and cost, Cluster-based services, especially Valkey, appear more attractive for new implementations.
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 superior 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 create a sharded configuration and the number of replicas is 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, one disadvantage of Valkey is that, as mentioned at the beginning, it is still unclear what impact the relaunch of Redis as "Redis Open Source" will have.
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
Based on the results of this testing, if you are looking for high performance and scalability, Memorystore for Redis Cluster or Memorystore for Valkey are likely your best options.
Memorystore for Valkey in particular offers a migration path from Redis 7.2, better performance, flexible configuration options, and is cost-competitive.
However, we need to keep an eye on future developments in the Redis and Valkey ecosystems.
With Redis relaunching as open source, it is still unclear which project will become mainstream or whether the two will coexist in the future.
Currently, the 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 monitor the Redis ecosystem more carefully, try the proven Memorystore for Redis Cluster (note that it uses an older engine version).
I think it will look something like this.
Conclusion
SRG is looking for people to work with us.
If you're interested, please contact us here.