Skip to main content
On this page

​
Coverage by target cloud

​
How the targets compare

Each row compares a capability of MemoryDB with its adaptation on each target. A dash means this row is not stated for that target.

​
Infrastructure-only adaptation

​
On Google Cloud

​
How it works

The adapter changes the application endpoint from MemoryDB to Memorystore for Valkey. Your Redis or Valkey client connects directly using the Redis serialization protocol (RESP). Tensor9 does not proxy these requests. The target supports Redis data types and operations such as GET, SET, HSET, ZADD, XADD, transactions and Lua. A sharded MemoryDB deployment needs Memorystore for Valkey with cluster mode enabled or Memorystore for Redis Cluster. Check restricted commands, authentication and topology when configuring the client.
Before: on AWS your app's Redis client speaks RESP to a MemoryDB cluster. After: on Google Cloud the same app runs the same client speaking the same RESP wire to a native Memorystore for Valkey instance; the endpoint is rewired at the build, with no proxy in the data path; configure the target's authentication, TLS and topology.Before: on AWS your app's Redis client speaks RESP to a MemoryDB cluster. After: on Google Cloud the same app runs the same client speaking the same RESP wire to a native Memorystore for Valkey instance; the endpoint is rewired at the build, with no proxy in the data path; configure the target's authentication, TLS and topology.

The application connects directly to Memorystore for Valkey using RESP.

​
Persistence and failover

Memorystore replicates asynchronously, so an unexpected failover can lose acknowledged writes that have not reached a replica. Persistence is configured separately: append-only files (AOF) support appendfsync values always, everysec (the default) and no; RDB snapshots run every 1, 6, 12 or 24 hours. always completes a local fsync before acknowledgment. With everysec, about a second of recent disk writes can be lost; no delegates flushing to the operating system. A local sync does not ensure that the replica promoted during failover has the write. Provision at least one replica per shard for automatic failover. Google describes recovery as taking tens of seconds. A promoted replica may be missing writes that the primary acknowledged. WAIT waits for acknowledgments from a chosen number of replicas, but does not guarantee that failover preserves every acknowledged write.
MemoryDB commits each write to a distributed multi-AZ transactional log across three Availability Zones before acknowledging the client, so the write is durable at ack. Memorystore local persistence depends on the selected policy: with AOF appendfsync always, local fsync completes before acknowledgment; everysec syncs about once per second, and RDB snapshots capture periodic recovery points. Replication is asynchronous, so failover can lose writes missing from the promoted replica even after a local sync.MemoryDB commits each write to a distributed multi-AZ transactional log across three Availability Zones before acknowledging the client, so the write is durable at ack. Memorystore local persistence depends on the selected policy: with AOF appendfsync always, local fsync completes before acknowledgment; everysec syncs about once per second, and RDB snapshots capture periodic recovery points. Replication is asynchronous, so failover can lose writes missing from the promoted replica even after a local sync.

MemoryDB commits across zones before acknowledgment. Memorystore replication is asynchronous; persistence settings do not remove the failover loss window.

​
Sharding and the keyspace

MemoryDB partitions keys across up to 500 shards, each with a primary and up to five replicas. Memorystore for Valkey supports up to 250 shards with zero to five replicas each. Both use Redis Cluster hash slots, including the cross-slot restrictions on multi-key operations. Size large datasets within Memorystore’s 250-shard limit, using a larger node type if necessary. A cluster-aware client discovers the target topology and follows MOVED and ASK redirects. The target does not retain the source cluster’s shard placement.
A MemoryDB cluster partitions the keyspace across shards, each a primary plus up to five replicas. Memorystore for Valkey with Cluster Mode Enabled maps directly: it scales to up to 250 shards, one primary per shard with zero to five replicas, using the same Redis Cluster hash-slot keyspace with target shard placement determined by its own topology.A MemoryDB cluster partitions the keyspace across shards, each a primary plus up to five replicas. Memorystore for Valkey with Cluster Mode Enabled maps directly: it scales to up to 250 shards, one primary per shard with zero to five replicas, using the same Redis Cluster hash-slot keyspace with target shard placement determined by its own topology.

Memorystore uses Redis Cluster hash slots, with up to 250 shards instead of MemoryDB’s 500.

​
Snapshots, auth, and encryption

Backups. MemoryDB snapshots to S3 have up to 35-day retention and are separate from its transaction log. Memorystore RDB backups can be exported to Cloud Storage and scheduled daily, with retention up to 365 days (35 by default). A restore creates a new instance. Each RDB backup captures one point in time; it does not preserve later writes. Authentication. MemoryDB clients use Redis access-control list (ACL) users. Memorystore offers IAM authentication with short-lived tokens and basic AUTH. Configure the target credentials and token refresh in the application; source ACL users are not the same as target IAM identities. Encryption. MemoryDB uses a default or customer KMS key at rest and requires TLS. Memorystore supports customer-managed encryption keys (CMEK) through Cloud KMS for persisted data. TLS is available and automatically enabled with IAM authentication. The customer key protects persisted AOF/RDB files and backups; Memorystore does not encrypt the live in-memory dataset.
Three operational surfaces map across with named differences. Backups: MemoryDB snapshots to Amazon S3 map to Memorystore RDB backups exported to a Cloud Storage bucket, on a daily schedule. Auth: MemoryDB Redis ACL users map to Memorystore IAM authentication plus basic AUTH. Encryption: MemoryDB always-on at-rest with a KMS customer key maps to Memorystore CMEK via Cloud KMS on persisted data, with TLS in transit.Three operational surfaces map across with named differences. Backups: MemoryDB snapshots to Amazon S3 map to Memorystore RDB backups exported to a Cloud Storage bucket, on a daily schedule. Auth: MemoryDB Redis ACL users map to Memorystore IAM authentication plus basic AUTH. Encryption: MemoryDB always-on at-rest with a KMS customer key maps to Memorystore CMEK via Cloud KMS on persisted data, with TLS in transit.

Configure Cloud Storage backups, target authentication and Cloud KMS encryption separately.

​
Limitations

Review persistence, failover, shard limits and target security settings before migrating the dataset. △ Where MemoryDB and Memorystore for Valkey diverge
  • 250-shard maximum. MemoryDB supports up to 500 shards. Size the target node types within the lower limit.
  • Customer keys protect persisted data. Cloud KMS covers persisted AOF/RDB files and backups; the live in-memory dataset is not encrypted.
  • Authentication changes. Configure IAM tokens or an AUTH credential; MemoryDB ACL users are not automatically retained.

​
Other considerations

Seed the new instance from an RDB restore or repopulate rebuildable data before cutover. Changing the endpoint does not transfer the live keyspace. Google operates the engine, replication, snapshots and failover. You select instance and shard sizing, replicas and the AOF/RDB policy. Configure backups and test recovery against the application’s data-loss requirements.

​
On Azure

​
How it works

The adapter changes the application endpoint from MemoryDB to Azure Managed Redis. Your Redis client connects directly using the Redis serialization protocol (RESP). Azure Managed Redis runs the Redis Enterprise engine with Redis 7.4.x support. Review command restrictions and target authentication when configuring the client. Azure Managed Redis includes RediSearch, RedisJSON, RedisBloom and RedisTimeSeries. Module availability does not establish MemoryDB-compatible durability: the two services acknowledge and persist writes differently.
Before: on AWS your app's Redis client speaks RESP to a MemoryDB cluster. After: on Azure the same client speaks the same RESP wire to a native Azure Managed Redis instance running the Redis Enterprise engine; the endpoint is rewired at the build, with no proxy in the data path; configure the target's authentication, TLS and topology.Before: on AWS your app's Redis client speaks RESP to a MemoryDB cluster. After: on Azure the same client speaks the same RESP wire to a native Azure Managed Redis instance running the Redis Enterprise engine; the endpoint is rewired at the build, with no proxy in the data path; configure the target's authentication, TLS and topology.

The application connects directly to Azure Managed Redis using RESP.

​
Persistence and zone failover

Azure Managed Redis acknowledges writes on the primary and replicates asynchronously. Configure persistence separately: RDB snapshots run every 60 minutes, 6 hours or 12 hours; AOF is saved once per second. The Enterprise engine no longer offers the per-write always option. On an HA instance, AOF runs only on replica shards; primary shards have appendonly disabled. Acknowledgment therefore does not wait for disk persistence. Persistence is not a backup or point-in-time recovery feature, and the service SLA does not guarantee protection from data loss. Zone redundancy is the default in regions with availability zones and requires the HA configuration. Microsoft describes typical zone-failover downtime as 10-15 seconds. Retry dropped in-flight requests. A promoted replica may lack recent acknowledged writes, usually a period measured in seconds that depends on replication lag.
MemoryDB commits each write to a distributed multi-AZ transactional log before acknowledging, so it is durable at ack. Azure Managed Redis acknowledges from the primary shard in memory, replicates asynchronously to replicas in another zone, and persists AOF once per second on the replica shards only, since the primary has appendonly disabled. So a write is acknowledged before it is durable.MemoryDB commits each write to a distributed multi-AZ transactional log before acknowledging, so it is durable at ack. Azure Managed Redis acknowledges from the primary shard in memory, replicates asynchronously to replicas in another zone, and persists AOF once per second on the replica shards only, since the primary has appendonly disabled. So a write is acknowledged before it is durable.

The primary acknowledges writes before replica-side AOF persistence. MemoryDB commits to its distributed log first.

​
Sharding, the keyspace, and active geo-replication

MemoryDB shards its keyspace. Azure Managed Redis is clustered by default; the OSSCluster policy supports Redis Cluster hash slots and MOVED/ASK redirects. Azure chooses shard count from the service size (SKU), so you size the instance instead of specifying the source shard count. Active geo-replication supports up to five writable instances. Each commits locally and propagates writes asynchronously; conflict-free replicated data types (CRDTs) merge concurrent updates. A region failure can lose recent writes that have not propagated. Active geo-replication cannot be combined with RDB/AOF persistence. Assess both the conflict behavior and the loss window when choosing it.
A MemoryDB cluster's shard-and-hash-slot keyspace maps to Azure Managed Redis clustered by default with the OSSCluster policy, which reproduces the Redis Cluster API. Active geo-replication links up to five instances in an active-active configuration using conflict-free replicated data types; cross-region replication is asynchronous and eventual, committing locally and propagating in the background, so recent writes to a failed region can be lost.A MemoryDB cluster's shard-and-hash-slot keyspace maps to Azure Managed Redis clustered by default with the OSSCluster policy, which reproduces the Redis Cluster API. Active geo-replication links up to five instances in an active-active configuration using conflict-free replicated data types; cross-region replication is asynchronous and eventual, committing locally and propagating in the background, so recent writes to a failed region can be lost.

OSSCluster supports Redis Cluster hash slots. Active geo-replication uses asynchronous CRDT conflict merging.

​
Backups, auth, and encryption

Backups. Use Azure Managed Redis Import and Export with a storage account to seed an instance or capture a backup. These are separate from RDB/AOF persistence. MemoryDB snapshots to S3 do not transfer automatically. Authentication. Azure Managed Redis defaults to Microsoft Entra ID on new instances, with managed identity enabled. Add users or service principals to its Redis users list and configure the application identity. Access keys remain available and can be disabled after Entra authentication is configured. MemoryDB ACL users are not automatically converted to Entra identities. Encryption. Azure Managed Redis encrypts disk data with platform-managed keys and supports a customer key through Azure Key Vault in all tiers. It requires TLS 1.2 or 1.3 by default. The customer key covers persistence disks, OS disks and export files; the service does not encrypt the live in-memory dataset.
Three operational surfaces map over with named differences. Backups: MemoryDB snapshots to Amazon S3 map to Azure Managed Redis Import/Export against a storage account. Auth: MemoryDB Redis ACL users map to Microsoft Entra ID, the default on new caches, with a Redis users list and access keys. Encryption: MemoryDB always-on at-rest with a KMS customer key maps to platform-managed keys in all tiers plus a customer-managed key via Key Vault, with TLS 1.2 or 1.3 required; in-memory data is not encrypted.Three operational surfaces map over with named differences. Backups: MemoryDB snapshots to Amazon S3 map to Azure Managed Redis Import/Export against a storage account. Auth: MemoryDB Redis ACL users map to Microsoft Entra ID, the default on new caches, with a Redis users list and access keys. Encryption: MemoryDB always-on at-rest with a KMS customer key maps to platform-managed keys in all tiers plus a customer-managed key via Key Vault, with TLS 1.2 or 1.3 required; in-memory data is not encrypted.

Import/Export handles backups; Entra handles identities; Key Vault customer keys protect disk data.

​
Limitations

Review the persistence, replication, sharding and encryption differences before migrating. △ Where MemoryDB and Azure Managed Redis diverge
  • Geo-replication excludes RDB/AOF. Up to five writable instances propagate changes asynchronously and merge with CRDTs. Recent writes to a failed region can be lost.
  • Azure chooses shard count. Select the instance size (SKU); the source shard layout is not retained.
  • The live dataset is not encrypted. The customer key protects persistence disks, OS disks and export files, not data in RAM.

​
Other considerations

Seed the new instance with Import from a storage account or repopulate rebuildable data. Changing the endpoint does not transfer the live keyspace. Microsoft operates the engine, replication and failover. You select capacity, HA and persistence settings and whether to use active geo-replication. Review its incompatibility with AOF/RDB and test the selected recovery path.

​
On OCI

​
How it works

The adapter changes the application endpoint from MemoryDB to OCI Cache. OCI Cache supports Valkey 8.1 or 7.2 and Redis 7.0 using the Redis serialization protocol (RESP), with TLS required by default. The application connects directly. Review restricted commands and configure the client for the target topology and security settings. OCI Cache offers a sharded topology for partitioned datasets. Its documented persistence and failover behavior does not establish MemoryDB’s guarantee that each acknowledged write is committed across availability zones.
Before: on AWS your app's Redis client speaks RESP to a MemoryDB cluster. After: on Oracle Cloud the same client speaks the same RESP wire to a native OCI Cache cluster running Valkey or Redis; the endpoint is rewired at the build, with no proxy in the data path; configure the target's authentication, TLS and topology.Before: on AWS your app's Redis client speaks RESP to a MemoryDB cluster. After: on Oracle Cloud the same client speaks the same RESP wire to a native OCI Cache cluster running Valkey or Redis; the endpoint is rewired at the build, with no proxy in the data path; configure the target's authentication, TLS and topology.

The application connects directly to OCI Cache using RESP over TLS.

​
Persistence and recovery guarantees

OCI Cache uses primary and replica nodes, but the reviewed documentation does not state whether replication is synchronous or asynchronous or define a failover data-loss window. It provides on-demand RDB snapshots and Object Storage export, with no AOF setting or built-in backup scheduler. Schedule backups through the CLI or API if needed. These documented controls do not establish that every acknowledged write survives failure. OCI Cache places nodes across fault and availability domains where possible. Each shard, or a non-sharded cluster, can have a primary and up to four replicas. The failover loss window, exact mechanics and an OCI Cache-specific SLA percentage are unpublished in the reviewed documentation. Establish the required recovery-point objective (RPO), the amount of data the application can afford to lose, with the provider before storing irreplaceable records. A cache rebuilt from a separately durable store avoids relying on an unspecified recovery guarantee.
MemoryDB commits each write to a documented distributed multi-AZ transactional log before acknowledging, so its durability is a published guarantee. OCI Cache acknowledges from the primary node and keeps replicas, but Oracle does not publish whether replication is synchronous or asynchronous; durability rests on on-demand RDB snapshots and Object Storage export, with no AOF and no built-in scheduler. So its recovery guarantee is not documented.MemoryDB commits each write to a documented distributed multi-AZ transactional log before acknowledging, so its durability is a published guarantee. OCI Cache acknowledges from the primary node and keeps replicas, but Oracle does not publish whether replication is synchronous or asynchronous; durability rests on on-demand RDB snapshots and Object Storage export, with no AOF and no built-in scheduler. So its recovery guarantee is not documented.

MemoryDB documents distributed commit durability. The reviewed OCI Cache documentation does not define replication mode or failover data loss.

​
Sharding and the keyspace

OCI Cache sharded clusters use an odd shard count from 3 to 99, up to 100 nodes total and up to 500 GB per node. Each shard has a primary and up to four replicas. Redis Cluster hash slots and MOVED/ASK redirects support cluster-aware clients; the node and replica limits still differ from MemoryDB. MemoryDB allows five replicas per shard; OCI Cache allows four. Size read-heavy shards accordingly and verify that the client supports cluster mode with hostnames. OCI also offers non-sharded clusters of one to five nodes for datasets that fit one primary.
A MemoryDB cluster partitions the keyspace across shards, each a primary plus up to five replicas. An OCI Cache sharded cluster maps directly: an odd shard count from three to ninety-nine, each shard a primary plus up to four replicas, up to one hundred nodes and five hundred gigabytes per node, using the Redis Cluster hash-slot keyspace. A non-sharded OCI Cache cluster is one to five nodes.A MemoryDB cluster partitions the keyspace across shards, each a primary plus up to five replicas. An OCI Cache sharded cluster maps directly: an odd shard count from three to ninety-nine, each shard a primary plus up to four replicas, up to one hundred nodes and five hundred gigabytes per node, using the Redis Cluster hash-slot keyspace. A non-sharded OCI Cache cluster is one to five nodes.

OCI Cache supports 3-99 shards, using odd shard counts, with up to four replicas per shard and 100 nodes total.

​
Backups, auth, and encryption

Backups. OCI Cache creates on-demand RDB snapshots with retention from 1 to 35 days (7 by default), and can export them to Object Storage for longer retention or cross-region transfer. No built-in scheduler is provided; automate the CLI or API, for example with cron, for regular backups. Authentication. Create OCI Cache users with ACL policies that restrict commands, keys and Pub/Sub channels. Associate them with the target cluster; source MemoryDB users are not copied automatically. With IAM authentication, the application connects using the cache username and a generated token that expires after one hour, so configure token renewal. IAM permissions also govern cluster administration and token creation. Private subnets and network security groups restrict network access separately. Encryption. OCI Cache requires TLS connections by default. The reviewed cluster-creation documentation does not expose an at-rest customer key or OCI Vault key argument. Do not assume that a MemoryDB customer-key requirement is supported.
Three operational surfaces map across with named differences. Backups: MemoryDB snapshots to Amazon S3 map to OCI Cache on-demand RDB snapshots exported to an Object Storage bucket, driven by your own scheduler. Auth: OCI Cache users have ACL policies for commands, keys and channels; IAM authentication supplies expiring connection tokens. OCI IAM also controls cluster administration. Encryption: MemoryDB always-on at-rest with a KMS customer key has no documented customer-set OCI Cache analog, though TLS in transit is mandatory by default.Three operational surfaces map across with named differences. Backups: MemoryDB snapshots to Amazon S3 map to OCI Cache on-demand RDB snapshots exported to an Object Storage bucket, driven by your own scheduler. Auth: OCI Cache users have ACL policies for commands, keys and channels; IAM authentication supplies expiring connection tokens. OCI IAM also controls cluster administration. Encryption: MemoryDB always-on at-rest with a KMS customer key has no documented customer-set OCI Cache analog, though TLS in transit is mandatory by default.

Schedule Object Storage backups, configure cache users and renew connection tokens.

​
Limitations

Review undocumented recovery guarantees, backup scheduling and access controls before migration. △ Where MemoryDB and OCI Cache diverge
  • Recovery guarantees need verification. The reviewed documentation does not state replication mode or the amount of data a failover can lose. Do not assume MemoryDB-compatible distributed durability.
  • Backups require scheduling. RDB snapshots have 1-35-day retention and Object Storage export. No AOF setting or built-in scheduler is documented.
  • Configure target users and token renewal. Recreate the required command, key and channel permissions in OCI Cache ACL policies. IAM connection tokens expire after one hour.
  • A customer-managed at-rest key was not established. TLS is mandatory by default, but the reviewed cluster resource does not expose a customer or Vault key.
  • Four replicas per shard. MemoryDB permits five. Size read-heavy shards within OCI’s replica and total-node limits.

​
Other considerations

Seed the new cluster from an RDB snapshot in Object Storage or repopulate rebuildable data. Changing the endpoint does not copy the live keyspace. Oracle operates replication and failover. You schedule snapshots and export, for example through cron. Obtain the recovery and access guarantees needed for the workload; retry-safe operations do not recover records that were never persisted.

​
On Private Kubernetes

​
How it works

The adapter changes the application endpoint from MemoryDB to a Valkey deployment installed with the Bitnami Helm chart in the customer’s Kubernetes cluster. Your client connects directly using the Redis serialization protocol (RESP). You operate the Valkey server and configure its authentication and topology. Self-hosting gives you control over Valkey administration, including commands such as CONFIG and SLAVEOF. It also makes persistence, replication, TLS, backups and failover your deployment responsibilities. The chart does not provide MemoryDB’s managed durability guarantee.
Before: on AWS your app's Redis client speaks RESP to a managed MemoryDB cluster. After: on Kubernetes cluster the same client speaks the same RESP wire to a Valkey deployment you run via the Bitnami Helm chart; the endpoint is rewired at the build, with no proxy in the data path; configure the target's authentication, TLS and topology, and you operate the server.Before: on AWS your app's Redis client speaks RESP to a managed MemoryDB cluster. After: on Kubernetes cluster the same client speaks the same RESP wire to a Valkey deployment you run via the Bitnami Helm chart; the endpoint is rewired at the build, with no proxy in the data path; configure the target's authentication, TLS and topology, and you operate the server.

The application connects directly to the Valkey service in the customer’s Kubernetes cluster.

​
Persistence and failover you operate

Valkey replicates asynchronously. Configure an append-only file (AOF) on a PersistentVolume and choose appendfsync: always syncs each write batch locally before acknowledgment, everysec can lose about one second of disk writes, and no delegates flushing to the operating system without a fixed loss bound. RDB snapshots are another recovery option. WAIT and WAITAOF can wait for replica or AOF acknowledgments, but do not guarantee that failover preserves acknowledged writes. A local disk sync is not a distributed commit across zones. For automatic failover, configure Sentinel to monitor the primary and promote a replica. Choose the replica count and failure-domain placement for the deployment. A promoted replica can be missing acknowledged writes; failover timing and PersistentVolume recovery depend on your configuration and have no managed SLA.
MemoryDB commits each write to a managed distributed multi-AZ transactional log before acknowledging, so it is durable at ack. Self-hosted Valkey local persistence depends on your policy. AOF appendfsync always completes a local fsync before acknowledgment; everysec syncs about once per second, and no delegates flushing to the operating system without a fixed loss bound. RDB snapshots provide another recovery point. Replication is asynchronous, so failover can lose acknowledged writes missing from the promoted replica despite local persistence.MemoryDB commits each write to a managed distributed multi-AZ transactional log before acknowledging, so it is durable at ack. Self-hosted Valkey local persistence depends on your policy. AOF appendfsync always completes a local fsync before acknowledgment; everysec syncs about once per second, and no delegates flushing to the operating system without a fixed loss bound. RDB snapshots provide another recovery point. Replication is asynchronous, so failover can lose acknowledged writes missing from the promoted replica despite local persistence.

Local AOF/RDB persistence and asynchronous replication do not reproduce MemoryDB’s distributed commit log.

​
Topology and the keyspace

MemoryDB partitions its keyspace across shards. The Bitnami chart’s default primary-replica topology uses a single primary instead of Valkey Cluster sharding. The dataset and write load must fit that primary unless you configure a different deployment. Valkey supports Cluster mode, but shard placement and slot migration require separate setup and operation. Decide whether to size one primary or operate a sharded cluster. Configure the client for the chosen topology; a client that requires cluster discovery may need changes for the default non-cluster deployment.
A MemoryDB cluster always partitions the keyspace across shards. The Bitnami chart's default is a single primary with replicas, not Valkey Cluster sharding, so a sharded MemoryDB cluster maps to a vertically sized primary. The Valkey engine supports Cluster mode for the hash-slot keyspace, but enabling and operating sharding is your setup.A MemoryDB cluster always partitions the keyspace across shards. The Bitnami chart's default is a single primary with replicas, not Valkey Cluster sharding, so a sharded MemoryDB cluster maps to a vertically sized primary. The Valkey engine supports Cluster mode for the hash-slot keyspace, but enabling and operating sharding is your setup.

The default topology uses one primary; sharded Valkey Cluster operation needs separate configuration.

​
Persistence storage, auth, and encryption

Backups. Run SAVE or BGSAVE and copy dump.rdb from the PersistentVolume to durable storage outside the cluster. You set the schedule and retention and test restoration. MemoryDB’s managed S3 snapshot service is not recreated. Authentication. The chart enables password AUTH by default. Configure Valkey ACL users and access strings to implement the required permissions. These users are part of the deployment you manage. Encryption. At-rest encryption depends on the PersistentVolume storage class and underlying disks. If the customer requires their own key, select storage that supports that key and configure it explicitly. The chart’s default TLS setting is off; enable TLS and configure certificates to preserve encrypted client connections.
Three operational surfaces are yours to run. Backups: MemoryDB snapshots to Amazon S3 become a manual SAVE plus copying dump.rdb off the PersistentVolume, which you manage. Auth: MemoryDB Redis ACL users map to password AUTH on by default plus ACL via engine config, your setup. Encryption: MemoryDB always-on at-rest with a KMS customer key becomes the encryption of Kubernetes PersistentVolume storage class, and TLS in transit is off by default in the chart until you configure it.Three operational surfaces are yours to run. Backups: MemoryDB snapshots to Amazon S3 become a manual SAVE plus copying dump.rdb off the PersistentVolume, which you manage. Auth: MemoryDB Redis ACL users map to password AUTH on by default plus ACL via engine config, your setup. Encryption: MemoryDB always-on at-rest with a KMS customer key becomes the encryption of Kubernetes PersistentVolume storage class, and TLS in transit is off by default in the chart until you configure it.

You configure backup copies, ACL users, encrypted storage and TLS.

​
Limitations

Review persistence, replica placement, failover, backup operation and encrypted connections before migration. △ Where MemoryDB and self-hosted Valkey diverge
  • TLS is off by default. Enable it in chart values and configure certificates for encrypted client connections.
  • You operate backups. Use SAVE/BGSAVE, copy dump.rdb outside the cluster and test restoration.
  • Storage controls at-rest encryption. A customer-key requirement needs a storage class and disk configuration that explicitly support that key; generic encrypted storage is insufficient.
  • Sharding requires separate setup. The default topology has a single primary with replicas. Size that primary or configure and operate Valkey Cluster.

​
Other considerations

Seed the deployment from a compatible RDB/AOF import or repopulate rebuildable data. Active sessions do not survive the endpoint change. You operate the server, underlying compute and storage, upgrades, replicas, persistence, TLS and backups. Include those resources and operating work in the deployment cost; the chart does not provide a managed availability or durability SLA. Service Catalog.