Memorystore for Redis

This page describes how Memorystore for Redis maps to services in the environment where the application runs. Some profiles adapt origin API calls; others translate infrastructure or document target-native behavior.

​

Supported environments

API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on.

​

How the targets compare

Each row compares a capability of Memorystore for Redis with its adaptation on each target. A dash means this profile does not state the capability for that target.

​

Cloud Adapter

​

On AWS

​

ElastiCache

A Memorystore instance becomes an ElastiCache cluster running Valkey. The client protocol and commands remain the same, while engine names and version strings change. The build identifies how a specified source version maps to the target.

​

Client and engine behavior

The adapter applies cache-management settings while the target engine answers cache commands. Keep the client’s expectations about topology, numbered databases, TLS, and authentication aligned with the selected target. Engine compatibility does not make source token providers interchangeable.

​

Cache cutover

Prepare the target endpoint and credentials before switching clients. Rebuild disposable entries from the application’s source of truth, or arrange an explicit data transfer when keys and expiry times must survive. Test reconnects and retried commands after failover.

​

Compatibility differences

Token-based authentication also requires a client change because the two clouds issue credentials differently; the build identifies that requirement.

​

On Azure

​

Azure Managed Redis

A Memorystore instance becomes an Azure managed cache using the same client protocol.

​

Client and engine behavior

The adapter applies cache-management settings while the target engine answers cache commands. Keep the client’s expectations about topology, numbered databases, TLS, and authentication aligned with the selected target. Engine compatibility does not make source token providers interchangeable.

​

Cache cutover

Prepare the target endpoint and credentials before switching clients. Rebuild disposable entries from the application’s source of truth, or arrange an explicit data transfer when keys and expiry times must survive. Test reconnects and retried commands after failover.

​

Compatibility differences

The build rejects configurations using more than one numbered database. On this target, SELECT does not switch databases: all keys remain in database zero. Deploying such a configuration could make previously separate keys overwrite each other.

​

Existing data and credentials

Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application’s endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target.

​

Configure, tune and debug

Start with setup and configuration. Use tuning to understand supported request tags, debugging to investigate a request, and High Fidelity Cloud Emulators to validate a bounded reproduction.