Memorystore is Google Cloud’s fully managed service for keeping data in memory so applications can read it in a fraction of a millisecond.

The problem: databases are slow compared to memory

A traditional database stores data on disks, even when those disks are fast solid-state drives. Every read has to travel over a network, wait in a queue, be found on storage, and travel back. For a single request this is fine. For millions of requests per minute, the delay adds up and the database becomes the bottleneck. Users feel it as slow pages, spinning loaders, and timeouts.

Computer memory (RAM) is thousands of times faster than disk. If the application keeps its most popular data in RAM, it can answer many requests without ever touching the database. This idea is called caching, and a system built to hold data in memory is called an in-memory data store.

What “managed” really means

You could install an open-source in-memory server on your own virtual machine. Then you would be responsible for patching it, restarting it when it crashes, copying data to a backup machine, watching memory usage, and planning upgrades. “Managed” means Google takes over those chores. Memorystore handles provisioning, replication, automatic failover, patching, and monitoring integration, while you focus on how your application uses the data.

Memorystore is also built to speak the same language as popular open-source engines. Existing client libraries and tools usually work with little or no change, which makes moving a cache to Google Cloud far less painful than rewriting an application.

Where Memorystore fits among Google Cloud services

Google Cloud has many places to keep data, and beginners often wonder which one to use. Cloud SQL, AlloyDB, and Spanner are relational databases built for durable, structured records. Firestore and Bigtable are databases for flexible or very large datasets. Cloud Storage keeps files and objects. Memorystore is different from all of these because its main promise is speed rather than long-term storage. It usually sits in front of one of them, answering the repeated questions quickly so the heavier database can focus on the work only it can do.

This placement also explains how to think about failure. If a database fails, you may lose business records. If a cache fails, you lose speed for a while, but the records are still safe. Designing with that mindset keeps the system honest about what each part is responsible for.

A handful of simple ideas explain almost everything about in-memory data stores.

Before looking at Google Cloud specifics, let us build a shared vocabulary. These words appear in every Memorystore document, and once they click, the rest of the service feels natural.

Keys, values, and data types

The engines behind Memorystore do more than store plain text. A value can be a simple string, a list, a set of unique items, a sorted set where every item has a score, or a hash that groups several fields together. These richer types are why in-memory stores are used for leaderboards, queues, and counters, not just caching web pages.

Why memory limits matter

RAM is fast but expensive and limited. You cannot keep everything in it. Good use of Memorystore is mostly about deciding what deserves a place in memory, how long it should stay, and what happens when the space runs out. Those three decisions shape cost, speed, and reliability more than any other setting.

The data types in more detail

Choosing the right data type is one of the biggest skills in working with an in-memory store. A string is the simplest type and holds text, numbers, or small serialized objects. It is perfect for a cached page fragment or a single counter. A hash groups several named fields under one key, which is a tidy way to hold a user profile without creating a separate key for every detail. A list keeps items in order, so it suits recent-activity feeds or simple work queues. A set holds unique items with no order, which is handy for questions such as “has this visitor already been counted today?”. A sorted set keeps unique items ranked by a score, which is the engine behind leaderboards.

Each type has trade-offs. A hash with a few dozen fields is compact and quick. A list with millions of entries is slow to walk through and heavy on memory. Think about how the data will be read before deciding how it is stored, because in memory stores the shape of the data decides the speed of the question.

Memorystore is not one product. It is a family of managed services, each built around a different open-source engine.

Google Cloud offers Memorystore for Valkey, Memorystore for Redis Cluster, Memorystore for Redis, and Memorystore for Memcached. They share a purpose, but they differ in how they scale, how available they are, and how long Google plans to recommend them. Choosing the right one at the start saves painful migrations later.

Valkey, in simple words

Valkey is an open-source in-memory data store that began as a community fork of Redis and is governed by the Linux Foundation. It speaks the same protocol as Redis, so most Redis clients work with it. Memorystore for Valkey is Google’s newest and most actively developed offering, and it is the one Google points many customers toward, including those moving away from Memcached.

One more point about versions. Memorystore for Redis is based on open-source Redis 7.2 and earlier, and it supports a subset of the full command library. Google’s release notes show Memorystore for Valkey adding newer Valkey versions over time. Always check the supported versions page in the documentation before you plan an upgrade.

Cluster mode enabled and cluster mode disabled

Google’s release notes describe that Memorystore for Valkey supports two configurations. In cluster mode enabled, data is split across shards using hash slots, which gives the best scaling. Clients must be cluster-aware. In cluster mode disabled, the instance behaves more like a classic single-primary setup, which is simpler for older applications that were never written to understand clusters. Neither is better in every case. The enabled mode is usually the right long-term choice for growth, while the disabled mode can ease a first migration.

An instance is made of shards, shards are made of nodes, and everything is reached through a private network endpoint.

The building blocks

When you create a clustered Memorystore instance, you are really creating a small team of machines that work together. The instance is the whole team. Each shard is a sub-team that owns a portion of the data. Inside a shard, one primary node accepts writes and one or more replica nodes hold copies. Together these pieces give you both capacity (more shards means more room) and safety (more replicas means more copies).

flowchart TD
  APP["Application on GKE, Compute Engine, or Cloud Run"] --> PSC["Private Service Connect endpoint"]
  PSC --> DISC["Discovery endpoint"]
  DISC --> S1["Shard 1"]
  DISC --> S2["Shard 2"]
  DISC --> S3["Shard 3"]
  S1 --> P1["Primary node"]
  S1 --> R1["Replica node"]
  S2 --> P2["Primary node"]
  S2 --> R2["Replica node"]
  S3 --> P3["Primary node"]
  S3 --> R3["Replica node"]
        

Read the diagram from the top. The application sends a request to a private endpoint inside your own network. The discovery endpoint tells the client library which shard owns the data it wants. The client then talks to the correct primary node directly. Replicas sit beside each primary, silently copying every change.

The endpoints explained

Clustered Memorystore instances expose a discovery endpoint. Think of it as the reception desk of a large office building. You do not need to know which room each employee sits in. You ask reception, and you are told where to go. Google documents that this endpoint is backed by multiple nodes across multiple zones, so it keeps working even when some nodes are being replaced or updated.

Because node addresses can change during maintenance or scaling, your application should never hard-code them. Good client libraries for clusters learn the layout from the discovery endpoint and refresh it automatically.

Node types and sizes

For Memorystore for Redis Cluster, Google documents several node types. The smallest, redis-shared-core-nano, is meant for small experiments: it has variable performance and no SLA, and its memory limit cannot be changed, so it is unsuitable for production. For production, the documentation recommends node types such as redis-standard-small, redis-highmem-medium, and redis-highmem-xlarge. More vCPUs help with heavy command processing, while more memory helps with big datasets. Memorystore for Valkey has its own list of node types, and Google’s release notes mention new Valkey node types becoming generally available in 2026.

Shapes, versions, and modules

Besides node types, an instance has a version and may offer extra features. Memorystore for Valkey lets you upgrade the engine version of an instance, and Google’s release notes show newer Valkey versions being added over time. Upgrading is valuable because new versions bring performance improvements and security fixes. Treat an upgrade like any other release: read the notes, test in staging, and then move production.

Some features arrive as extra modules. The release notes mention support for JSON documents and Bloom filters in preview for Memorystore for Valkey, and vector search that is generally available. A Bloom filter is a very small structure that answers the question “have I probably seen this before?” using little memory, which is useful for avoiding useless database lookups. Because preview features can change, avoid building critical systems on them until they are generally available.

Hash slots, replication, and health checks are the three mechanisms that make a cluster behave like one big store.

Hash slots: how data finds its shard

In a cluster, every key is run through a mathematical function that turns it into a number. That number places the key in one of 16,384 buckets called hash slots. Each shard owns a range of these slots. So when the application asks for a key, the client library calculates the slot and goes straight to the shard that owns it. No central server needs to decide, which is why clusters scale so well.

Replication: keeping copies in sync

Whenever the primary node changes a value, it streams that change to its replicas. The replicas apply the change in order, so they stay almost identical to the primary. This copying is usually asynchronous, meaning the primary does not wait for the replica before replying to your application. That keeps writes fast, but it also means a replica can be a tiny moment behind. If the primary fails at exactly the wrong instant, the very latest write may be lost. This is a normal trade-off of speed versus perfect safety.

Health checks and automatic failover

Memorystore constantly monitors the health of every node. If a primary stops responding, the service promotes one of its replicas to become the new primary and updates the cluster layout. Client libraries notice the change and reconnect to the new primary. For clustered instances, Google also spreads primaries and replicas across zones so that one data center problem does not take both copies down together.

sequenceDiagram
  participant App as Application
  participant P as Primary node
  participant R as Replica node
  participant M as Memorystore control
  App->>P: Write request
  P-->>App: Acknowledge
  P->>R: Stream the change
  Note over P: Primary stops responding
  M->>R: Promote to primary
  M-->>App: Updated topology
  App->>R: Next request now goes here
        

The sequence above shows why applications should expect brief hiccups during failover. The switch is quick, but not instant. Well-written clients retry a failed request after a short pause, and your users will usually never notice.

What happens when memory fills up

Every node has a maximum amount of memory it may use. When a node reaches that limit and a new write arrives, the engine must decide what to do. The decision is controlled by the eviction policy. Some policies refuse new writes and return an error. Others remove the least recently used keys, the least frequently used keys, or keys that are closest to expiring. Some policies consider every key, while others only consider keys that have a TTL. The available choices and the default for each service are listed in the Memorystore documentation, so check them rather than assuming.

Picking a policy is a business decision as much as a technical one. A pure cache usually prefers to quietly drop the oldest or least useful entries, because losing a cache entry costs only a database lookup. A store that holds sessions or counters may prefer errors over silent loss, because disappearing sessions log users out. Match the policy to what the data means.

Why memory usage is more than your data

The memory shown on a node is not only the size of your keys and values. The engine also needs space for its internal bookkeeping, for the buffers that feed replicas, and for client connections. That is why Google’s documentation reserves part of node memory as overhead and shows a client memory setting for each node type. If you plan capacity by adding up only your raw data, you will underestimate what you need.

There are two journeys to understand: how a single request travels, and how an instance lives from creation to deletion.

The journey of one request

The most common way to use Memorystore is the cache-aside pattern. The application is in charge. It first asks Memorystore for the data. If the data is there, it returns it right away. If not, it asks the database, returns the answer, and also saves a copy in Memorystore with a TTL so the next request is faster.

flowchart LR
  U["User request"] --> A["Application"]
  A --> C{"Found in Memorystore?"}
  C -- "Yes, cache hit" --> R["Return data fast"]
  C -- "No, cache miss" --> D["Read from database"]
  D --> W["Save copy with TTL"]
  W --> R
        

The life of an instance

Memorystore lives on private addresses, so the way you connect your applications is one of the first design decisions you make.

Why Memorystore is never exposed to the internet

A cache often holds sensitive information such as session tokens, user profiles, and shopping carts. For that reason Memorystore does not give instances a public internet address. Applications reach it through private IP addresses inside your Virtual Private Cloud (VPC), which is your own isolated network in Google Cloud. Only workloads that can route into that network can talk to the instance.

Two ways to connect

The older Memorystore services, Memorystore for Redis and Memorystore for Memcached, use Private Service Access or direct peering. In this model, Google’s service network is linked to your VPC by a reserved range of private addresses. It works, but it uses a block of address space and can be tricky when many networks need access.

The newer clustered services, Memorystore for Valkey and Memorystore for Redis Cluster, use Private Service Connect (PSC). With PSC, endpoints are created inside your own network, and each endpoint consumes only a small number of addresses. Google’s documentation highlights simpler management, granular private connectivity, and minimal address consumption as the benefits.

Multi-VPC access

Large companies often run many separate networks for different teams. Google’s release notes describe multi-VPC support for Memorystore for Valkey, which lets you create Private Service Connect endpoints in multiple VPCs that all point to the same instance. This means a payments team and a catalog team can share one cache without merging their networks.

flowchart LR
  subgraph V1["VPC network A"]
    APP1["Service A"] --> E1["PSC endpoint A"]
  end
  subgraph V2["VPC network B"]
    APP2["Service B"] --> E2["PSC endpoint B"]
  end
  E1 --> INST["Memorystore for Valkey instance"]
  E2 --> INST
        

Each network gets its own private door into the same room. Traffic never crosses the public internet, and the networks do not need to see each other.

Memorystore can grow in two directions, wider with more shards or taller with bigger nodes, and the clustered services do both without downtime.

Scaling out versus scaling up

Scaling out means adding more shards. The data is spread across more machines, so total memory and total throughput both increase. Scaling up means changing the node type to a larger one, giving each shard more memory and more processing power. Google’s documentation for Memorystore for Valkey and Redis Cluster describes zero-downtime scaling, up to 250 nodes, and capacity reaching many terabytes.

What to measure before choosing

Replicas: for safety and for reads

Replicas exist mainly to protect against failure, but they also cost money, because each one is another node. Google’s release notes for Memorystore for Valkey mention that each primary node can now have up to five replica nodes. A common starting point for production is at least one replica per shard so that failover is possible. Adding more replicas can help reads in some designs, but it also increases cost and replication traffic.

Small and large shard counts

Google’s release notes also mention smaller instance shapes of one, two, or four shards for Memorystore for Valkey. These shapes help small and medium workloads start cheaply while still using the modern, cluster-capable service. As the business grows, the instance can be scaled instead of rebuilt.

A worked example of planning

Imagine an online store expecting two million cached product records, each about two kilobytes, which is about four gigabytes of raw data. After adding overhead for internal structures, replication buffers, and growth over the next year, the team decides to plan for roughly double that amount. They expect around fifty thousand operations per second at the peak of a sale, mostly reads. With these numbers they might choose several mid-sized shards with one replica each, so that capacity is comfortable and the load is spread across machines.

The key lesson is the method, not the numbers. Start from the real data size, add generous headroom, estimate the peak traffic, decide the replica count from your availability needs, and then load test. After launch, watch the real metrics and adjust. Because scaling is possible without downtime, you do not need to guess perfectly on the first day.

High availability is a combination of replicas, zones, and good maintenance habits, not a single switch.

Understanding the SLA numbers

An SLA (Service Level Agreement) is a written promise about how much of the time a service will be working. Memorystore’s published SLA depends on the service and how you configure it. Multi-zone Memorystore for Valkey and Redis Cluster instances with high availability enabled are listed at up to 99.99%. Single-zone instances with high availability, and Memorystore for Redis Standard Tier, are listed at 99.9%. Some regions have their own listed values, so always read the current SLA page for the exact number that applies to you.

The tiers of Memorystore for Redis

In the standalone Memorystore for Redis service, the Basic Tier is a single node with no replication and no automatic failover. It is an ephemeral cache, meaning losing it is acceptable. The Standard Tier adds a replica in another zone with automatic failover, and an option for read replicas. Use Basic for development and non-critical caches. Use Standard for anything where an outage would hurt.

Maintenance without surprises

Every managed service must be patched. Memorystore applies updates for security and reliability, and Google’s release notes describe several tools that make maintenance friendlier for Memorystore for Valkey:

• Maintenance windows that you can view and set in the Google Cloud console.
• Self-service maintenance, so you can choose to update an instance to a newer maintenance version sooner.
• A simulate maintenance event feature that lets you test how your application behaves during a maintenance event before it happens for real.
• Maintenance changelogs that explain what each update contains, including security fixes.
• Cloud Logging support for viewing maintenance logs.

Designing for zones and regions

A region is a geographic area such as a city, and a zone is an isolated data center inside that region. Spreading nodes across zones protects you from a single-building problem, such as a power cut. Google’s documentation says that clustered instances distribute replicas across zones automatically, and its release notes describe that an instance can still be created if one zone of the region is unavailable, in which case it is created in the available zones.

Choose the region based on where most users and applications live. A cache that is far from the application loses the speed advantage that justified it. For global businesses, run separate instances close to each major region and decide carefully which data really needs to be shared between them.

Thinking about failure like an engineer

A useful exercise is to list what can break and decide in advance what the application does in each case. A single node failure should trigger automatic failover with a short blip. A zone failure should leave replicas in other zones ready to take over. A full region failure needs either a second region or a plan to rebuild from the database. A mistaken command that flushes the cache needs a plan for protecting the database while the cache refills. Writing these answers down turns surprises into routine procedures.

Memory is temporary by nature, so Memorystore offers several ways to protect data from restarts and regional disasters.

Persistence: surviving a restart

In-memory engines can write their contents to durable storage in two common ways. One takes periodic snapshots, like photographing a whiteboard every few minutes. The other keeps an append-only log of every change, like a diary of each edit, which can be replayed after a restart. Memorystore for Redis Cluster mentions optional append-only-file persistence and backups among its pricing components, which tells us these protections are options you can choose and pay for.

Backups

A backup is a saved copy you can restore later, for example after a mistaken bulk deletion or when you want to create a copy of an instance for testing. Google’s release notes show backup management for Memorystore for Valkey as generally available, including management from the Google Cloud console. Backups protect against human error, which is far more common than hardware failure.

Cross-region replication

Zones protect you if one data center has trouble. A whole region can also have problems, though that is rare. Cross-region replication keeps a copy of your instance in a second region. Google’s release notes list cross-region replication for Memorystore for Valkey as generally available, with Terraform support and console support. If the main region fails, you can promote the secondary instance and keep serving traffic from the second region.

flowchart LR
  A["Applications in Region 1"] --> P["Primary instance in Region 1"]
  P -. "Asynchronous replication" .-> S["Secondary instance in Region 2"]
  B["Applications in Region 2"] -.-> S
        

The dotted line is drawn on purpose. Replication between regions is asynchronous, so the second region may be slightly behind. For a cache, that is usually perfectly fine, since the data can be rebuilt from the database. For data you cannot rebuild, think carefully about how much loss is acceptable.

Recovery objectives in plain words

Two simple ideas help you decide how much protection to buy. The recovery point objective asks how much recent data you can afford to lose. The recovery time objective asks how long you can afford to be without the service. A pure cache may tolerate losing everything and rebuilding in minutes. A session store may tolerate losing a few seconds of writes but not the whole dataset. Writing these two numbers down makes it clear whether replicas, backups, persistence, or cross-region replication are worth their cost.

Security is layered: private networks, strong identity, encrypted traffic, and encrypted data at rest.

No single lock protects a house well. You want a fence, a locked door, and a safe for the valuables. Memorystore follows the same layered idea, and Google’s documentation lists several layers you can combine.

Certificates and trust

When traffic is encrypted with TLS, the client must trust the server’s certificate. Google’s release notes describe several certificate authority (CA) modes for Memorystore for Valkey. The per-instance mode gives each instance its own certificate. The shared CA mode offers one certificate bundle per region that works for all instances you configure to use it, which reduces the number of certificates your clients must manage. The customer-managed CA mode lets you use your own CA pool hosted on Certificate Authority Service, which helps with strict compliance needs. Google notes that shared and customer-managed CA modes are generally available.

Encryption at rest and compliance

Customer-managed encryption keys are generally available for Memorystore for Valkey according to the release notes, and organization policy constraints can enforce their use. This matters for industries such as banking and healthcare, where auditors want proof that sensitive data is encrypted with keys the company controls.

Who should be allowed to do what

Security has two sides that are easy to mix up. The first is control-plane access, meaning who may create, resize, back up, or delete instances. This is managed with IAM roles on your Google Cloud project. The second is data-plane access, meaning who may read and write keys inside the cache. This is managed with authentication, ACLs, and for the clustered services, IAM-based authentication. A person who can delete an instance does not automatically need permission to read cached data, and the reverse is also true.

Separate these duties on purpose. Platform engineers get permission to manage instances. Application service accounts get permission to connect and perform only the commands they need. Auditors may get read-only visibility into configuration and logs. When roles are cleanly separated, a mistake or a compromise in one area cannot easily spread to the others.

Protect what you cache

Cached data is still real data. Avoid placing secrets such as raw passwords or full payment card numbers in a cache. Store only what the application needs, use short TTLs for sensitive items such as tokens, and remember that a cache may hold personal information that falls under privacy rules. If a user asks to have their data deleted, the cached copy must be deleted as well.

You cannot fix what you cannot see, so Memorystore reports its health to Cloud Monitoring and Cloud Logging.

The metrics that matter most

Memorystore integrates with Cloud Monitoring so you can chart metrics and set alerts. Memorystore for Valkey also provides node-level metrics and, according to its release notes, additional node-level metrics and a metric for whether a node is healthy and functioning. Node-level views help you spot a single struggling shard that an instance-wide average would hide.

Alerting that people actually respond to

Alerts should be few and meaningful. A good starting set warns when memory stays high for several minutes, when the hit ratio drops sharply, when replication lag grows, and when a node reports unhealthy. Too many noisy alerts train people to ignore them, which is worse than having none.

Logs and client-side visibility

Memorystore sends maintenance logs to Cloud Logging, where you can query and view them. Remember that Memorystore only knows its own side of the conversation. Your application should also record client-side metrics such as request time, timeouts, and retry counts. Comparing the two sides tells you whether a slowdown lives in the service or in the network and code around it.

A simple troubleshooting playbook

When users report slowness, resist the urge to guess. Follow a short routine. First, check whether the problem is in Memorystore or in the application by comparing client-side timings with service metrics. Second, look at memory and evictions to see whether the cache has become too small. Third, look at CPU and per-node views to find a single overloaded shard. Fourth, check connection counts for a leak or a sudden surge. Fifth, review recent changes, such as a new release that changed key names or TTLs, and check the logs for maintenance activity around the same time.

Keep a record of what you find. Over time, these notes become a team guide that makes the next incident faster to solve and helps new engineers learn how the system behaves.

The same fast memory can serve very different jobs, from caching pages to powering AI search.

Choosing a caching strategy

Choosing a good TTL

A TTL is a balance between freshness and speed. A very short TTL keeps data fresh but sends more requests to the database. A very long TTL gives a high hit ratio but risks showing old information. Ask the business how stale each kind of data may safely be. A product description may be allowed to be an hour old. A stock level may only be allowed to be a few seconds old. An account balance may not belong in a cache at all.

Besides expiry, many teams also delete or update the cached copy whenever the database record changes. This is called invalidation, and it keeps users from seeing outdated values after an edit. Invalidation is famously tricky, so keep it simple: delete the cached key on change and let the next read rebuild it.

Keeping the cache and database consistent

Whenever the same fact lives in two places, they can disagree for a short time. With cache-aside, there can be a brief window where the cache holds an old value after the database has changed. For most pages, nobody notices. For critical data such as inventory at checkout, read the authoritative value from the database at the moment it matters, and use the cache only for browsing. Being honest about where slight staleness is acceptable is the heart of a good caching design.

Most Memorystore trouble comes from a small group of repeated design mistakes, not from the service itself.

A short checklist of habits separates smooth Memorystore deployments from stressful ones.

Habits that pay off

Mistakes that appear again and again

Every technology trades something for something else, and Memorystore is no exception.

How the bill is built

Google states that Memorystore pricing varies by capacity, number of replicas, and region, with per-second billing. For Memorystore for Redis Cluster, the main drivers are the node type, the number of nodes, the region, the replica count, and optional features such as persistence and backups. Total nodes equals shards multiplied by one plus the replicas per shard, so a three-shard cluster with two replicas per shard uses nine nodes.

Memorystore versus running it yourself

Some teams consider installing Valkey or Redis on their own virtual machines or on Kubernetes. This gives maximum control and sometimes a lower raw price. It also makes the team responsible for upgrades, security patches, failover testing, backup jobs, monitoring, capacity planning, and late-night incidents. For many companies the engineering time saved by a managed service is worth more than the extra cost of the service. For very specialized needs, such as unusual modules or settings that the managed service does not permit, self-management may still make sense.

Different industries lean on in-memory speed in different ways, and the patterns repeat across them.

Whether you are coming from your own servers, an older Memorystore service, or Memcached, there is a path forward.

Common starting points

A safe migration order

flowchart TD
  Q1{"New project or existing cache?"} -->|"New"| Q2{"Need large scale or 99.99 percent SLA?"}
  Q1 -->|"Existing Memcached"| V["Plan move to Memorystore for Valkey"]
  Q2 -->|"Yes"| VC["Memorystore for Valkey or Redis Cluster"]
  Q2 -->|"No, small or simple"| Q3{"Need replication and failover?"}
  Q3 -->|"Yes"| ST["Valkey small shape or Redis Standard Tier"]
  Q3 -->|"No, dev or test only"| BA["Basic Tier or smallest Valkey shape"]
        

The flow above is a starting guide, not a rule. If your needs are unusual, such as strict compliance or special commands, confirm details in the current documentation before committing.

Quick answers to the questions beginners and intermediate engineers ask most often.

It stores data, but it is best thought of as a fast data layer beside your main database. It is great for caching, sessions, counters, and similar jobs, while your durable database remains the source of truth.

For most new work needing scale, high availability, or modern features such as vector search, Memorystore for Valkey is the natural starting point. Memorystore for Redis Cluster suits teams with a strong Redis focus. Standalone Redis fits small, simple needs.

Valkey began as a community fork of Redis and is developed under the Linux Foundation. They speak a compatible protocol, so many clients work with both. Over time, features and versions can differ, so check supported versions and commands.

No. Memorystore uses private IP addresses inside your VPC. Applications must run in Google Cloud or connect through private network links, such as a VPN or interconnect, that route into your VPC.

You may see brief connection errors, and because replication is usually asynchronous, the very latest writes could be lost in rare failover cases. Well-designed clients retry, and caches can be rebuilt from the database.

Watch the hit ratio, latency, memory usage, and evictions. A high hit ratio with steady latency and low evictions means the cache is doing its job.

For production, yes. Without a replica, losing a node means losing that shard until it is rebuilt. Replicas, ideally in a different zone, give you automatic failover and the higher SLA tiers.

Google documents zero-downtime scaling for Memorystore for Valkey and Redis Cluster, both by adding shards and by changing node types. Clients should still be cluster-aware so they follow the new layout.

Google’s documentation says it stopped being a recommended service on January 20, 2026, and customer support ends on January 31, 2029. Plan a migration, preferably to Memorystore for Valkey.

Billing depends on the service, capacity or node type, number of nodes and replicas, region, and optional features, with per-second billing. Check the official pricing pages for current rates.

Yes. Memorystore for Valkey supports storing and searching vector data, which suits retrieval for chatbots and recommendation features, and it offers low-latency storage for conversation state.

Check CPU, memory, connection counts, and node-level metrics for one overloaded shard. Then look for large values, hot keys, a recent deployment, or maintenance activity in the logs.

Memorystore gives Google Cloud applications a fast shelf next to the stove. It removes the chores of running in-memory servers and lets teams concentrate on how data is cached, secured, and scaled. The family has grown and shifted: Valkey and Redis Cluster lead for scale and availability, standalone Redis remains for simpler needs, and Memcached is on a retirement path. Success comes less from clicking the right settings than from good habits: sensible TTLs, cluster-aware clients, careful monitoring, layered security, and a design that survives failover calmly.