Managed Valkey Services Compared: ElastiCache, MemoryDB, Memorystore, Aiven and More

Picking a managed Valkey service in November 2026 looks simple until you read the details. Every provider says "Valkey", but one runs 9.1 while another stops at 7.3, and one offers AOF while another has no restorable backups. Feature lists hide the differences that cause outages: writes failing with OOM command not allowed when used memory > 'maxmemory' at 70% of the RAM you paid for, a restore that cannot run because persistence was off, or a monitoring script that breaks because CONFIG is blocked. This guide compares AWS ElastiCache and MemoryDB, Google Cloud Memorystore for Valkey, Aiven, DigitalOcean, and Oracle OCI Cache row by row, and shows how to check each claim on your own instance.

Scope and review date: November 2026. This post covers the managed Valkey offerings of AWS (ElastiCache and MemoryDB), Google Cloud (Memorystore for Valkey), Aiven, DigitalOcean, and Oracle (OCI Cache), with a short note on Akamai. Versions, limits, and commands were checked against each provider's documentation on 10 November 2026. They were not run in a lab, so verify them on a test instance before you rely on them. We do not quote prices; the pricing section describes how each provider bills.

Which providers offer managed Valkey, and on which versions?

Upstream Valkey's current stable branches are 9.1 (9.1.3, released 26 October 2026), 9.0 (9.0.7), and 8.1 (8.1.11), according to the Valkey releases page. 9.2 is still a release candidate (9.2.0-rc2, 4 November 2026). Managed providers trail upstream by weeks to years, and how far they trail decides which commands you can use. The TL;DR lists each provider's versions; the cards below cite the pages.

AWS announced Valkey 9.1 for ElastiCache node-based clusters on 23 June 2026; the announcement does not mention Serverless, so check the major version Serverless offers in your Region. Google made Valkey 9.1 generally available on Memorystore on 24 September 2026. You can list what your account can actually create:

# ElastiCache: every Valkey version you can create in this Region
aws elasticache describe-cache-engine-versions --engine valkey \
  --query 'CacheEngineVersions[].EngineVersion'

# MemoryDB: Valkey versions and the patch each one runs
aws memorydb describe-engine-versions --engine valkey \
  --query 'EngineVersions[].[EngineVersion,EnginePatchVersion]'

Interpretation: the ElastiCache list should include 9.1, which AWS made available in every Region where ElastiCache runs. If the MemoryDB list stops at 7.3, commands added in Valkey 8.x and 9.x, such as SET ... IFEQ, hash field expiration, and DELIFEQ, are not available there.

On Memorystore, the version is a property of the instance:

gcloud memorystore instances describe my-valkey --location=us-central1 \
  --format="yaml(engineVersion,mode,shardCount,replicaCount,persistenceConfig.mode)"

Interpretation: mode is CLUSTER or CLUSTER_DISABLED, and persistenceConfig.mode is DISABLED, RDB, or AOF. Google does not allow downgrades after a version upgrade, so record the version before you change it.

How do ElastiCache, MemoryDB, and Memorystore compare?

All three are reached over private networking by default and bill per node (or per GB-hour and request on ElastiCache Serverless). They differ in what they are built for. ElastiCache is a cache that can become durable on 9.0 and later. MemoryDB is durable for every write, by design. Memorystore offers RDB or AOF persistence on a cache-style service.

Sources for this card: the ElastiCache engine versions page, the MemoryDB engine versions page, and the Memorystore supported versions page. MemoryDB Multi-Region needs Valkey 7.3 or later on R7g nodes of size xlarge and up, and it does not support TTLs or vector search.

How do Aiven, DigitalOcean, and OCI Cache compare?

These providers publish their limits more directly than the hyperscalers. Aiven and DigitalOcean both make about 70% of node memory usable by default, which affects sizing more than any other row.

Sources: Aiven's memory usage, advanced parameters, and clustering pages; DigitalOcean's Valkey limits and memory usage pages; and the OCI Cache overview and release notes.

Creating a clustered Aiven service and a DigitalOcean cluster looks like this:

# Aiven: a cluster plan with 3 shards and 1 replica each (6 nodes)
avn service create my-valkey --service-type valkey \
  --plan cluster-4 --cloud CLOUD_AND_REGION --project PROJECT_NAME \
  -c shard_count=3 -c replicas=1

# DigitalOcean: Valkey 9 with one primary and one standby node
doctl databases create my-valkey --engine valkey --version 9 \
  --region nyc1 --size db-s-2vcpu-4gb --num-nodes 2

Interpretation: Aiven's replicas defaults to 0, and a shard without a replica has no automatic failover. List DigitalOcean size slugs with doctl databases options slugs --engine valkey; the smallest 1 GiB plan cannot have a standby node.

Akamai (Linode) also has a Valkey Managed Database API, labelled "Limited availability". Its options mirror Aiven's (cluster_size 1 to 3, valkey_persistence rdb or off, 12-hour backups). Check the Akamai API reference for the versions on offer before you plan around it.

How much memory can you actually use?

The node size on the pricing page is not your dataset limit. Every provider keeps part of the node for replication buffers, fork copy-on-write during snapshots, fragmentation, and its own agents. Size against maxmemory, not the node size.

ElastiCache's reserved memory page sets reserved-memory-percent to 25% (a 13.5 GB node gets about 10.1 GB of maxmemory), says not to lower it, and recommends 30% on small nodes and 50% on micro nodes. When FreeableMemory is too low for a forked save, ElastiCache switches to a forkless save, which uses less memory but can add client latency. Memorystore's node specification page lists 10.4 GB of writable keyspace on a 13 GB highmem-medium node and advises against raising maxmemory above that. MemoryDB and OCI Cache publish no percentage, so measure it.

ElastiCache lists config among its restricted commands, Memorystore returns NOPERM for CONFIG GET, and DigitalOcean disables config entirely. INFO is not on any of these restricted lists, so build capacity alerts on its fields:

# Percent of maxmemory in use; alert well before 100
valkey-cli -h "$VALKEY_HOST" --tls INFO memory | tr -d '\r' | awk -F: '
  /^used_memory:/ {u=$2} /^maxmemory:/ {m=$2}
  END { if (m > 0) printf "%.1f%% of maxmemory\n", 100*u/m; else print "maxmemory not set" }'

Interpretation: maxmemory:0 means no limit is set, which you should not see on a managed service. Watch the eviction policy too: Aiven defaults to noeviction, so a full cache rejects writes instead of evicting keys. Pick allkeys-lru or volatile-lru if the data is a cache.

Which managed Valkey services can be a primary data store?

Most managed Valkey is a cache whose data can be rebuilt elsewhere. Snapshots and AOF reduce what a restart loses, but a failover can still promote a replica that is behind the primary. Only two services log every write across zones.

MemoryDB stores data "durably across multiple Availability Zones (AZs) using a Multi-AZ transactional log" (What is MemoryDB), with single-digit millisecond writes.

ElastiCache 9.0 and later can do the same per cluster. The durability page describes synchronous writes, logged in at least two AZs before the reply, and asynchronous writes, which reply first and can lose up to 10 seconds of data. The limitations matter: it is not available on Serverless, Global Datastore, data tiering, or cluster-mode-disabled clusters, and it supports up to 100 MBps of writes per primary.

aws elasticache create-replication-group \
  --replication-group-id orders-store \
  --replication-group-description "Durable Valkey store" \
  --engine valkey --engine-version 9.1 \
  --cache-node-type cache.r7g.large \
  --cluster-mode enabled --num-node-groups 2 --replicas-per-node-group 1 \
  --multi-az-enabled --automatic-failover-enabled \
  --transit-encryption-enabled \
  --durability sync

Interpretation: --durability accepts sync, async, disabled, or default. With default, ElastiCache picks the mode and currently resolves to disabled on 9.0, so set it explicitly. Durability turns on encryption at rest automatically. If the call rejects the default parameter group, pass a cluster-mode-enabled one with --cache-parameter-group-name.

aws elasticache describe-replication-groups --replication-group-id orders-store \
  --query 'ReplicationGroups[0].[ClusterMode,Durability,EffectiveDurability,TransitEncryptionEnabled]'

Interpretation: trust EffectiveDurability, not Durability. It shows the mode actually in force, and a restore from a snapshot keeps it.

What do backups and restores look like on each service?

Backups are where providers differ most, and the differences only show up during an incident. Rehearse a restore on each candidate before you choose.

Sources: ElastiCache automatic backups, the Memorystore backups overview, and Aiven for Valkey backups. On Aiven, Akamai, and DigitalOcean, persistence off also stops RDB dumps, so nothing is left to restore after a full outage. An Aiven cluster restore needs the same shard count as the backup.

# Is anything being written to disk at all?
valkey-cli -h "$VALKEY_HOST" --tls INFO persistence \
  | grep -E '^(aof_enabled|rdb_last_bgsave_status|rdb_last_save_time|rdb_changes_since_last_save)'

Interpretation: aof_enabled:0 with a rdb_last_save_time that never advances means the node keeps nothing on disk. Some providers take snapshots outside the engine (ElastiCache durability uses off-box snapshotting), so compare this with the provider's backup list before you draw a conclusion.

How do the pricing models differ?

We do not quote prices, because they change by Region and over time. As read on the providers' pricing pages on 10 November 2026: ElastiCache bills node-hours, or GB-hours of data plus ElastiCache Processing Units (ECPUs) on Serverless. Its pricing page says Valkey costs 20% less than Redis OSS on nodes and 33% less on Serverless, and synchronous durability adds 18% to the node-hour price. MemoryDB bills node-hours plus each GB of data written. Memorystore bills per node and Aiven per plan, with cluster plans billed per node; replicas and standby nodes add cost. Compare cost per usable GiB: a 70% cap and a 75% cap on the same node differ by about 7% in usable memory before any price difference.

How should you evaluate a provider before you commit?

Feature tables show what a provider documents; a test instance shows how it behaves. Run these steps on each shortlisted provider.

Version upgrades are one-way on several services: Memorystore and MemoryDB both say you cannot downgrade after an upgrade. Keep a tested backup from before every major version change. If you are moving an existing Redis OSS deployment on AWS, our guide to migrating Redis to Valkey on ElastiCache and MemoryDB covers the cross-engine upgrade itself.

When does self-managed Valkey with support make more sense?

Managed services remove patching, failover wiring, and node replacement, and for most caches that is the right trade. Running Valkey yourself, on VMs or Kubernetes, starts to pay off in a few specific cases:

• You need a version or feature the provider does not offer. MemoryDB is on 7.3 and OCI Cache on 8.1. Features such as hash field expiration (9.0) or database-level ACLs (9.1) arrive on your schedule, not the provider's.
• You need settings the provider blocks. Most managed services block CONFIG, so you cannot tune io-threads, AOF fsync, or replication buffers beyond what the parameter group exposes.
• You need a persistence or backup model the provider lacks. AOF with your own retention, or restorable backups on a provider that has none.
• You run in several clouds or on-premises and want one Valkey configuration and runbook everywhere.

# valkey.conf: settings most managed services do not let you change
appendonly yes
appendfsync everysec
io-threads 4

Interpretation: self-managed, these are yours to set and to test under load. The cost is that failover, upgrades, backups, and on-call become your work. The Kubernetes route is covered in our comparison of Valkey and Redis operators for Kubernetes, and tuning a node you control is in Valkey performance tuning.

Frequently asked questions

Key takeaways

Choose and run Valkey with JusDB

JusDB's Valkey support team can review your shortlist of managed services against your workload, run the evaluation checks above on a test instance, and plan a move between providers or to a self-managed deployment.

If you run Valkey yourself, the same team can support it in production: incident response, failover recovery, and persistence problems. Bring your current provider, versions, dataset size, and recovery requirements to the first call.

Related reading

• Redis 8 vs Valkey 8 in production
• Valkey performance tuning: memory, persistence, and cluster config
• Valkey and Redis operators for Kubernetes compared
• AWS documentation: Durability in ElastiCache