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.
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.
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.
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. ## On Azure ### Azure Managed Redis | Operation | Area | Support | Depth | Notes | | --------------------------------------------------------------------------------------- | ---------------- | ------------ | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Data-plane commands (strings, hashes, sorted sets, streams, pub/sub, Lua) | Data plane | Supported | Common | the full RESP data plane runs on a native Azure Managed Redis (Redis Enterprise) engine; the client is unchanged and no proxy sits in the path | | Backup / snapshot / restore | Durability | Supported | Most usage | Import / Export on all tiers (to a storage account); restore seeds a new instance | | Persistence (AOF / RDB) | Durability | Partial | Most usage | optional RDB + AOF to a managed disk (for HA, not a point-in-time backup) | | Strong consistency + durable commit | Durability | Partial | Most usage | Azure Managed Redis is zone-redundant with optional AOF (per-second fsync) for intra-region HA, and active geo-replication is asynchronous multi-primary; a failover still has a data-loss window where MemoryDB's synchronous multi-AZ log has none | | Search / JSON / modules (FT.\* / JSON.\*) | Extensions | Supported | Full surface | RediSearch (vector and full-text), JSON, Bloom and TimeSeries are built into the target engine | | Replication / HA / failover | Operations | Supported | Most usage | replication + automatic failover on all tiers; zone-redundant by default | | Admin / config / replication commands (CONFIG / DEBUG / SAVE / SLAVEOF / CLUSTER admin) | Restricted admin | Out of scope | Full surface | the admin / replication / cluster surface moves to the Azure control plane; Azure additionally disables the ACL command, SELECT is unusable on the clustered tier, and FLUSHALL / FLUSHDB are blocked under active geo-replication | | AUTH / ACL / RBAC | Security | Supported | Most usage | access keys + Microsoft Entra ID (the default); data-access ACL (preview) | | Encryption at rest | Security | Supported | Most usage | platform-managed key by default; customer-managed key (CMK via Key Vault) on all tiers | | Encryption in transit (TLS) | Security | Supported | Common | TLS on all tiers (minimum TLS 1.2) | | Cluster mode (slot topology) | Topology | Supported | Most usage | clustered by default (the OSSCluster policy reproduces the Redis Cluster API); shards are auto-managed, so MemoryDB's always-sharded topology maps directly | #### 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.
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.
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.
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.
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 DigitalOcean ### DigitalOcean Managed Valkey | Operation | Area | Support | Depth | Notes | | --------------------------------------------------------------------------------------- | ---------------- | ------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Data-plane commands (strings, hashes, sorted sets, streams, pub/sub, Lua) | Data plane | Supported | Common | the full RESP data plane runs on a native DigitalOcean Managed Valkey engine; the client is unchanged and no proxy sits in the path | | Backup / snapshot / restore | Durability | Partial | Most usage | managed daily backups; restore seeds a new cluster (export / restore UI is not documented) | | Persistence (AOF / RDB) | Durability | Partial | Most usage | disk-backed periodic dump (approximately every 10 minutes); an rdb / off toggle, not a tunable AOF | | Strong consistency + durable commit | Durability | Partial | Most usage | DigitalOcean persists via a coarse periodic disk dump (approximately every 10 minutes) plus daily backups, a far wider data-loss window than a per-write log, and no counterpart to MemoryDB's synchronous multi-AZ commit log | | Search / JSON / modules (FT.\* / JSON.\*) | Extensions | Out of scope | Full surface | core Valkey types only; no search / JSON / Bloom modules | | Replication / HA / failover | Operations | Supported | Most usage | automated failover with at least one standby; availability SLA 99.95% with a standby, 99.5% without | | Admin / config / replication commands (CONFIG / DEBUG / SAVE / SLAVEOF / CLUSTER admin) | Restricted admin | Out of scope | Full surface | the admin / replication / cluster surface moves to the DigitalOcean control plane; DigitalOcean also blocks MONITOR, but uniquely keeps server-side FUNCTION / FCALL | | AUTH / ACL / RBAC | Security | Partial | Most usage | a single AUTH password (no ACL users); finer access is DigitalOcean's trusted-sources firewall (IP / Droplet / tag / app) | | Encryption at rest | Security | Supported | Most usage | encrypted at rest (LUKS); customer-managed keys (BYOK) are not offered | | Encryption in transit (TLS) | Security | Supported | Common | TLS / SSL is required | | Cluster mode (slot topology) | Topology | Out of scope | Most usage | no Redis Cluster sharding, just a single primary + up to 2 read standbys; MemoryDB's always-sharded topology does not map, so size vertically | #### How it works The adapter changes the application endpoint from MemoryDB to DigitalOcean Managed Valkey, which runs Valkey 8. Your client connects directly using the Redis serialization protocol (RESP). Review command restrictions and configure the client for the target's authentication and single-primary topology. DigitalOcean Managed Valkey uses periodic RDB disk dumps and asynchronous standby replication. It does not reproduce MemoryDB's per-write distributed commit log. Check both the topology and the possible data loss before migrating a durable dataset.
The application connects directly to DigitalOcean Managed Valkey using RESP.
#### Durability: a per-write log versus a ten-minute disk dump MemoryDB commits each write to a distributed log across availability zones before acknowledging it. A successful write survives a node or zone loss. DigitalOcean acknowledges writes in memory and replicates asynchronously to standbys. With persistence set to `rdb`, it dumps data every 10 minutes if a key changed; `off` disables dumps and backups, allowing restart to lose data. There is no tunable AOF or `appendfsync` setting. Recovery from disk can lose changes since the last dump, up to about 10 minutes under this schedule. Standby promotion has a separate loss window based on replication lag.
DigitalOcean persists changed data about every 10 minutes. MemoryDB commits each write to a distributed log before acknowledgment.
#### Standby nodes, failover, and the data-loss window DigitalOcean supports one primary and zero, one or two standby nodes. A standby automatically takes over after primary failure. At least one standby is needed for this failover setup. The [availability SLA](https://www.digitalocean.com/sla/databases) is 99.95% with at least one standby and 99.5% without; those percentages do not guarantee preservation of data. Because replication is asynchronous, a promoted standby can be missing recent writes. If no standby is available and recovery uses a disk dump, changes since that dump can be lost. Assess replication lag and the approximately 10-minute dump interval as different recovery cases.
DigitalOcean promotes asynchronous standbys; availability commitments do not guarantee zero data loss.
#### Topology and the keyspace MemoryDB scales writes across shards. DigitalOcean Managed Valkey has no Redis Cluster sharding: it uses one primary with up to two read standbys. The dataset and write load must fit a single primary sized through the service plan. A workload that requires horizontal write scaling has no equivalent topology here. Check whether the dataset fits the largest suitable single-node plan, and configure the Redis client for a non-cluster endpoint; do not assume a cluster-discovery client works unchanged.
The dataset and write load must fit one primary; DigitalOcean Managed Valkey does not shard.
#### Backups, auth, and encryption **Backups.** DigitalOcean provides daily backups with point-in-time recovery. Restoring creates a new cluster. Plan the initial dataset transfer separately; MemoryDB S3 snapshots do not automatically become DigitalOcean backups. **Authentication.** DigitalOcean uses a connection password and a trusted-sources firewall that restricts access by Droplet, Kubernetes cluster, IP, tag or app. The documented target configuration does not establish distinct ACL users with separate command permissions. Network source restrictions do not replace those permissions. **Encryption.** DigitalOcean encrypts data at rest with LUKS and connections with SSL. It does not offer a customer-managed at-rest key, so it cannot meet a requirement to use the customer's own encryption key.
The target uses managed backups, a connection password, network access rules and provider-managed encryption.
#### Limitations Review the single-primary limit, persistence interval, failover behavior and access controls before migration. △ Where MemoryDB and DigitalOcean Managed Valkey diverge * **Recovery can lose acknowledged writes.** A standby may be missing recent writes. Disk recovery can lose changes since the approximately 10-minute RDB dump; these are separate failure cases. * **No tunable AOF.** Persistence offers `rdb` or `off`, with no `appendfsync` control. * **No sharding.** The dataset and write load must fit one primary. A workload requiring horizontal write scaling needs a different topology. * **The SLA covers availability.** The stated 99.95% with standbys and 99.5% without do not guarantee preservation of acknowledged writes. * **No customer-managed key.** DigitalOcean manages the LUKS at-rest encryption key. * **Access uses a shared password and firewall.** The reviewed target model does not establish separate ACL users. Trusted sources restrict network access by Droplet, Kubernetes cluster, IP, tag or app. #### Other considerations Plan a supported dataset transfer before cutover, or repopulate rebuildable data. Changing the endpoint does not copy the live keyspace. DigitalOcean operates backups and failover. You select capacity, standbys and the `rdb` persistence option. The dataset must fit one primary; plan growth within the largest suitable single-node plan. ## On Google Cloud ### Memorystore for Redis | Operation | Area | Support | Depth | Notes | | --------------------------------------------------------------------------------------- | ---------------- | ------------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Data-plane commands (strings, hashes, sorted sets, streams, pub/sub, Lua) | Data plane | Supported | Common | the full RESP data plane runs on a native Memorystore for Valkey engine; the Redis / Valkey client is unchanged and no proxy sits in the path | | Backup / snapshot / restore | Durability | Supported | Most usage | RDB export / import to Cloud Storage plus scheduled managed backups; restore seeds a new instance | | Persistence (AOF / RDB) | Durability | Supported | Most usage | AOF always syncs locally before acknowledgment; everysec and no use periodic or OS-managed flushing. RDB snapshots provide separate recovery points; replicas remain asynchronous | | Strong consistency + durable commit | Durability | Partial | Most usage | Memorystore replicates asynchronously; Google states that on an unexpected failover acknowledged writes may be lost, so MemoryDB's commit-to-log guarantee has no counterpart (AOF / RDB narrow the window, they don't close it) | | Search / JSON / modules (FT.\* / JSON.\*) | Extensions | Supported | Full surface | Memorystore for Valkey provides vector search, JSON and Bloom capabilities | | Replication / HA / failover | Operations | Supported | Most usage | cross-zone read replicas + automatic failover; up to 99.99% SLA on Memorystore for Valkey / Redis Cluster | | Admin / config / replication commands (CONFIG / DEBUG / SAVE / SLAVEOF / CLUSTER admin) | Restricted admin | Out of scope | Full surface | the admin / replication / cluster surface (CONFIG / DEBUG / SAVE / SLAVEOF / CLUSTER admin) moves to the Google control plane; Memorystore additionally blocks CLIENT / COMMAND / OBJECT / ACL / MODULE, and CONFIG moves to gcloud flags | | AUTH / ACL / RBAC | Security | Supported | Most usage | Redis / Valkey AUTH + IAM authentication | | Encryption at rest | Security | Partial | Most usage | CMEK (customer\_managed\_key) on new instances only; platform-managed otherwise | | Encryption in transit (TLS) | Security | Supported | Common | in-transit encryption always applied; optional application-layer TLS 1.2+ | | Cluster mode (slot topology) | Topology | Supported | Most usage | MemoryDB is always sharded; the right target is the sharded Memorystore for Valkey / Redis Cluster (up to 250 shards), not the single-shard classic instance | #### 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.
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 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.
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.
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 OCI ### OCI Cache | Operation | Area | Support | Depth | Notes | | --------------------------------------------------------------------------------------- | ---------------- | ------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Data-plane commands (strings, hashes, sorted sets, streams, pub/sub, Lua) | Data plane | Supported | Common | the full RESP data plane runs on a native OCI Cache (Valkey / Redis) engine; the client is unchanged and no proxy sits in the path | | Backup / snapshot / restore | Durability | Supported | Most usage | on-demand backups (no built-in scheduler, so use cron), export / import to Object Storage, restore to a new cluster | | Persistence (AOF / RDB) | Durability | Out of scope | Most usage | the engine's AOF / RDB parameters are not exposed; durability is managed backup + Object Storage import, not a tunable persistence mode | | Strong consistency + durable commit | Durability | Partial | Most usage | OCI Cache does not expose AOF / RDB knobs; durability rests on managed backup + Object Storage snapshots, and the failover data-loss window and SLA percentage are not published, so MemoryDB's synchronous multi-AZ commit log has no counterpart | | Search / JSON / modules (FT.\* / JSON.\*) | Extensions | Out of scope | Full surface | core types + server-side Lua; no search / JSON / Bloom modules are documented | | Replication / HA / failover | Operations | Partial | Most usage | a primary + up to 4 replicas across fault / availability domains; the exact failover mechanics and SLA percentage are not published | | Admin / config / replication commands (CONFIG / DEBUG / SAVE / SLAVEOF / CLUSTER admin) | Restricted admin | Out of scope | Full surface | the admin / replication / cluster surface moves to the OCI control plane; OCI additionally blocks CONFIG SET / REWRITE (CONFIG GET is kept) and FAILOVER | | AUTH / ACL / RBAC | Security | Supported | Most usage | OCI Cache users with command/key/channel ACL policies; IAM connection tokens expire after one hour | | Encryption at rest | Security | Out of scope | Most usage | at-rest encryption and customer-managed keys are not documented as customer-set arguments; they are platform-managed and not published | | Encryption in transit (TLS) | Security | Supported | Common | TLS is mandatory by default on 6379 | | Cluster mode (slot topology) | Topology | Supported | Most usage | sharded (3-99 shards, up to 100 nodes) or non-sharded (1-5 nodes), so MemoryDB's always-sharded topology maps directly | #### 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.
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 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.
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](https://docs.oracle.com/en-us/iaas/Content/ocicache/cache-users.htm) 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](https://docs.oracle.com/en-us/iaas/Content/ocicache/iam-authentication.htm), 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.
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. ## 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](/cloud-adapter/getting-started/overview) and [configuration](/cloud-adapter/configuration/overview). Use [tuning](/cloud-adapter/tuning/overview) to understand supported request tags, [debugging](/cloud-adapter/debugging/overview) to investigate a request, and [High Fidelity Cloud Emulators](/cloud-adapter/local-testing/overview) to validate a bounded reproduction.