Skip to main content
On this page

​
Coverage by target cloud

​
How the backends compare

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

​
Infrastructure-only adaptation

​
On Google Cloud

​
How it works

When the stack is deployed, Tensor9 points your application at Memorystore for Valkey instead of MemoryDB. Your Redis or Valkey client connects directly using the Redis serialization protocol (RESP); Tensor9 does not proxy the requests. The backend 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 talks RESP to a MemoryDB cluster. After: on Google Cloud, the same client talks RESP directly to a Memorystore for Valkey instance, with no proxy in between.Before: on AWS, your app's Redis client talks RESP to a MemoryDB cluster. After: on Google Cloud, the same client talks RESP directly to a Memorystore for Valkey instance, with no proxy in between.

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 backend topology and follows MOVED and ASK redirects. The backend 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 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 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 backend credentials and token refresh in the application; source ACL users are not the same as Google Cloud 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, backend authentication and Cloud KMS encryption separately.

​
Limitations

Where MemoryDB and Memorystore for Valkey differ
  • Synchronous multi-zone durability is not supported. Memorystore replicates asynchronously, so a failover can lose acknowledged writes that had not reached the promoted replica. AOF and RDB settings do not close that window.
  • Clusters larger than 250 shards are not supported. MemoryDB allows up to 500 shards. Size node types so the dataset fits within 250.
  • Encryption of the live dataset is not supported. Customer keys in Cloud KMS protect persisted AOF/RDB files and backups; the in-memory dataset is not encrypted.
  • You must set up authentication again. MemoryDB ACL users are not kept. Configure IAM tokens or an AUTH credential in the application.

​
Other considerations

  • Moving data. Seed the new instance from an RDB restore, or repopulate data you can rebuild, before cutover. Changing the endpoint does not move the live keyspace.
  • Who does what. Google operates the engine, replication, snapshots and failover. You choose 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

When the stack is deployed, Tensor9 points your application at Azure Managed Redis instead of MemoryDB. Your Redis client connects directly using the Redis serialization protocol (RESP), with no proxy in between. Azure Managed Redis runs the Redis Enterprise engine with Redis 7.4.x support. Review command restrictions and backend authentication when configuring the client. Azure Managed Redis includes RediSearch, RedisJSON, RedisBloom and RedisTimeSeries. Those modules do not change durability: the two services acknowledge and persist writes differently.
Before: on AWS, your app's Redis client talks RESP to a MemoryDB cluster. After: on Azure, the same client talks RESP directly to an Azure Managed Redis instance running the Redis Enterprise engine, with no proxy in between.Before: on AWS, your app's Redis client talks RESP to a MemoryDB cluster. After: on Azure, the same client talks RESP directly to an Azure Managed Redis instance running the Redis Enterprise engine, with no proxy in between.

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

Where MemoryDB and Azure Managed Redis differ
  • Durability behaves differently: writes are acknowledged before they reach disk. The primary acknowledges from memory and replicates asynchronously, and AOF runs only on replica shards, once per second. A failover can lose recent acknowledged writes.
  • Persistence is not supported with active geo-replication. Geo-replication excludes RDB/AOF. Up to five writable instances propagate changes asynchronously and merge them with CRDTs, so recent writes to a failed region can be lost.
  • Choosing the shard count is not supported. Azure sets shards from the instance size (SKU). The source shard layout is not kept.
  • Encryption of the live dataset is not supported. The customer key protects persistence disks, OS disks and export files, not data in memory.

​
Other considerations

  • Moving data. Seed the new instance with Import from a storage account, or repopulate data you can rebuild. Changing the endpoint does not move the live keyspace.
  • Who does what. Microsoft operates the engine, replication and failover. You choose capacity, HA and persistence settings, and whether to use active geo-replication, which cannot be combined with AOF/RDB. Test the recovery path you choose.

​
On OCI

​
How it works

When the stack is deployed, Tensor9 points your application at OCI Cache instead of MemoryDB. 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 backend’s topology and security settings. OCI Cache offers a sharded topology for partitioned datasets. Oracle does not document a guarantee like MemoryDB’s that each acknowledged write is committed across availability zones.
Before: on AWS, your app's Redis client talks RESP to a MemoryDB cluster. After: on Oracle Cloud, the same client talks RESP directly to an OCI Cache cluster running Valkey or Redis, with no proxy in between.Before: on AWS, your app's Redis client talks RESP to a MemoryDB cluster. After: on Oracle Cloud, the same client talks RESP directly to an OCI Cache cluster running Valkey or Redis, with no proxy in between.

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

​
Persistence and recovery guarantees

OCI Cache uses primary and replica nodes, but Oracle’s documentation does not say whether replication is synchronous or asynchronous, or how much data a failover can lose. 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. None of these controls promises that every acknowledged write survives a 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. Oracle does not publish the failover loss window, the failover mechanics or an SLA percentage specific to OCI Cache. 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 commits each write across zones before acknowledging it; Oracle does not document OCI Cache’s replication mode or failover 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 OCI Cache 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. Creating a cluster offers no setting for a customer-managed or OCI Vault at-rest key. 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

Where MemoryDB and OCI Cache differ
  • Recovery behaves differently: Oracle does not document it. Oracle does not state the replication mode or how much data a failover can lose. Do not assume MemoryDB-style durability across zones.
  • You must schedule backups yourself. RDB snapshots are taken on demand, kept 1 to 35 days and can be exported to Object Storage. There is no AOF setting and no built-in scheduler.
  • You must recreate users and renew tokens. Recreate the command, key and channel permissions you need in OCI Cache ACL policies. IAM connection tokens expire after one hour.
  • You must not rely on a customer-managed at-rest key. TLS is required by default, but the cluster resource exposes no customer or Vault key setting.
  • More than four replicas per shard are not supported. MemoryDB permits five. Size read-heavy shards within OCI’s replica and total-node limits.

​
Other considerations

  • Moving data. Seed the new cluster from an RDB snapshot in Object Storage, or repopulate data you can rebuild. Changing the endpoint does not copy the live keyspace.
  • Who does what. Oracle operates replication and failover. You schedule snapshots and exports, for example with cron, and get the recovery and access guarantees the workload needs from Oracle. Retrying an operation does not recover a record that was never persisted.

​
On Private Kubernetes

​
How it works

When the stack is deployed, Tensor9 points your application at a Valkey deployment, installed with the Bitnami Helm chart in the customer’s Kubernetes cluster, instead of MemoryDB. 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 talks RESP to a managed MemoryDB cluster. After: on the Kubernetes cluster, the same client talks RESP directly to a Valkey deployment you run from the Bitnami Helm chart, with no proxy in between.Before: on AWS, your app's Redis client talks RESP to a managed MemoryDB cluster. After: on the Kubernetes cluster, the same client talks RESP directly to a Valkey deployment you run from the Bitnami Helm chart, with no proxy in between.

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

Where MemoryDB and self-hosted Valkey differ
  • You must operate durability yourself. Valkey replicates asynchronously, and AOF or RDB persist only to the local PersistentVolume. A promoted replica can be missing acknowledged writes, and there is no managed durability or availability SLA.
  • You must turn on TLS. The chart’s default TLS setting is off. Enable it in the chart values and configure certificates for encrypted client connections.
  • You must run backups. Use SAVE or BGSAVE, copy dump.rdb outside the cluster, and test restoring it.
  • Encryption at rest behaves differently: it depends on your storage. A customer-key requirement needs a storage class and disks that explicitly support that key; generic encrypted storage is not enough.
  • Sharding is not set up by default. The default topology is one primary with replicas. Size that primary, or configure and operate Valkey Cluster yourself.

​
Other considerations

  • Moving data. Seed the deployment from a compatible RDB/AOF import, or repopulate data you can rebuild. Active sessions do not survive the endpoint change.
  • Who does what. You operate the server, its compute and storage, upgrades, replicas, persistence, TLS and backups. Include those resources and that work in the deployment cost.

​
Debug this service

For requests through a service adapter, use Explain and request diagnostics to investigate the selected mapping. Follow the BYOC service-adapter debugging runbook to capture and interpret the diagnostic evidence. Service Catalog.