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 Azure | 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 OCI | 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. ## On Private Kubernetes | 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 Valkey deployment you run in the target cluster (the Bitnami chart); the client is unchanged and no proxy sits in the path | | Backup / snapshot / restore | Durability | Partial | Most usage | manual SAVE + copy dump.rdb off the PVC, which you manage | | Persistence (AOF / RDB) | Durability | Supported | Most usage | configure RDB and AOF on a PersistentVolume; appendfsync always syncs locally before acknowledgment, but asynchronous failover can still lose acknowledged writes | | Strong consistency + durable commit | Durability | Partial | Most usage | durability is yours: RDB + AOF (appendfsync you set) on a PersistentVolume; a single-node fsync narrows but never equals MemoryDB's synchronous multi-AZ commit log, and there is no vendor SLA | | Search / JSON / modules (FT.\* / JSON.\*) | Extensions | Out of scope | Full surface | core Valkey types; no modules are bundled with the chart | | Replication / HA / failover | Operations | Partial | Most usage | 1 primary + replicas with Sentinel HA that you configure; there is no vendor SLA | | Admin / config / replication commands (CONFIG / DEBUG / SAVE / SLAVEOF / CLUSTER admin) | Restricted admin | Partial | Full surface | you operate the server and can configure Valkey administrative and replication commands; access still depends on your permissions and configuration | | AUTH / ACL / RBAC | Security | Partial | Most usage | password AUTH is on by default; ACL is available via engine config, your setup | | Encryption at rest | Security | Partial | Most usage | delegated to the Kubernetes PersistentVolume / node-disk layer, so encryption is your storage class's | | Encryption in transit (TLS) | Security | Partial | Common | TLS you configure (off by default in the chart) | | Cluster mode (slot topology) | Topology | Partial | Most usage | the chart default is primary-replica, not Valkey Cluster sharding (the engine supports Cluster; enabling and operating sharding is your setup), where MemoryDB is always sharded | #### 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.
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. [Service Catalog](/service-adapters/catalog).