GCP Memorystore: Redis vs Memcached vs Valkey
Google Cloud has the most expansive managed in-memory portfolio of the three hyperscalers: separate Memorystore services for Redis, Memcached, and Valkey, each with their own SKUs, pricing, and feature roadmaps. The three-way choice has a defensible answer.
Three engines, four services, one decision
GCP Memorystore is actually four distinct managed services. Memorystore for Redis (the original, single-shard with optional replicas) launched in 2018. Memorystore for Memcached followed in 2020 for ephemeral cache workloads. Memorystore for Redis Cluster launched in 2024 as the sharded variant for horizontal scaling. Memorystore for Valkey launched in early 2025 in step with the Valkey 8.0 release. Each has its own pricing page, its own quotas, and its own client-library integration story.
The launches reflect Google's strategy of letting customers self-select. Memorystore for Redis exists because Redis was the de facto in-memory store of the late 2010s and customers expected it. Memorystore for Memcached exists because some workloads still preferred Memcached's operational simplicity. Memorystore for Redis Cluster exists because the original single-shard offering ran out of headroom for large customers. Memorystore for Valkey exists because Google was a founding member of the Valkey project after the March 2024 Redis SSPL switch and wanted to offer a strategic alternative.
For new GCP workloads in 2026, the recommended starting point is Memorystore for Valkey. It is BSD-licensed (no SSPL fallout), priced competitively with Memorystore for Redis OSS, supports the same Redis client libraries, and Google's roadmap pushes Valkey-specific features (better threading, lower memory overhead) faster than the Redis OSS port. The exceptions are when you specifically need Redis 8.0's vector sets (use Memorystore for Redis Cluster on the Redis OSS engine) or when you want pure Memcached throughput (Memorystore for Memcached).
Memorystore for Memcached: the simpler choice
Memorystore for Memcached presents differently from the Redis-family offerings. There is no concept of replication, persistence, or backup; the service is a managed Memcached server pool with automatic node discovery, monitoring, and patch management. You specify a node count (1 to 20) and a per-node memory size, and the service provisions, exposes a service endpoint your application connects to, and handles the rest.
Per-node memory tops out at 300GB on the largest configuration (24 cores, 300GB RAM), and clusters can scale to 20 nodes for a total of 6TB of ephemeral cache memory. This is enough for very large page-cache workloads. The pricing structure is per-vCPU-hour and per-GB-hour, broadly competitive with running Memcached yourself on GCE and significantly simpler operationally.
The case for Memorystore for Memcached over Memorystore for Valkey or Redis is narrow but real: when your workload is purely ephemeral page caching, when persistence is actively not wanted (you trust that the application can repopulate the cache from the data source), when multi-threaded raw GET/SET throughput is the dominant performance metric, and when operational simplicity is more valuable than feature breadth. For that combination, Memcached on GCP is a good fit. For anything else, Valkey or Redis Cluster.
Memorystore for Redis vs Redis Cluster
Memorystore for Redis (the original 2018 product) is a single-shard, single-zone-or-multi-zone offering with up to 5 read replicas. Basic tier is one node, Standard tier is one primary plus a replica with automatic failover, and Memorystore supports scaling memory up to 300GB per instance. The single-shard architecture is simpler to use (any Redis command works, no cross-slot restrictions) but caps your scale at one shard's memory.
Memorystore for Redis Cluster (launched 2024) is the sharded variant. Up to 250 shards per cluster, each shard with a primary and optional replicas. The pricing is per-shard, the operational model is Redis Cluster's standard one (clients must support cluster topology discovery, multi-key operations must use hash tags to land in the same slot), and the scaling is horizontal: add shards to add capacity.
The decision rule is straightforward. If your working set fits comfortably in one shard's memory now and is unlikely to outgrow it, Memorystore for Redis is simpler. If you anticipate scale or want headroom for growth, Memorystore for Redis Cluster gives you that path without a future migration. The migration from non-clustered to clustered Redis is non-trivial because client code must handle topology discovery; starting on Cluster avoids the future pain.
Integration with GKE, Cloud Run, Cloud Functions
The reason most teams use Memorystore over running their own Redis on GCE is the integration with the rest of GCP. Memorystore deploys into your VPC with a private IP, and GKE pods, Cloud Run services, and Cloud Functions can reach it through the standard VPC connectivity options. IAM permissions control who can create, modify, and access instances. Cloud Monitoring auto-instruments connection counts, memory usage, latency, and eviction rates.
For Cloud Run specifically, the recommended pattern is to use Serverless VPC Access connectors to reach Memorystore from a fully-managed Cloud Run service. The latency overhead is a few hundred microseconds compared to in-VPC compute, acceptable for most cache workloads. For latency-critical workloads, run the application on GKE in the same region and zone as Memorystore to minimise hop count.
The integration with Vertex AI and Google's BigQuery / Spanner stack is more relevant for vector search workloads, where Memorystore for Redis Cluster on Redis 8.0 can hold the vector index for an RAG application while the embedding model runs in Vertex AI. This combination is one of the cases where the Redis OSS engine wins over Valkey: Valkey 8.1 has not shipped vector set support and the Redis 8.0 vector commands are GCP-supported on Memorystore for Redis Cluster.
FAQ
Does GCP support Valkey?
Yes. Memorystore for Valkey went GA in early 2025 with first-class support, separate billing, and the same node sizes as Memorystore for Redis. Google was a founding member of the Valkey project alongside AWS, Oracle, and Ericsson, so the offering reflects strategic backing rather than a token addition.
Memorystore for Redis vs Cluster?
Memorystore for Redis (the original) is a single-shard offering with up to 5 read replicas. Memorystore for Redis Cluster (launched 2024) is the sharded version supporting up to 250 nodes per cluster with horizontal scaling. New workloads should usually start with the Cluster variant if you anticipate growth, even if you launch with a small cluster.
Basic vs Standard tier?
Basic is a single node with no replication and no SLA, intended for development. Standard has automatic failover via a primary-replica pair and a 99.9% SLA. The price difference is roughly 2x because Standard runs two nodes for the same capacity. Production should always be Standard.
How does Memorystore pricing compare to ElastiCache?
Broadly comparable per GB of cache memory, with regional differences. Google's per-hour pricing is broken down differently (per GB-hour for Memorystore for Redis, per node-hour for Memorystore for Memcached). For an apples-to-apples comparison normalise to cache GB delivered per dollar across both providers; in May 2026 the per-GB rates land within 10-15% of each other for equivalent SKUs.
Can I access Memorystore from outside GCP?
Not directly. Memorystore is VPC-internal by default with private IP access. To reach it from on-premises or other clouds, you go through Cloud VPN, Cloud Interconnect, or a managed Cloud SQL Auth Proxy-style sidecar. The lack of public endpoints is intentional security posture, common to all GCP managed databases.