Top Managed Redis Services Compared

The short answer

A managed Redis solution is a commercial service that runs a Redis-API-compatible in-memory data store on your behalf, handling provisioning, replication, failover, patching, backups, and monitoring. As of 2026 there are three major engines behind these services (Redis, Valkey, and Dragonfly) plus several proprietary implementations, and they are no longer interchangeable on license, threading model, or scaling ceiling.

The practical decision comes down to five questions: which engine you want to be tied to, whose infrastructure it runs on, which clouds it runs in, how it scales when you outgrow one node, and how many nodes you end up paying for. This guide answers those for every provider we could verify against vendor documentation.

For light workloads, most of these services are interchangeable and you should pick on convenience. For heavy workloads they are not, and the gap is wide. Priced against a 500 GB, 1M ops/sec workload, Dragonfly Cloud runs it on one node for roughly $4,000/month, against 7 nodes and $7,130 on ElastiCache and 39 nodes and $5,475 on Memorystore. Lower cost, higher per-node throughput, and far less operational surface, from the same Redis API your clients already speak. The workings are further down this page.

A note on the word "Redis"

Throughout this guide, "Redis" refers to the API, not to a single product or vendor.

This matters because the ecosystem forked. Since 2024, services marketed as "managed Redis" may be running Redis (the software from Redis Ltd.), Valkey (the Linux Foundation fork), Dragonfly, or an in-house engine that speaks the RESP protocol without sharing any Redis lineage. All of them accept GET, SET, HGETALL, and the rest of the command surface your existing clients already send. None of them are the same product.

So when we say "managed Redis solutions," we mean every managed service that implements the Redis API:

Redis is a registered trademark of Redis Ltd. We use it here to describe API compatibility, which is how the market itself uses the term.

The state of managed Redis in 2026

Four shifts define the current landscape. If you last evaluated this market before 2024, all four are new.

1. The license fork is permanent, and it reshaped the vendor map

In March 2024, Redis Ltd. moved the core project off BSD-3 to a dual RSALv2 / SSPLv1 license. Eight days later the Linux Foundation announced Valkey, a fork of Redis 7.2.4 that stays under BSD-3. In May 2025, Redis added AGPLv3 as a third option starting with Redis 8, restoring an OSI-approved license but on copyleft terms rather than permissive ones.

Two years on, that fork has not healed, it has hardened. Valkey shipped 9.0 in October 2025 and 9.1 in May 2026, with releases from a contributor base approaching 400 engineers and corporate participants including AWS, Google Cloud, Oracle, Alibaba Cloud, ByteDance, Tencent Cloud, DigitalOcean, Heroku, Ericsson, NetApp Instaclustr, Percona, and UpCloud. Redis has continued its own line through the 8.x series with vector sets, the Redis Query Engine, and the former Redis Stack modules folded into the core distribution.

The consequence for buyers: the engine under your managed service probably changed without you choosing it. AWS, Google Cloud, and DigitalOcean now default new deployments to Valkey. DigitalOcean retired its Redis-based Managed Caching product outright in favor of Managed Caching for Valkey. Heroku's Key-Value Store runs on Valkey. Meanwhile Azure Managed Redis is built on Redis Software from Redis Ltd., moving Azure in the opposite direction.

2. Valkey is priced as the default, not the alternative

AWS prices ElastiCache for Valkey 20% below Redis OSS on node-based clusters and roughly 33% below on serverless, with a serverless storage minimum of 100 MB (about $6/month) versus 1 GB for Redis OSS. Existing Redis OSS reserved nodes carry over to Valkey in the same instance family and region, which means a reservation covering five nodes covers six after the switch.

That is not a promotional rate. It is the standing price structure, and it means staying on Redis OSS inside a hyperscaler is now a line item you have to justify.

3. Azure is forcing a migration

Azure Cache for Redis is being retired. The Enterprise and Enterprise Flash tiers go away on March 31, 2027; Basic, Standard, and Premium follow on September 30, 2028. Instances not migrated are disabled after those dates. The destination is Azure Managed Redis, which is not a drop-in swap: it changes the port (6380 to 10000), the underlying architecture, and the connection configuration.

The same shift closed a door elsewhere. Redis Cloud Pro is no longer sold directly on Azure at all; on Azure, Redis Ltd. routes enterprise workloads through Azure Managed Redis, and Redis Cloud Essentials remains available in just two Azure regions. If you run Redis on Azure, this is a scheduled project, not a someday item.

4. Workloads outgrew the single-threaded assumption

Redis and Valkey both execute commands on a single thread. Valkey 8 and 9 added asynchronous I/O threading, memory prefetching, and zero-copy responses, which raised per-node throughput meaningfully, but command execution itself remains single-threaded by design. That design was correct in 2010, when a large server had four cores.

Modern cloud instances have 64 to 192 vCPUs. The standard answer to using them is horizontal scaling: shard the keyspace and run more processes. That works, and it is why Redis Cluster and Valkey Cluster exist. It also means shard-count management, slot rebalancing, cluster-aware clients, cross-shard transaction limits, and a node count that grows with both memory and throughput independently.

The workloads pushing hardest on this are the newer ones: ML feature stores, agent and session memory for LLM applications, real-time bidding, and vector search, all of which combine large keyspaces with unpredictable read amplification. This is the axis on which the engines now differ most, and it is why the scaling model column below is the one worth reading twice.

The four kinds of provider

Sorting the market this way makes the comparison tables easier to read.

Hyperscaler-native services. Amazon ElastiCache, Google Memorystore, Azure Managed Redis, Oracle OCI Cache. Deepest integration with your existing VPC, IAM, monitoring, and committed spend. Least flexibility on engine and version, and locked to one cloud.

Engine vendors running their own cloud. Redis Cloud, Dragonfly Cloud, Upstash. The team that builds the engine also operates it, which usually means faster access to new engine capabilities and support that can answer questions about internals.

Multi-cloud data platforms. Aiven is the main example. One control plane across clouds, alongside Kafka, Postgres, and OpenSearch, and typically the category most willing to run inside your own cloud account.

Platform add-ons. Heroku Key-Value Store, DigitalOcean Managed Caching. Optimized for "I need a cache next to my app in five minutes." Fewer knobs, lower ceilings, simplest pricing.

Comparison: engine, hosting, clouds, and pricing

All eleven solutions compared here speak the Redis API. Every one accepts commands from standard Redis clients over the RESP protocol, which means the choice between them is an operational and commercial decision, not a compatibility one. What differs is the engine underneath, who runs it, where it runs, how it scales, and how you are billed.

Hosting model definitions used below:

• Managed cloud: runs in the vendor's cloud account, you get an endpoint
• Bring-your-own-cloud (BYOC): runs in your cloud account, vendor operates it
• Managed on-prem: vendor-operated in your own data center, air-gapped environment, or Kubernetes cluster

Comparison: scaling and performance

Same eleven solutions, same order. This is the table that decides whether a service can carry a heavy workload, and how much hardware it needs to do it.

How to read the throughput column. These are peak benchmark figures on tuned hardware, not numbers your application will hit. They are useful as a ratio, not as a target. Two things make them comparable: all are memtier or valkey-benchmark style synthetic loads, and where pipelining is used we have said so, because pipeline depth inflates throughput several times over. Dragonfly's 6.43M is non-pipelined; Valkey's 2.1M figure uses a pipeline depth of 10. Compared like for like, one Dragonfly process serves roughly five times the throughput of one Valkey process, and roughly twenty-five times a single Redis process. Where a vendor does not publish per-node numbers, we have given the engine's documented ceiling and labelled it as such, since a managed service cannot exceed the engine it runs.

Why the maximum scale column matters less than it looks. Every horizontally scaled option here reaches enormous aggregate numbers eventually, because you can always add shards. Valkey has documented 1 billion ops/sec, on a 2,000-node cluster. The question worth asking is not whether a service reaches your number but how many nodes it takes to get there, which is what the next section prices out.

Comparison: what a 500 GB, 1M ops/sec workload costs

Entry prices tell you almost nothing, because every provider is cheap at 1 GB. The number that separates them is what a real production workload costs. So here is one workload, priced across every provider in this guide.

The workload. 500 GB of cached data, 1,000,000 operations per second sustained, mixed reads and writes, values averaging 500 bytes. US region, on-demand list price, 730 hours per month. No reserved nodes, committed use discounts, savings plans, or negotiated pricing. Excludes cross-AZ data transfer, backups, and snapshots.

The node-count rule. Nodes are added only where the workload requires them, either because the data will not fit or because a single process cannot serve the throughput. No replicas are added for high availability. This keeps the comparison on architecture rather than on each vendor's replication policy. Adding HA on top scales each provider differently, and every provider here bills a replica at the full node rate.

The throughput assumption. For Redis and Valkey we assume 150,000 ops/sec sustained per shard. Published estimates for a single shard range from 100,000 to 200,000 before CPU saturates, and Redis's own conservative guidance is to shard past 25,000 ops/sec. We used the generous end of that range. Use a lower figure and every shard count below goes up.

The headline is the node count, not the dollars

1 node versus 7 versus 39. Every number in that column follows from one fact: how much memory and throughput a single process can actually use. Dragonfly holds 500 GB in one shard and serves the full 1M ops/sec from it, because a Dragonfly shard uses every core on the instance. ElastiCache and OCI Cache need seven primaries each because throughput saturates long before a 100 GB node fills. Memorystore needs thirty-nine because its commonly used highmem-medium node type holds 13 GB.

Cost follows, but the operational load follows harder. Thirty-nine nodes means thirty-nine things to patch, monitor, and fail over, slot rebalancing every time the keyspace grows, cluster-aware clients, and cross-slot restrictions on transactions and Lua scripts. One node means one endpoint and one thing to watch.

The dollar gaps are narrower than the node gaps: Dragonfly comes in roughly 24% below OCI Cache, 27% below Memorystore, and 44% below ElastiCache. Node count is where the difference is structural.

How each figure was calculated

Dragonfly Cloud. 500 GB fits in a single shard, under the 600 GB per-shard ceiling, and a single Dragonfly shard sustains millions of ops/sec, so neither memory nor throughput forces a second node. Pricing is $8/GB/month of provisioned memory: 500 GB × $8 = $4,000. Note that we have deliberately not applied Dragonfly's memory efficiency advantage here. On a published customer migration, 310 GB of Redis data provisioned at 190 GB on Dragonfly, roughly 40% less. Applying that ratio would put this workload nearer $2,600, but comparing our compressed footprint against everyone else's uncompressed one would not be a fair test.

Oracle OCI Cache. Memory alone would fit in fewer nodes, but at 150,000 ops/sec per shard the throughput requirement sets 7 nodes at roughly 71 GB each. OCI bills provisioned memory at $0.0194/GB/hour for the first 10 GB per node and $0.0136/GB/hour above that, giving about $1.03/hour per node. 7 × $1.03 × 730 = $5,260.

Google Memorystore for Valkey. The highmem-medium node type holds 13 GB, so 500 GB needs 39 shards, which is well within the 250-shard limit and leaves each shard serving only about 26,000 ops/sec. Google publishes $0.1923 per node per hour for highmem-medium in us-central1. 39 × $0.1923 × 730 = $5,475. The highmem-xlarge type (58 GB) cuts this to 9 shards at a higher per-node rate, which is the configuration most teams would actually choose.

Amazon ElastiCache for Valkey. At 150,000 ops/sec per shard, 1M ops/sec needs 7 shards. AWS recommends reserving 25% of node memory, so a cache.r7g.4xlarge (105.81 GiB) holds about 79 GiB of data, and 7 shards give 556 GiB usable. cache.r7g.4xlarge lists at $1.745/hour on Redis OSS; Valkey is priced 20% lower, so $1.396/hour. 7 × $1.396 × 730 = $7,130.

Redis Cloud Pro. Redis Cloud Pro is quote-based above a $200/month minimum, so we will not publish a total we cannot source. What we can source is Redis's own sizing guidance: shard past 25 GB of data or 25,000 ops/sec per shard. Applied to this workload, that implies 20 shards on memory and 40 on throughput. For a public reference point at smaller scale, one migration published on our pricing page shows a 310 GB, 100,000 ops/sec workload running on 13 Redis Cloud nodes at $5,722/month.

Upstash. 1,000,000 ops/sec is 2.63 trillion commands per month. At the published pay-as-you-go rate of $0.20 per 100,000 commands, that is roughly $5.26 million per month. Upstash's fixed plans are the realistic path for sustained throughput, but the published tiers do not reach this scale. This is not a knock on Upstash: per-request pricing is excellent for spiky and low-volume traffic, and this workload is the exact opposite of what it is designed for.

Azure Managed Redis. In-memory SKUs above 350 GB (M500 and higher) are in preview as of July 2026, so a 500 GB in-memory instance is not a generally available configuration. Flash Optimized SKUs reach further but move 80% of values to NVMe.

Aiven, DigitalOcean, and Heroku. All three scale vertically with replicas for availability, not by sharding the keyspace across primaries. Neither 500 GB nor 1M ops/sec is a supported configuration.

The conclusion, stated plainly. For heavy workloads, Dragonfly Cloud is the cheapest option in this guide, on the fewest nodes, with the most headroom left over. It is the only service here that serves 500 GB and 1M ops/sec without sharding at all, and it still has 100 GB and several million ops/sec of room inside that single shard before Dragonfly Swarm is needed. Every other option is already managing a cluster at this point on the curve.

These are modeled list prices, not quotes, and they exclude replicas. Node counts derive from published specifications and vendor sizing guidance; costs derive from published on-demand rates. Committed-spend discounts of 20% to 55% are available on most providers here and would reduce every figure. Verify against vendor calculators before budgeting.

Comparison: engine characteristics

This table is about the engines rather than the services, because engine choice determines your ceiling regardless of who operates it. All four implement the Redis API. They differ in license, threading model, and how much of the command surface they cover.

What the threading column actually costs you

Single-threaded command execution means one process cannot use more than roughly one core for command work, no matter how large the instance. The standard response is to run more processes and shard the keyspace, which is exactly what Redis Cluster and Valkey Cluster do well.

The cost shows up as node count. Two examples published on our own pricing page, both real migrations:

The pattern in both: the incumbent's node count was set by the ceiling of a single process, not by the size of the data. Once one shard can use every core on the instance, the shard count drops, and so does the metadata overhead, the rebalancing risk, and the bill.

Dragonfly Swarm is the horizontal path for workloads beyond that. It scales each shard vertically first, then adds shards, using a control plane for cluster metadata instead of a gossip protocol and parallel TCP connections for slot migration. See Announcing Dragonfly Swarm for the design.

How to choose

Seven questions, in the order that eliminates the most options fastest.

1. Do you have a license constraint? If AGPLv3 is a blocker for your legal team, Redis 8 self-hosted is out, though Redis Cloud and Azure Managed Redis are unaffected because you are buying a service. If you want a permissive license and open governance, Valkey is the only major engine that gives you both. If you want source-available with no copyleft obligation for normal use, Dragonfly's BSL 1.1 permits everything except reselling it as a hosted service.

2. Where does the data have to live? If it cannot leave your cloud account, you need BYOC: Dragonfly Cloud on the Business tier, or Aiven. If it cannot leave your data center, Dragonfly Cloud Enterprise supports air-gapped deployment, and Redis licenses Redis Software for self-managed installation.

3. Which clouds are you actually on? The hyperscaler services are single-cloud by definition. If you are multi-cloud or expect to be, the shortlist is Dragonfly Cloud, Redis Cloud, Aiven, and Upstash. Two traps worth knowing: Redis Cloud Pro is not sold on Azure (that path goes through Azure Managed Redis), and Upstash runs on AWS, GCP, and Fly.io rather than on Azure at all.

4. Is your traffic steady or spiky? Steady and high favors provisioned pricing. Genuinely spiky, or near-zero much of the time, favors per-request pricing (Upstash) or serverless (ElastiCache Serverless). Note that "serverless" rarely means zero: ElastiCache Serverless has a monthly floor even when idle.

5. Does throughput or capacity set your node count? Check your current cluster. If you have shards well below their memory limit that exist only to add CPU, you are paying for the single-threaded ceiling, and a multi-threaded engine changes the math. If your shards are full, you have a capacity problem and any horizontally scalable option works.

6. Which Redis features do you actually use? If you depend on Redis 8 modules (time series, Bloom filters, the full Query Engine), that is a Redis Ltd. product feature. Valkey deliberately does not ship them, and Valkey's own module ecosystem (Valkey Search, Valkey JSON) is a separate implementation. Dragonfly implements JSON and vector search natively; check the command reference for the current surface. Upstash restricts the cluster and admin command families entirely.

7. Where does your committed spend sit? If you have an AWS, GCP, or Azure commitment, hyperscaler-native services and marketplace-available platforms let you draw it down. This frequently decides the outcome regardless of the technical comparison, so check marketplace availability before you shortlist.

Where Dragonfly fits

If your workload is heavy, Dragonfly Cloud is the strongest option in this guide, and the margin is not close. It costs less, serves more throughput per node, and scales further before the architecture fights you. That is a strong claim, so here is the evidence behind each part of it, all of it sourced above.

Lower cost. On a 500 GB, 1M ops/sec workload at list price, Dragonfly Cloud comes in roughly 24% below Oracle OCI Cache, 27% below Google Memorystore, and 44% below Amazon ElastiCache. That is before applying Dragonfly's memory efficiency advantage, which on a published customer migration provisioned 310 GB of Redis data in 190 GB, roughly 40% less.

Higher performance. A single Dragonfly instance has been benchmarked at 6.43M ops/sec on a c7gn.16xlarge, and 10M SET / 15M GET with pipelining. The best published single-node Valkey figure is 2.1M ops/sec, and that one uses a pipeline depth of 10. A single Redis process is roughly 25x behind on identical hardware. Dragonfly also holds P99 latency below 1ms at peak throughput, and takes no memory spike during snapshotting, where Redis's copy-on-write fork can nearly triple memory use.

Much better scalability. This is the part that compounds. Dragonfly scales vertically to 600 GB and millions of ops/sec in a single shard before you shard at all, then horizontally to 15 TB and tens of millions of ops/sec with Dragonfly Swarm. Every other engine here must scale horizontally almost immediately, because a single process cannot use more than about one core for command execution. That is why the same workload takes 1 node on Dragonfly, 7 on ElastiCache, and 39 on Memorystore. Node count is not just a cost line: it is patching, monitoring, failover, slot rebalancing, cluster-aware clients, and cross-slot limits on transactions and Lua scripts.

The reason all three hold at once is architectural. Dragonfly is a from-scratch implementation of the Redis and Memcached APIs, built for hardware that did not exist when Redis was designed. The shared-nothing, multi-threaded design partitions the keyspace across threads so one instance uses every core and network queue on the machine, rather than running one process per core and paying the coordination cost between them.

For managed deployments, Dragonfly Cloud runs on AWS, GCP, and Azure in three shapes:

• Flex, self-serve, from $36/month, one-click provisioning with both vertical and horizontal scaling
• Business, from $2,000/month, adds bring-your-own-cloud, auto-scaling, SSO and MFA, and a custom SLA
• Enterprise, quote-based, adds air-gapped deployment, custom instance types, and white-glove migration

You pay for provisioned memory, not per node and not per command, which is why the node-count reduction shows up directly on the invoice.

When Dragonfly is not the right choice

We would rather you find that out here than three weeks into a POC.

• You depend on Redis Ltd. modules. Time series and Bloom filters have no Dragonfly equivalent today. Redis Cloud or Azure Managed Redis is the shorter path.
• You need a permissive open-source license. BSL 1.1 is source-available, not OSI-approved. If your requirement is BSD or Apache, Valkey is the honest answer.
• You need durable-primary-database semantics with multi-region write durability. A purpose-built durable in-memory database such as Amazon MemoryDB is designed for that shape.
• Your workload is genuinely tiny and idle. A 256 MB cache serving a few thousand commands a day is cheaper on a per-request tier than on any provisioned service, including ours.
• You need one dashboard for Kafka, Postgres, OpenSearch, and your cache. A multi-service platform like Aiven consolidates that in a way a single-engine vendor cannot.

Migration notes

Because every option here implements the Redis API, migrations are mostly endpoint changes rather than code changes. The parts that actually take time:

• Cluster-aware clients. Moving from a single-node service to a sharded one, or the reverse, changes client configuration and can surface cross-slot command errors. Dragonfly supports an emulated cluster mode specifically to ease migrations off Redis Cluster; see cluster mode.
• Persistence and eviction semantics. RDB, AOF, SSD tiering, and durable-log designs have different recovery behavior. Test the failure mode you actually care about.
• In-place engine upgrades. AWS supports zero-downtime in-place upgrades from ElastiCache for Redis OSS to Valkey. Google publishes a migration path into Memorystore for Valkey. These are the cheapest moves available if Valkey is your destination.
• Live replication. Dragonfly can replicate from a Redis or Valkey primary, which allows a cutover with a short switchover window instead of a dump-and-restore. See the migration guide.

Frequently asked questions

Is Redis still open source?

Partly. Redis 7.2.x and earlier remain BSD-3. Versions 7.4.x through 7.8.x are RSALv2 or SSPLv1, neither OSI-approved. Redis 8.0 and later are tri-licensed under RSALv2, SSPLv1, or AGPLv3, so you can use Redis 8 under an OSI-approved license, but AGPLv3 is copyleft and many organizations decline it for that reason.

What is the difference between Redis, Valkey, and Dragonfly?

Redis is the original, now under a tri-license from Redis Ltd., with the largest feature surface. Valkey is a BSD-licensed fork of Redis 7.2.4 governed by the Linux Foundation, with roughly the same architecture and a large corporate contributor base. Dragonfly is a separate implementation of the same API, multi-threaded and shared-nothing rather than single-threaded, under BSL 1.1. All three accept the same commands from the same clients.

Which managed Redis service is cheapest?

It depends entirely on traffic shape. For low or spiky traffic, per-request pricing (Upstash) wins because idle costs approach zero. For steady, high-throughput workloads, provisioned pricing wins, and within that, the cheapest option is usually the one that needs the fewest nodes to hit your throughput target. On AWS specifically, choosing Valkey over Redis OSS is a 20% to 33% reduction for the same workload.

Which clouds can I run managed Redis on?

Every major cloud has a native option: ElastiCache on AWS, Memorystore on Google Cloud, Azure Managed Redis on Azure, OCI Cache on Oracle Cloud. For the same service across multiple clouds, the options are Dragonfly Cloud (AWS, GCP, Azure), Redis Cloud (AWS and Google Cloud, with Azure limited to Essentials in two regions), Aiven (AWS, GCP, Azure, DigitalOcean, UpCloud), and Upstash (AWS, GCP, Fly.io).

How do pricing models differ between providers?

Four models are in use. Per node-hour, where you rent a fixed-size server whether it is busy or idle (ElastiCache node-based, Azure, DigitalOcean, Heroku). Per GB-hour of provisioned capacity, where you pay for reserved memory (Google Memorystore, Oracle OCI Cache, Dragonfly Cloud). Per request, where you pay per command executed (Upstash pay-as-you-go). And all-inclusive plan-hour pricing that bundles compute, storage, and support (Aiven). Node-hour pricing punishes idle capacity hardest; per-request pricing punishes sustained high throughput hardest.

Do I need to change my code to switch providers?

Usually not. Every service in this guide implements the Redis API, so your existing client libraries, CLI tools, and GUI managers work unchanged. What does change: connection strings, TLS settings, whether your client needs to be cluster-aware, and occasionally a command that a given provider restricts.

Can I run a managed Redis service inside my own cloud account?

Yes, but the list is short. Bring-your-own-cloud is available from Dragonfly Cloud on the Business and Enterprise tiers, and from Aiven on AWS and Google Cloud. The hyperscaler-native services do not offer it, because their own account is your account.

What happens to Azure Cache for Redis?

It is being retired. Enterprise and Enterprise Flash on March 31, 2027; Basic, Standard, and Premium on September 30, 2028. Instances not migrated to Azure Managed Redis are disabled after those dates. Microsoft has published migration tooling that preserves the hostname and access key, with a brief DNS-level connection blip.

Which managed services scale vertically rather than horizontally?

Vertically only: Redis Cloud Essentials and Flex, Aiven, DigitalOcean, Heroku Key-Value Store, and the legacy Memorystore for Redis tier. Both: ElastiCache, Memorystore for Valkey and Redis Cluster, Azure Managed Redis, Redis Cloud Pro, Oracle OCI Cache, and Dragonfly Cloud. Upstash abstracts the question away entirely and scales automatically. The distinction matters because vertical-only services hit a hard ceiling, while horizontal-only services make you manage shards from day one.

How much can a single node handle?

On memory, Dragonfly Cloud's single-shard ceiling is 600 GB, extending to 15 TB across shards with Dragonfly Swarm; self-hosted Dragonfly handles up to 1 TB on one instance. On throughput, a single Dragonfly instance has been benchmarked at 6.43M ops/sec, against a best published single-node Valkey figure of 2.1M and roughly 25x less for a single Redis process. The two limits are related: Redis and Valkey shards are kept far smaller than the hardware allows, because a single process cannot use additional cores for command execution, so throughput rather than available memory sets the practical size of a node.

Methodology

Every claim in the tables above was checked against vendor documentation, pricing pages, or primary announcements in July 2026. Pricing is list price for a single node in a US region, excluding data transfer and any commitment discounts. Where a vendor publishes ranges rather than figures, the table says so rather than guessing.

This market moves. Engines default-switch, tiers get retired, and prices change without announcement. Spot something wrong or out of date? Tell us in Discord and we will fix it and note the correction date.

Primary sources

• Redis licenses and Redis 8 AGPLv3 announcement
• Redis Cloud supported clouds and regions
• Valkey project and managed providers and Valkey 9.1 release
• Amazon ElastiCache pricing and ElastiCache for Valkey announcement
• Google Cloud Memorystore
• Azure Cache for Redis retirement FAQ
• Oracle OCI Cache pricing
• DigitalOcean Managed Caching for Valkey
• Dragonfly Cloud data stores and pricing

Related reading

Engines and architecture

• Valkey vs Redis: ultimate comparison guide
• Redis 8.0 vs Valkey 8.1: a technical comparison
• Introduction to Valkey, the OSS Redis fork
• Redis and Dragonfly architecture comparison
• The unbearable lightness of horizontal scaling

Provider deep dives

• ElastiCache for Valkey: what's in the box
• Google Memorystore: architecture, pros and cons, best practices
• Upstash: solution overview, pros and cons, alternatives
• Best Redis alternatives: open source and fully managed

Migration and operations

• Redis to Valkey migration guide
• Using Redis Cluster: key features and best practices
• Migrating to Dragonfly

Compare Dragonfly directly

• Redis alternative
• ElastiCache alternative
• Memorystore alternative
• Upstash alternative
• Memcached alternative

Redis is a registered trademark of Redis Ltd. Valkey and the Valkey logo are trademarks of LF Projects, LLC. All other trademarks are the property of their respective owners. Use of these marks here describes API compatibility and does not imply endorsement or affiliation.