General trade-offs
Compare the command and recovery contract before selecting a node size. This page focuses on provisioned Valkey and Redis workloads. Confirm the origin shape in the provisioned service catalog or serverless-origin profile. A serverless origin does not imply serverless target capacity or billing. Use the environment sections below to identify the target cache and its operating model. A RESP-compatible product available in a cloud is not automatically another adapter for that environment.Commands, topology and recovery
Keep engine versions and command exceptions in the catalog review. In particular, classic Memorystore for Redis is a different topology from Memorystore’s clustered products. Azure’s module requirements can constrain both clustering and eviction policy.
Operating ownership
Keep a decision record with the engine version, topology, command fixture, loss/miss budget, failure observations and the person who can perform recovery in the customer’s environment. Compare cost only after these requirements pass.
Google Cloud
Memorystore for Redis
The documented backend is the classic Memorystore for Redis instance. Google operates the engine and failover mechanism; your team owns capacity, eviction policy, access and recovery acceptance. The strength of this option is managed operation for a workload that fits its single-primary shape and supported Redis command set. It is not the same engine or topology as a sharded Valkey replication group. Valkey-specific commands, required modules and multi-shard capacity can disqualify this mapping even when ordinary GET and SET succeed. Memorystore for Redis Cluster and Memorystore for Valkey are distinct products, not settings that turn this adapter into a different one. Check the Memorystore mapping against the exact commands and topology you require.Workload example: disposable product summaries
A storefront caches rendered product summaries for five minutes while PostgreSQL remains authoritative. It uses GET, SET with expiry and deletion after updates. Memorystore fits this shape when the working set and command set fit its instance model and the team wants provider-operated cache infrastructure. A workload requiring an unsupported Valkey command or more write capacity than the single-primary design permits needs a different documented deployment design; increasing read replicas does not resolve either requirement. Budget for memory headroom and the database’s extra work during warm-up. Cut over a small application cohort to an empty test cache and bound database concurrency. Check invalidation while both endpoints are in use. Keeping the old endpoint provides a reversal path only if its stale values expire or are invalidated before clients return.Run a bounded cache-pressure probe
This first probe tests the disposable-cache example. It does not certify stream durability or distributed locking. It uses a tiny authoritative fixture in the script so that missing cache entries can be checked unambiguously; repeat the workload through your real application’s database-backed path to measure the production miss cost.1
Prepare an isolated cache
Use a dedicated single-endpoint test cache with no customer data. Configure a supported evicting policy through its deployment/control plane and record that policy. Permit INFO for the test identity, use TLS and obtain its CA certificate if it is not publicly trusted. Do not turn off certificate verification.This is a native RESP test, so it does not require a local
tensor9 adapt svc run process. A management adapter cannot provision or resize a cache simply because you start it. Provision the target through your deployment workflow and use its native endpoint.2
Run the fixture
Install the Python client with An interrupted cleanup leaves only namespaced keys with a five-minute TTL. Do not rerun while a previous process still writes this namespace. See the Redis client connection reference for your target’s TLS options.
python3 -m pip install redis. Save this as cache-pressure-check.py, replace the example hostname and port with the test endpoint, and run python3 cache-pressure-check.py. Supply the test username and password when prompted. For a target using token authentication, use its documented token and renewal mechanism instead.The run refuses an existing test namespace, writes at most 2 GiB of disposable values, and stops after observing an eviction. The payload cap is a safety bound, not a recommended cache size. Set a lower bound in the code if your test budget requires it.3
Interpret the observation
Expected: the native eviction counter increases and every successful fixture read returns its authoritative value. Zero misses for the two hot keys can be legitimate because other keys were evicted. No observed eviction is inconclusive, not a pass; use a smaller dedicated cache or an explicitly approved larger test budget.Write rejection points to policy or capacity, a timeout needs investigation, and an incorrect returned value fails correctness. Inspect the configured policy and native metrics before increasing capacity. The eviction reference explains the counter and policy distinction.
4
Qualify the application and clean up
Repeat through the real read-through path with representative key skew, values and concurrency. Set the maximum database request rate and p99 response budget before the run. Test cold start and a controlled failover separately. Reject a capacity/warm-up plan that exceeds either budget even if the cache itself stays responsive.Stop generators, verify the test keys are gone, and retire dedicated infrastructure through its deployment workflow. Preserve only nonsecret results and configuration. Explain can inspect management decisions; it does not trace GET/SET traffic sent directly to the engine.
Microsoft Azure
Azure Managed Redis
Azure Managed Redis runs a Redis Enterprise engine under Microsoft’s operation. Its supported JSON and search modules can suit applications whose cache also serves document queries. The trade-offs include its engine-specific command set, capacity tiers, clustering policies and module constraints. A Valkey command is not supported merely because the client connects over RESP. Use the Azure mapping to compare the required module versions, multi-key behavior and topology. Select the clustering policy before assuming a transaction can update keys in different slots. Cache settings belong to the control plane rather than runtime CONFIG commands.Workload example: JSON search
A customer-support product stores JSON documents and serves module-backed searches. Azure Managed Redis is a candidate when its modules and query behavior match the application’s fixtures and managed engine operation fits the team’s responsibilities. A mandatory module version or Valkey-only command absent from that mapping excludes it; a larger capacity tier does not repair that mismatch. Search changes the memory calculation. The documented RediSearch configuration requires its supported clustering policy and no-eviction behavior. Size for documents, indexes, temporary work and growth. Test how write failures reach the application when the memory budget is exhausted, and exercise the capacity-change procedure before production depends on it. For migration, copy source documents through the supported transfer path, rebuild indexes and compare query results before switching reads. A completed key copy does not establish that indexes are ready. Keep the source until both document updates and query answers are reconciled. Do not use the evicting-cache probe above as acceptance evidence for this no-eviction search workload.DigitalOcean
Managed Valkey
DigitalOcean Managed Valkey provides a provider-operated Valkey engine. It can fit workloads that use the supported core command set and fit the mapped primary’s capacity. The trade-offs include the mapped topology, service-defined persistence, access controls and recovery options. A cluster-mode ElastiCache workload cannot assume its keyspace is spread across equivalent target shards. Compare the application’s commands, required memory, write rate and recovery budget with the configured managed plan. DigitalOcean distinguishes standby availability from read-only replicas and does not offer its general managed-database backup/restore feature for Valkey. Do not budget for read scaling or recoverability on that assumption. Modules or exact engine features outside the managed command set are compatibility requirements, not sizing problems. See the DigitalOcean service limits and managed-cache tuning guidance.Workload example: event processing with streams
A worker service uses Valkey streams for events that do not exist in another durable queue. Consumers maintain pending work and acknowledge completed entries. Keeping the RESP client avoids a protocol rewrite, but does not answer what survives a primary failure. Test the exact stream commands and options, consumer recovery, acknowledged writes followed by connection loss, and restoration of pending work. Accept the managed deployment only when retained history and observed recovery meet the workload’s tolerated loss and redelivery. The provider operates the engine; the application team still owns idempotent side effects and consumer recovery. If the available recovery contract does not fit, change the persistence design before production rather than tuning memory around it. Account for retained events, standby capacity and memory consumed by pending work. Shortening retention is a data-retention decision: test it against the slowest permitted consumer and longest expected outage. Define any independent recoverable copy explicitly; provider-managed persistence is not an application backup policy. Migration needs a fenced transfer of state and consumer positions. Rewarming a cache cannot recover unique stream entries. Specify which side accepts new events, when consumers stop, and how to reconcile events written after cutover if you return to the source.OCI
OCI Cache
OCI Cache offers an Oracle-operated Redis or Valkey engine with sharded and non-sharded cluster choices. It can fit a workload requiring managed cache operation in OCI when the chosen engine, topology and commands match the application’s contract. Compare shard count and per-shard capacity with the actual key distribution rather than treating total memory as sufficient evidence. Persistence and backup controls differ from an operated Valkey server. Do not assume you can reproduce the source AOF policy with an engine setting, or that a backup exists on the schedule the application requires. Establish the permitted backup, export, restore and access procedures through the service’s control plane. Check the OCI Cache overview and managed-cache tuning guidance. For a disposable cache, qualify eviction, cold-start misses and the database’s recovery load. For sessions or stream history that cannot be reconstructed, test acknowledged-write loss and recovery into a new isolated cluster. Require a restoration result with usable credentials and endpoints, not only a completed backup operation. Oracle owns the managed engine; the application and platform teams own the recovery requirement and its exercised procedure.Scaleway
Managed Redis, Valkey or Dragonfly
Compare the managed and operated caches within the same required region and network:
For disposable session lookups backed by a durable database, test expiry, eviction and miss load on each candidate. For a stream holding unique events, compare retained history and consumer recovery after failover before considering cost. Neither managed operation nor an acknowledged write establishes the tolerated data-loss contract.
The managed Redis profile and Valkey profile describe different control surfaces. Set the managed service’s supported engine settings deliberately. On Valkey, establish the image version, persistence and primary/replica or Cluster topology through deployment configuration.
For Dragonfly, test the exact stream or cache fixture before comparing throughput. A successful cluster-aware connection does not establish Redis Cluster slot sharding. Use its supported cache mode rather than copying a Valkey eviction-policy string, and include operating work in the comparison. See operated-cache tuning.
For a serverless ElastiCache origin, read its separate Scaleway profile. Do not assume the provisioned-origin menu applies to it.