Redis vs Valkey: Enterprise Architecture Guide

Valkey and Redis diverge primarily on licensing, governance, and trajectory. Valkey, a Linux Foundation fork backed by AWS, Google Cloud, and others, retains the open BSD licence and receives contributions from major cloud engineering teams. Redis remains source available under RSALv2/SSPLv1. For enterprises prioritising open source compliance, long term managed service support, or cloud native integration, Valkey is increasingly the stronger architectural choice.

Redis vs Valkey: Enterprise Architecture GuideAndrew Baker's Technology Blog Posts, 04/Jan/2026
https://andrewbaker.ninja/2026/01/04/redis-vs-valkey-enterprise-architecture-guide/

Updated October 2026. This guide was first published in January 2026 and has been revised for Valkey 9.0 and 9.1, Redis 8.4 through 8.8, the Azure Cache for Redis retirement, corrected AWS pricing, the migration constraints that now matter more than they did at the fork, and a read latency regression on hash heavy workloads that we hit in production and that is being worked on upstream (section 2.3 and section 10.4).

The in memory data store landscape fractured in March 2024 when Redis Inc abandoned its BSD 3 clause licence in favour of the dual RSALv2/SSPLv1 model. The community response was swift and surgical: Valkey emerged as a Linux Foundation backed fork, supported by AWS, Google Cloud, Oracle, Alibaba, Tencent, and Ericsson. Two and a half years later, both projects have diverged significantly, both are shipping feature releases at a pace neither managed before the split, and the choice between them involves far more than licensing philosophy.

1. The Fork That Changed Everything

When Redis Inc made its licensing move, the stated rationale was protecting against cloud providers offering Redis as a managed service without contribution. The irony was immediate. AWS and Google Cloud responded by backing Valkey with their best Redis engineers. Tencent’s Binbin Zhu alone had contributed nearly a quarter of all Redis open source commits. The technical leadership committee now has over 26 years of combined Redis experience and more than 1,000 commits to the codebase.

Redis Inc CEO Rowan Trollope dismissed the fork at the time, asserting that innovation would differentiate Redis. What he perhaps underestimated was that many of the innovators had just walked out the door.

Redis then spent the following year repairing the relationship. Salvatore Sanfilippo (antirez), Redis’s original creator, returned to the company in December 2024, and in May 2025 Redis added AGPLv3 as a licensing option for Redis 8. The messaging was careful: “Redis as open source again.” But the damage to community trust was done. As Kyle Davis, a Valkey maintainer, stated after the September 2024 Valkey 8.0 release: “From this point forward, Redis and Valkey are two different pieces of software.”

That prediction has aged well. Valkey shipped 9.0 in October 2025 and 9.1 in May 2026. Redis shipped 8.2, then 8.4 in late 2025, 8.6 in February 2026 and 8.8 in May 2026. The two projects now add commands the other does not have, write snapshot formats the other cannot read, and make competing performance claims that cannot be compared directly. They still share a wire protocol and most of a command set, which is why switching is easy in some situations and surprisingly expensive in others (see section 5).

2. Architecture: Same Foundation, Diverging Paths

Both Redis and Valkey maintain the single threaded command execution model that ensures atomicity without locks or context switches. This architectural principle remains sacred in both projects. What differs is how each one uses additional threads for I/O, memory management and, increasingly, for modules such as search.

2.1 Threading Models

Redis introduced multi threaded I/O in version 6.0, offloading socket reads and writes to worker threads while keeping data manipulation single threaded. Redis 8.0 enhanced this with a new I/O threading model, claiming a 112% throughput improvement when setting io-threads to 8 on multi core Intel CPUs. Redis 8.4 added lookahead prefetching, which parses several pipelined commands ahead of execution, and Redis reports more than 30% higher throughput than 8.2 for a typical caching mix of 90% GET and 10% SET. By 8.6, Redis was claiming more than five times the throughput of Redis 7.2 for the same kind of caching workload.

Valkey took a more aggressive approach earlier. The async I/O threading implementation in Valkey 8.0, contributed primarily by AWS engineers, allows the main thread and I/O threads to operate concurrently. The I/O threads handle reading, parsing, writing responses, polling for I/O events, and even memory deallocation, while the main thread orchestrates jobs and executes commands, and the number of active I/O threads adjusts dynamically based on load. On AWS Graviton r7g instances, Valkey 8.0 achieved 1.2 million queries per second compared to 380K in Valkey 7.2. Valkey 9.0 added memory prefetching for pipelined commands, zero copy responses for large replies, Multipath TCP and AVX-512 optimisations, with the project claiming up to 40% more throughput than 8.1 for pipelined workloads.

Valkey 9.1 then replaced the I/O threading communication model altogether. The old design had the main thread repeatedly walking a list of pending clients to find completed work and assigning jobs to specific threads up front; the new one uses a shared lock free queue that idle threads pull from, a response queue the main thread checks instead of polling, and thread scaling driven by queue depth and main thread CPU. The pull request that introduced it reported 8% to 17% more throughput for GET and SET at 512 byte values, and the release is reported to reach 2.1 million requests per second with 512 byte payloads.

The most useful head to head data point remains the independent Momento benchmark on c8g.2xlarge instances (8 vCPU), where Valkey 8.1.1 reached 999.8K requests per second on SET operations with 0.8ms p99 latency, against 729.4K requests per second and 0.99ms p99 for Redis 8.0. That is 37% higher write throughput for Valkey in that configuration. The caveat is that both engines have shipped at least two performance focused releases since, and every newer figure quoted above is a vendor number measured against its own previous version, on its own hardware, with its own workload mix. None of them tells you how Valkey 9.1 compares with Redis 8.8. If throughput per node is a deciding factor for you, run your own benchmark with your own key sizes, command mix, pipelining depth and TLS settings, because the gap is narrower and more workload dependent than it was a year ago. Section 2.3 is a concrete example of why the command mix matters as much as the engine.

2.2 Memory Efficiency

Valkey 8.0 introduced a redesigned hash table implementation that reduces memory overhead per key, and the 8.1 release pushed further, saving roughly 20 bytes per key value pair for keys without TTL and up to 30 bytes for keys with TTL. For a dataset with 50 million keys, that translates to roughly 1GB of saved memory. Valkey 9.1 continued the work, with strings under 128 bytes using 20% less memory and sorted sets up to 10% less, according to AWS’s ElastiCache release notes.

Redis has been working the same seam. Redis 8.4 reduced JSON memory consumption for short strings and homogeneous numeric arrays, and 8.6 delivered what its release notes describe as substantial memory reductions for hashtable encoded hashes and skiplist encoded sorted sets. Google Cloud’s benchmarks showed Memorystore for Valkey 8.0 achieving twice the QPS at microsecond latency compared to Memorystore for Redis Cluster, but that comparison predates the recent Redis releases and was run on Google’s own managed services.

The honest summary is that both projects are now competing hard on memory per key, which is good news for everyone, and that the size of the difference for your workload depends on your data types and key sizes more than on the engine’s headline claim.

2.3 When Faster Writes Come With Slower Reads: A Hash Read Regression

The headline benchmarks in section 2.1 are dominated by GET and SET on small values. Real caches rarely look like that, and the clearest example of the gap between a headline number and a production workload is an open Valkey issue, #3451, together with what we saw on one of our own caches after an ElastiCache engine upgrade to Valkey.

What the issue reports. The reporter loads about 100,000 hashes, each with 99 small fields of roughly 100 bytes and one larger blob field averaging around 50KB, and then has 14 parallel readers repeatedly scan the whole keyspace with SCAN and HGETALL. On their machine, with io-threads 4 over a Unix socket, a full scan averaged about 73 seconds on Redis 7.2.4, 47 seconds on Redis 8.6.1 and 60 seconds on Valkey 9.0.2, with Redis using a little over half the server CPU time of Valkey over the same test. A later rerun on different hardware put Valkey 9.0.2 at 39 seconds, Valkey 9.1.1 at 35 seconds, Redis 8.6.1 at 28 seconds and Redis 8.8.0 at 21 seconds. Both projects beat the pre fork engine, Valkey 9.1 narrowed the gap slightly, and Redis has kept moving on this path. It is one reporter’s workload and client, so treat it as a demonstration that the shape exists, not as a general ranking.

The suspected cause. RESP requires the element count of an array or map before the elements themselves. Valkey’s HGETALL (and HKEYS and HVALS) did not emit the count up front; it reserved a placeholder with addReplyDeferredLen() and patched it once iteration finished. The side effect is the expensive part: once that placeholder sits on the client’s reply list, every subsequent byte of the reply skips the client’s 16KB static output buffer and is written into heap allocated reply blocks instead, and each field and value goes through the buffer or list routing logic three times (length header, data, trailing CRLF). Redis computes the hash length first and writes a real header, so the static buffer stays in use, and it also prefetches hash entries in batches. A second, smaller cost was found separately: Valkey’s reply copy avoidance check, isCopyAvoidPreferred(), was being evaluated twice for every reply fragment once the reply list was in use.

What is being done upstream. Two pull requests target this directly, and neither had been merged when this guide was updated:

Hashes that do carry per field TTLs keep the old deferred path in #4417, because their length can change during iteration. The reporter has said that #4417 beats current Redis on their workload, which is encouraging, but it is still a single workload on a single machine.

What we saw. After one of our ElastiCache Serverless caches moved to Valkey, the server side CloudWatch latency metrics (hourly averages, in microseconds) moved in opposite directions:

{
  "type": "bar",
  "data": {
    "labels": ["Write latency (µs)", "Read latency (µs)"],
    "datasets": [
      { "label": "Before upgrade (midpoint of hourly range)", "data": [768, 210], "backgroundColor": "#5b8def" },
      { "label": "After upgrade (latest hourly average)", "data": [259, 812], "backgroundColor": "#f5a524" }
    ]
  },
  "options": {
    "responsive": true,
    "plugins": {
      "title": { "display": true, "text": "Server side latency before and after the Valkey upgrade" },
      "legend": { "labels": { "color": "#e6e6e6" } }
    },
    "scales": {
      "x": { "ticks": { "color": "#e6e6e6" }, "grid": { "color": "#444444" } },
      "y": { "beginAtZero": true, "title": { "display": true, "text": "microseconds", "color": "#e6e6e6" }, "ticks": { "color": "#e6e6e6" }, "grid": { "color": "#444444" } }
    }
  }
}

Writes fell by roughly 60% to 65% and reads rose by roughly three and a half to four times. The hour containing the upgrade showed a blend of both states (reads at 738µs and writes at 428µs), which is what you would expect from an hourly average spanning the cutover. Two common explanations can be ruled out from the same 48 hour window: ThrottledCmds stayed at zero throughout, so this is not ECPU throttling, and CacheHitRate held between 94% and 99%, so it is not a wave of misses or evictions forcing work back to the source of truth. AWS defines both latency metrics as server side response time covering command preprocessing, execution and postprocessing, so client network effects are not part of these numbers.

I want to be careful about what this does and does not show. The shape matches issue #3451: writes benefit from the threading and memory work, while large multi field reads pay the deferred reply cost on every call. But a fourfold increase is much larger than the 20% to 30% gap in the issue, the numbers are hourly averages rather than percentiles, and I have not yet confirmed that hash reads dominate this cache’s read mix. The defensible claim is that the regression is consistent with the known hash read path and worth testing for before you upgrade, not that it is proven to be the cause here. Section 10.4 covers how to check and what to change.

3. Feature Comparison

3.1 Core Data Types

Both support the standard Redis data types: strings, hashes, lists, sets, sorted sets, streams, HyperLogLog, bitmaps, and geospatial indexes. Both support Lua scripting and Pub/Sub messaging, although Valkey 9.1 moved its Lua engine into a separate module, which gives operators the option of running without scripting at all.

The shared command set is no longer growing in lockstep. Valkey 9.0 added polygon based geospatial queries through a BYPOLYGON option and the DELIFEQ command; Valkey 9.1 added HGETDEL, MSETEX and CLUSTERSCAN. Redis 8.4 added DELEX, DIGEST, compare and set options on SET, and its own MSETEX; Redis 8.6 added HOTKEYS and idempotent XADD; Redis 8.8 added XNACK. Some of these overlap in purpose but differ in syntax. Every one of them that your application adopts makes a later switch between engines harder.

3.2 JSON Support

Redis 8.0 bundles RedisJSON (previously a separate module) directly into core, available under the AGPLv3 licence. This provides native JSON document storage with partial updates and JSONPath queries.

Valkey responded with valkey-json, an official module compatible with Valkey 8.0 and above. As of Valkey 8.1, JSON support is production ready through the valkey bundle container that packages valkey-json, valkey-bloom, valkey-search and valkey-ldap together.

3.3 Vector Search

This is where the AI workload story becomes interesting.

Redis 8.0 introduced vector sets as a new native data type, designed by Sanfilippo himself, providing high dimensional similarity search directly in core and positioning Redis for semantic search, RAG pipelines and recommendation systems. Redis 8.6 reported up to 43% faster vector insertion and up to 58% faster querying for vector sets compared with 8.4.

Valkey’s approach is modular. valkey-search provides KNN and HNSW approximate nearest neighbour search; Google Cloud contributed its vector search module to the project, and it is now the official search module for Valkey. AWS added native vector search to ElastiCache with its Valkey 8.2 engine version, and Memorystore for Valkey supports vector search as well.

The architectural difference matters. Redis embeds vector capability in core; Valkey keeps it in a module. For organisations wanting a smaller attack surface, or that simply do not need vector search, Valkey’s approach offers more control over what is actually running.

3.4 Probabilistic Data Structures

Both now offer Bloom filters. Redis bundles RedisBloom in core; Valkey provides valkey-bloom as a module. AWS describes Bloom filters as using as much as 98% less memory than the Set data type for membership lookups, at the cost of an acceptable false positive rate.

3.5 Time Series

Redis 8.0 bundles RedisTimeSeries in core, and 8.6 added NaN support and new aggregators. Valkey still has no official time series module in its bundle or in the major managed services. There is a community project, ValkeyTimeSeries, which its author positions as a drop in replacement for RedisTimeSeries and which was presented at the Valkey Keyspace conference in 2025. It is worth watching, but if time series is central to your workload, Redis remains the lower risk option today.

3.6 Search and Query

This is the section that has changed most since the original version of this guide, which described Valkey’s full text search as roadmap rather than product. That is no longer true. Valkey Search 1.2, released alongside Valkey 9.1, supports full text, tag, numeric range and vector similarity queries, which can be used independently or combined with boolean operators in a single query, along with server side aggregations. AWS ships these capabilities in ElastiCache from its Valkey 9.0 engine version, including hybrid queries that combine text and vector results.

Redis has not stood still either. The Redis Query Engine (formerly RediSearch) has provided secondary indexing, full text search and aggregations for years, and Redis 8.4 added FT.HYBRID, which fuses full text and vector rankings in a single query using Reciprocal Rank Fusion or linear combination.

The gap is now one of maturity and depth rather than existence. The Redis Query Engine has many more years of production mileage and a richer query language; Valkey Search is newer, open source under BSD, and available inside AWS’s managed service at Valkey pricing. Teams should test their actual queries against both rather than assume either is a superset of the other.

3.7 Cluster Operations and Multi Tenancy

Both projects finally fixed the oldest operational complaint about Redis Cluster: key by key slot migration that caused redirects, broken pipelines and inconsistent multi key operations during resharding. Valkey 9.0 introduced atomic slot migration, where the whole slot is moved as a snapshot and the source node keeps serving it until the move completes. Redis 8.4 shipped its own atomic slot migration through the CLUSTER MIGRATION command a few weeks later.

Hash field expiration, the ability to set a TTL on individual fields within a hash, arrived in Redis 7.4 under the source available licence and in Valkey 9.0. Valkey 9.0 also added numbered databases in cluster mode, removing a long standing limitation that forced applications using SELECT to be rewritten before moving to a sharded cluster, and Valkey 9.1 layered database level ACLs on top, so a single cluster can isolate tenants by database. Both engines now support TLS certificate based client authentication.

4. Licensing: The Uncomfortable Conversation

4.1 Redis Licensing (as of Redis 8)

Redis now offers a tri licence model: RSALv2, SSPLv1 and AGPLv3. Users choose one.

AGPLv3 is OSI approved open source, but organisations often avoid it because of its copyleft requirements. If you modify Redis and offer it as a network service, you must release your modifications. Many enterprise legal teams treat AGPL as functionally similar to proprietary for internal use policies, and some prohibit it outright.

RSALv2 and SSPLv1 are source available but not open source by the OSI definition. Both restrict offering Redis as a managed service without a licensing arrangement.

The practical implication is that most enterprises consuming Redis 8 will either run it unmodified, which sidesteps most AGPL concerns, or license Redis commercially through Redis Software or Redis Cloud.

4.2 Valkey Licensing

Valkey remains BSD 3 clause. Full stop. You can fork it, modify it, commercialise it and offer it as a managed service without restriction. This is why AWS, Google Cloud, Oracle, Aiven, Percona and dozens of others are building their managed offerings and support businesses on Valkey.

For financial services institutions subject to regulatory scrutiny around software licensing, Valkey’s licence clarity is a non trivial advantage. It also matters for exit planning: a BSD licensed engine can be run by any provider, or by you, without renegotiating anything.

5. Commercial Considerations: AWS Reference Pricing

AWS has made its position clear through pricing, and the discounts for Valkey over Redis OSS are substantial and consistent across services. Before looking at the numbers, one framing point matters more than any of them.

5.1 What the AWS Comparison Actually Compares

ElastiCache supports Redis OSS versions up to 7.1 and nothing later. It will never offer Redis 7.4 or Redis 8, because those versions are not under a licence AWS can use. Every ElastiCache price comparison in this section is therefore Valkey against a Redis OSS engine that stopped evolving in 2023, not against the current Redis product.

That makes the AWS decision unusually simple: if you are on ElastiCache for Redis OSS today, Valkey is cheaper, newer and the only path forward inside the service. It also means the real comparison for anyone who wants Redis 8 features on AWS is ElastiCache for Valkey against Redis Cloud, Redis Inc’s own managed service, which is priced through commercial quotes and cannot be reduced to a table here.

AWS is also adding pressure on teams that stay on older Redis OSS engines. Redis OSS 4 and 5 left standard support on 31 January 2026 and are now charged Extended Support premiums, which rise each year until end of life in January 2029. Redis OSS 6 follows the same schedule a year later, leaving standard support on 31 January 2027.

5.2 Annual Cost Comparison by Cluster Size

The following tables show annual on demand costs for typical ElastiCache node based deployments in us-east-1 using r7g Graviton3 instances, with high availability through one replica per shard unless stated. Reserved nodes reduce costs further but preserve the same 20% engine differential.

Small Cluster (Development or Small Production)

Configuration: 1 shard, 1 primary and 1 replica, 2 nodes. Node type: cache.r7g.large (13.07 GiB memory, 2 vCPU). Effective capacity: roughly 10GB after a 25% reservation for overhead.

Medium Cluster (Production Workload)

Configuration: 3 shards, 1 primary and 1 replica each, 6 nodes. Node type: cache.r7g.xlarge (26.32 GiB memory, 4 vCPU). Effective capacity: roughly 60GB after a 25% reservation.

Large Cluster (High Traffic Production)

Configuration: 6 shards, 1 primary and 1 replica each, 12 nodes. Node type: cache.r7g.2xlarge (52.82 GiB memory, 8 vCPU). Effective capacity: roughly 240GB after a 25% reservation.

XL Cluster (Enterprise Scale)

Configuration: 12 shards, 1 primary and 2 replicas each, 36 nodes. Node type: cache.r7g.4xlarge (105.81 GiB memory, 16 vCPU). Effective capacity: roughly 950GB after a 25% reservation.

For a sense of throughput at this size, AWS’s own figure for ElastiCache Redis OSS 7.1 is more than one million requests per second per node on r7g.4xlarge or larger, which puts a 12 shard cluster in the low tens of millions of requests per second for simple operations, with reads spread across replicas adding more. Treat that as an order of magnitude, not a capacity plan.

Serverless Comparison (Variable Traffic)

For serverless deployments, the 33% discount on both storage and compute makes the differential even more pronounced at scale.

These figures assume simple GET and SET operations at one ECPU per request with payloads under 1KB, sustained around the clock at the stated rate. Complex operations on sorted sets or hashes, and larger values, consume proportionally more ECPUs. At sustained high request rates serverless becomes considerably more expensive than equivalent node based clusters; its value is in workloads that are spiky, small or unpredictable.

5.3 Memory Efficiency Multiplier

The comparisons above assume identical node sizing, but Valkey’s memory improvements sometimes allow downsizing. AWS documented a customer case where moving from ElastiCache for Redis OSS to Valkey 8.1 reduced memory usage by 36%, allowing a move from r7g.xlarge to r7g.large nodes; combined with the 20% engine discount, total savings reached 50%.

Be careful generalising from that case. Dropping one node size halves available memory, so a 36% reduction only makes it possible when the cluster already had meaningful headroom. For the Large Cluster above, the downsized scenario looks like this, but only applies if your working set after migration genuinely fits in half the memory with your normal reservation intact:

The sensible way to use this is to migrate on the same node size first, measure actual memory for a few weeks, and then downsize if the data supports it. Measure read latency over the same period before downsizing; a smaller node gives a hash read regression of the kind in section 2.3 less CPU headroom to absorb it.

5.4 ElastiCache Serverless

ElastiCache Serverless charges for data storage (GB hours) and compute (ElastiCache Processing Units, or ECPUs). One ECPU covers 1KB of data transferred for simple GET and SET operations; more complex commands such as HMGET consume ECPUs in proportion to vCPU time or data transferred, whichever is higher.

In us-east-1, ElastiCache Serverless for Valkey is priced at $0.0837 per GB hour for storage and $0.00227 per million ECPUs. ElastiCache Serverless for Redis OSS is priced at $0.125 per GB hour and $0.0034 per million ECPUs. That is 33% lower on both storage and compute for Valkey.

Because complex commands are billed on vCPU time or bytes transferred, a command that has become more expensive to serve can also cost more ECPUs. If a hash read regression like the one in section 2.3 affects you on serverless, watch ECPU consumption per read alongside latency; the 33% price advantage is still there, but part of it may be spent on the extra work until the upstream fixes land.

The minimum metered storage is 100MB for Valkey against 1GB for Redis OSS, which means a Valkey serverless cache can start at roughly $6 a month compared with roughly $91 a month for Redis OSS.

For a reference workload of 10GB average storage and 50,000 requests per second, storage runs 10GB × $0.0837 × 730 hours, or $611 a month for Valkey against $912.50 for Redis OSS. Compute runs 180 million ECPUs an hour × 730 hours × $0.00227 per million, or $298 a month for Valkey against $447 for Redis OSS. The total is roughly $909 a month for Valkey against $1,359 for Redis OSS, a 33% saving.

AWS has also added public endpoints to ElastiCache Serverless, protected by IAM authentication and TLS 1.3, which removes the need for a VPC in some edge and serverless application patterns.

5.5 ElastiCache Node Based Pricing

For node based clusters where you choose instance types, Valkey is priced 20% lower than Redis OSS across all node types. A cache.r7g.xlarge node in us-east-1 costs $0.350 an hour for Valkey against $0.437 for Redis OSS, which is $256 against $319 a month per node. For a 6 node cluster (3 shards, 1 replica each), annual savings come to roughly $4,570.

Reserved nodes offer additional discounts of up to around 55% for three year all upfront terms on top of the Valkey pricing advantage. Critically, if you hold Redis OSS reserved node contracts and migrate to Valkey, your reservations continue to apply, and because a Valkey node consumes 20% fewer normalised units, the same reservation covers more Valkey capacity than it did Redis OSS capacity.

5.6 MemoryDB, and Durability in ElastiCache

Amazon MemoryDB, the durable in memory database with multi AZ persistence, follows the same pattern, with MemoryDB for Valkey priced 30% lower on instance hours than MemoryDB for Redis OSS. A db.r6g.xlarge node in us-west-2 costs $0.432 an hour for Valkey against approximately $0.617 for Redis OSS, so a typical HA deployment of one primary and one replica runs about $631 a month for Valkey against $901 for Redis OSS. MemoryDB for Valkey also removes data written charges up to 10TB a month; above that, pricing is $0.04 per GB, 80% lower than MemoryDB for Redis OSS.

The line between the two services has blurred. ElastiCache’s Valkey 9.0 engine version introduced durability through a multi AZ transactional log, with a choice between synchronous writes, which AWS describes as zero data loss at single digit millisecond write latency, and asynchronous writes, which keep microsecond write latency but can lose up to 10 seconds of data. For banks and other regulated users, this is significant: it puts a system of record option inside ElastiCache, and it means the MemoryDB versus ElastiCache decision now deserves a fresh look rather than a default.

5.7 Data Tiering Economics

For workloads with cold data that must remain accessible, ElastiCache and MemoryDB both support data tiering on r6gd node types, which moves infrequently accessed data from memory to locally attached SSD automatically.

A db.r6gd.4xlarge with data tiering can store 840GB in total (approximately 105GB in memory and 735GB on SSD) at significantly lower cost than pure in memory equivalents. For compliance workloads requiring 12 months of data retention, this can reduce costs by around half compared with fully in memory configurations, while keeping low millisecond latencies for hot data. The saving depends heavily on how skewed your access pattern is; tiering works well when a small fraction of keys takes most of the traffic and poorly when access is uniform.

5.8 Scaling Economics

ElastiCache Serverless for Valkey 8.0 scales dramatically faster than 7.2. AWS states that it can double supported requests per second every two to three minutes and reach 5 million requests per second from zero in under 13 minutes, with consistent sub millisecond p50 read latency. For burst workloads, faster scaling means shorter periods of throttling and elevated tail latency during traffic spikes.

5.9 Migration: The Easy Path and the One Way Door

AWS provides zero downtime, in place upgrades from ElastiCache for Redis OSS to ElastiCache for Valkey. The process is a few clicks in the console or a single CLI command:

aws elasticache modify-replication-group \
  --replication-group-id my-cluster \
  --engine valkey \
  --engine-version 9.0

Check which target versions your current engine can upgrade to directly before running this, since some older Redis OSS versions need an intermediate step. Your reserved node pricing carries over, and you immediately begin receiving the 20% discount on node based clusters or 33% on serverless. There is no migration cost beyond the time it takes to validate application compatibility and performance.

That last word deserves more weight than the original version of this guide gave it. An in place engine upgrade is easy to start and not easy to reverse: ElastiCache does not offer an in place path from Valkey back to Redis OSS, so rolling back means restoring a pre upgrade snapshot into a new cache and repointing clients. Before upgrading a production cache, take a snapshot, restore it into a second cache on the target engine, and replay or mirror a representative slice of real read traffic against it, comparing read and write latency per command family rather than in aggregate. Section 2.3 shows why: an upgrade can cut write latency by more than half and still make your most important read path several times slower.

That easy path exists because ElastiCache Redis OSS stops at 7.1, which Valkey can read natively. Outside ElastiCache, the story is different, and the original version of this guide did not make this clear enough. Valkey can load RDB snapshots and AOF files from Redis versions up to 7.2.x, but Redis 7.4 moved to RDB format version 12, which Valkey will not load. Anything that relies on that serialisation fails as well: copying dump.rdb, MIGRATE, DUMP and RESTORE, and a full resynchronisation when a Valkey node is attached as a replica of a Redis 7.4 or later primary.

If you run self managed Redis 7.4 or Redis 8, or Redis Software or Redis Cloud, moving to Valkey therefore means a logical migration: scanning keys and rewriting them type by type into the new cluster, dual writing from the application during a cutover window, or rebuilding the cache from source of truth if it is genuinely ephemeral. Hash field TTLs, Redis only data types such as vector sets, and the newer commands in section 3.1 all need explicit handling. None of this is difficult for a cache, but it is real engineering work for a durable store, and the cost grows every month an estate spends adopting Redis 8 features. If you are on Redis 7.2 or earlier today and expect to end up on Valkey eventually, it is cheaper to move before you upgrade than after.

5.10 Total Cost of Ownership

For an enterprise running 100GB across 10 ElastiCache clusters with typical caching workloads, the annual savings from Redis OSS to Valkey are substantial.

In a serverless scenario with 10 clusters of 10GB each, averaging 100,000 requests per second per cluster, Valkey costs roughly $145,000 a year against roughly $217,000 for Redis OSS, a saving of about $72,000 annually.

In a node based scenario with 10 clusters, each of 3 shards with 1 replica on cache.r7g.2xlarge (60 nodes in total), Valkey costs roughly $367,000 a year against roughly $459,000 for Redis OSS, a saving of about $92,000 annually.

These numbers exclude operational benefits from faster scaling, any downsizing that memory efficiency allows, and the Extended Support premiums that teams on Redis OSS 4, 5 and soon 6 are paying or will pay. They also assume your command mix costs the same to serve on both engines, which section 2.3 shows is not guaranteed for hash heavy reads.

6. Google Cloud and Azure Considerations

Google Cloud Memorystore for Valkey is generally available with a 99.99% SLA. Committed use discounts offer 20% off for one year terms and 40% off for three year terms, fungible across Memorystore for Valkey, Redis Cluster, Redis and Memcached. Google was first to market with Valkey 8.0 as a managed service.

Azure has moved firmly in the opposite direction. Microsoft has announced the retirement of every tier of Azure Cache for Redis: the Enterprise and Enterprise Flash tiers retire on 31 March 2027, with instances migrated to Azure Managed Redis from 1 April 2027, and the Basic, Standard and Premium tiers retire on 30 September 2028. The replacement, Azure Managed Redis, is built on Redis Enterprise software and is clustered by default, which means hostname changes and, for some applications, client changes when you migrate. Azure customers do not have a native Valkey option, and the retirement means every Azure Redis estate faces a migration in the next two years regardless. For Azure primary organisations that would prefer Valkey, that forced migration is the natural moment to decide; the options are self managed Valkey on AKS, a third party managed Valkey service, or multi cloud architectures that use AWS or GCP for caching.

Redis Cloud, Redis Inc’s managed offering, operates across AWS, GCP and Azure with consistent pricing. Commercial quotes are required for production workloads, which makes direct comparison difficult, but the pricing does not include the aggressive discounting that cloud providers apply to their own Valkey services.

7. Third Party Options

Upstash offers a true pay per request serverless Redis compatible service at $0.20 per 100K requests plus $0.25 per GB of storage. For low traffic applications (under 1 million requests a month with 1GB of storage), Upstash costs roughly $2.25 a month, against about $6 for the smallest ElastiCache Serverless Valkey cache and about $91 for Redis OSS. Upstash also provides a REST API for environments where TCP is restricted, such as Cloudflare Workers.

Aiven and Percona now offer managed services and commercial support for Valkey, which matters for organisations that want Valkey on infrastructure outside the big three clouds or need a support contract for self managed clusters.

Dragonfly, KeyDB and other Redis compatible alternatives exist but lack the cloud provider backing and scale validation that Valkey has demonstrated.

8. Clients, Tooling and Security Operations

Client strategy deserves a decision of its own. Most Redis client libraries work against Valkey unchanged, but the Valkey project now maintains its own client, Valkey GLIDE, built on a shared Rust core with consistent behaviour across languages. GLIDE 2.4 added client side caching and extended language support to C# and PHP. Valkey Admin, an open source visual cluster management tool, reached general availability alongside Valkey 9.1. Standardising on one client per language, and knowing whether it is tested against your engine version, removes a class of subtle incompatibilities as the command sets diverge.

The client also shows up in performance. In the issue #3451 thread, a contributor reran the reporter’s Python scan workload with valkey-py in place of redis-py and saw full scan times fall from about 63 to 53 seconds against Valkey 9.0.2, and from about 59 to 49 seconds against Valkey 8.1.6. That is a single test of end to end scan time, which includes client side parsing, so it says nothing about server latency; but it is a reminder that a client swap is a cheap experiment when chasing read performance.

Security cadence matters as much as engine choice. Both projects shipped fixes for remote code execution vulnerabilities in 2026: Redis 8.6.3 in May fixed five CVEs, including use after free and invalid memory access flaws that could lead to remote code execution, and Valkey 9.1.1 and 9.0.5 in July fixed a use after free in TLS connection handling that could let an authenticated client achieve remote code execution, along with a corrupt stream RDB issue. The same Valkey releases also fixed corrupted client replies caused by a race between in flight writes and reply buffer reuse when I/O threads are enabled, which is another reason to run the latest patch release of whichever minor version you choose. Neither project is unusually exposed; both are large C codebases under increasingly capable scrutiny. What this means in practice is that your managed provider’s patch window, or your own patching discipline for self managed clusters, is a first order risk control, and should be part of the evaluation.

9. Decision Framework

9.1 Choose Valkey When

Licensing clarity matters. BSD 3 clause eliminates legal review friction and keeps every exit open.

You are on ElastiCache or Memorystore today. Valkey is the only engine either service is moving forward, it is 20% to 33% cheaper than Redis OSS on AWS, and the in place upgrade is the lowest risk migration you will ever be offered, provided you test your read path first (section 5.9).

Cost optimisation is a priority. Lower pricing on the major cloud platforms, reservation portability, and memory improvements that sometimes allow downsizing.

Search is needed but not at the depth of a dedicated search engine. Valkey Search 1.2 now covers full text, tag, numeric and vector queries with aggregations.

Multi tenancy on a shared cluster matters. Numbered databases in cluster mode and database level ACLs are useful and Valkey specific.

Traditional use cases dominate. Caching, session stores, leaderboards, rate limiting and queues, and write heavy workloads, where the threading and memory work shows up most clearly.

9.2 Choose Redis When

Time series is critical. RedisTimeSeries ships in core; Valkey has only a community module.

You need the most mature search and query capability. The Redis Query Engine has many more years in production and a richer query language, and FT.HYBRID is a strong option for retrieval workloads.

Vector sets fit your design. They are a native data type in Redis core with no direct Valkey equivalent.

Your hottest path is fetching whole, wide hashes and you cannot change the access pattern. Until the fixes in section 2.3 ship, current Redis is faster on that specific shape in the published reports. If you can change the access pattern (section 10.4), this reason largely disappears.

You are already on Redis 7.4, Redis 8, Redis Software or Redis Cloud. The RDB format break makes leaving a logical migration project, and that cost should be weighed honestly against the savings.

You are Azure primary and want a first party managed service. Azure Managed Redis is built on Redis Enterprise and is where Microsoft is taking every existing Azure Redis customer.

Following the original creator’s technical direction has value. Antirez remains active at Redis and continues to build new data types.

9.3 Choose Managed Serverless When

Traffic is unpredictable or spiky. ElastiCache Serverless scales automatically, and Valkey 8.0 and later scale considerably faster than earlier engines.

Ops overhead must be minimal. No node sizing, patching or capacity planning.

Low traffic applications dominate. Valkey’s roughly $6 a month minimum against about $91 for Redis OSS on ElastiCache Serverless.

Sustained request rates are low to moderate. At high, constant throughput, node based clusters are usually much cheaper.

10. Production Tuning Notes

10.1 Valkey I/O Threading

Enable with io-threads N in configuration. A reasonable starting point on Valkey 8.x is core count minus two for the I/O thread count; the system adjusts active threads dynamically based on load, so slight over provisioning is safe. Valkey 9.1 introduced a new I/O threading model, in which threads pull work from a shared queue and the first I/O thread is woken once main thread CPU passes roughly 30%, and it offloads more object deallocation from the main thread, so benchmark your thread count again after upgrading rather than carrying the old setting forward. The 9.1 INFO output adds active_io_threads_num and pending I/O job counters, which make it much easier to see whether threads are actually being used.

For TLS workloads, Valkey 8.1 offloads TLS negotiation to I/O threads, which substantially improves new connection rates for clients that reconnect frequently. Valkey 9.1 adds automated TLS certificate reloading, which removes a common source of restart driven maintenance.

10.2 Memory Defragmentation

Valkey 8.1 reduced the active defrag cycle time to 500 microseconds with anti starvation protection, which largely removes the historical problem of 1ms plus latency spikes during defragmentation. Valkey 9.1 also reduced latency spikes during rehashing.

10.3 Cluster Scaling

Valkey 8.0 introduced automatic failover for empty shards and replicated migration states, contributed by Google, so cluster consistency is maintained through node failures during slot movement. Valkey 9.0’s atomic slot migration goes further, moving whole slots as a snapshot and avoiding the redirects and retries of key by key migration. If you reshard regularly, this alone justifies moving to 9.0 or later, and Redis users get the equivalent from Redis 8.4 onward.

10.4 Read Heavy Hash Workloads

If your read latency rose after moving to Valkey, or you are about to move and your application leans on hashes, these are the steps worth taking, roughly in order of effort.

1. Find out what your reads actually are. Aggregate read latency hides the command mix. On node based clusters, INFO commandstats and the per command latency metrics in CloudWatch show which commands dominate time; on serverless, the per command family metrics such as HashBasedCmds show how much of your read traffic is hash commands. The regression in section 2.3 is specific to commands that return a whole hash (HGETALL, HKEYS, HVALS), and it grows with the number of fields and the size of the reply.
2. Ask for fields, not hashes. If the application only needs a handful of fields, HMGET key f1 f2 f3 is the better command on any engine, and it avoids the deferred length path because the reply count is known from the arguments. Code that calls HGETALL and then reads three fields from the result is common, and on a wide hash it pays for the whole reply on every call.
3. Move large blobs out of hashes. The issue’s workload, many small fields plus one blob of tens of kilobytes, is close to the worst case: the blob forces the reply well past the 16KB static buffer and drags every small field along with it. Storing the blob as its own string key, fetched with GET only when needed, keeps the metadata hash small and makes the expensive read optional.
4. Avoid scanning the whole keyspace with HGETALL. Full SCAN plus HGETALL sweeps are usually reporting, export or warm up jobs. Point them at a replica, rate limit them, or move them off the cache entirely, so they do not compete with latency sensitive traffic.
5. Pipeline and batch. Fewer round trips do not fix the per reply cost, but they recover client and network time around it. The #4417 benchmarks show pipelining helps less than the exact length fix itself, so treat it as a complement rather than a cure.
6. Try the Valkey native client. On the evidence in section 8, swapping redis-py for valkey-py, or moving to GLIDE, is a cheap experiment with a measurable effect on end to end time.
7. Pick your engine version deliberately. Valkey 9.1 measured somewhat better than 9.0 on this workload, and its patch releases include reply buffer fixes for I/O threads, so if your managed service offers 9.1 it is the version to test. Track #4417 and #4869 through the 9.2 cycle; if they land, retest before spending engineering time on application changes you might no longer need.
8. Measure percentiles, not hourly averages. Hourly CloudWatch averages are good enough to spot a step change but blur the upgrade window and hide the tail. Record client side p50 and p99 per operation before and after any change, so you can tell a real improvement from averaging noise.

The script below builds a test dataset shaped like the issue’s workload and compares the three access patterns from steps 2 and 3. Run it against a non production cache, because the loader holds the main thread while it writes. All keys share the {bench} hash tag so the loader runs in cluster mode, and TLS=1 adds --tls, which ElastiCache Serverless requires.

cat > hash-read-bench.sh << 'EOF'
#!/usr/bin/env bash
# Compare HGETALL on wide hashes against HMGET and a split blob GET.
# Usage: ./hash-read-bench.sh <host> <port>
# Optional env: KEYS (default 1000), BLOB_BYTES (default 20000),
#               REQUESTS (default 100000), CLIENTS (default 50), TLS=1
set -euo pipefail

HOST="${1:-127.0.0.1}"
PORT="${2:-6379}"
KEYS="${KEYS:-1000}"
BLOB_BYTES="${BLOB_BYTES:-20000}"
REQUESTS="${REQUESTS:-100000}"
CLIENTS="${CLIENTS:-50}"
TLS_FLAG=""
if [ "${TLS:-0}" = "1" ]; then TLS_FLAG="--tls"; fi

CLI="valkey-cli -h $HOST -p $PORT $TLS_FLAG"
BENCH="valkey-benchmark -h $HOST -p $PORT $TLS_FLAG -n $REQUESTS -c $CLIENTS -r $KEYS --threads 4 --csv"

echo "Loading $KEYS hashes (99 x 100 byte fields plus a $BLOB_BYTES byte blob)"
$CLI EVAL "
  local n = tonumber(ARGV[1])
  local blob = string.rep('y', tonumber(ARGV[2]))
  local small = string.rep('x', 100)
  for i = 0, n - 1 do
    local id = string.format('%012d', i)
    local args = {}
    for j = 0, 98 do
      args[#args + 1] = 'metric' .. j
      args[#args + 1] = small
    end
    args[#args + 1] = 'chunk'
    args[#args + 1] = blob
    redis.call('HSET', 'bench:{bench}:h:' .. id, unpack(args))
    redis.call('HSET', 'bench:{bench}:m:' .. id, unpack(args, 1, 198))
    redis.call('SET', 'bench:{bench}:b:' .. id, blob)
  end
  return n
" 0 "$KEYS" "$BLOB_BYTES"

echo "1) HGETALL on the wide hash with the blob inside"
$BENCH HGETALL "bench:{bench}:h:__rand_int__"

echo "2) HMGET of five fields from the same hash"
$BENCH HMGET "bench:{bench}:h:__rand_int__" metric0 metric1 metric2 metric3 metric4

echo "3) HGETALL on the metrics only hash (blob moved out)"
$BENCH HGETALL "bench:{bench}:m:__rand_int__"

echo "4) GET of the split out blob"
$BENCH GET "bench:{bench}:b:__rand_int__"

echo "Clean up with: $CLI --scan --pattern 'bench:{bench}:*' | xargs -n 500 $CLI DEL"
EOF
chmod +x hash-read-bench.sh

Run it on the engine you have today and on the one you are moving to, from the same client host. The comparison between engines for test 1 tells you whether the regression affects your data shape at all; the comparison between tests 1, 2 and 3 on the new engine tells you how much of it an application change would recover.

To check a cache you have already upgraded, the second script pulls the same CloudWatch metrics used in section 2.3, but as hourly p50 and p99 rather than averages, alongside throttling and hit rate so the obvious alternative explanations sit in the same output. ElastiCache Serverless caches use the clusterId dimension; for a node based cluster, set DIM_NAME=CacheClusterId and pass a node ID such as my-cluster-0001-001. It needs the AWS CLI and GNU date, with a fallback for the BSD date on macOS.

cat > valkey-upgrade-latency.sh << 'EOF'
#!/usr/bin/env bash
# Hourly server side latency percentiles, throttling and hit rate for one cache.
# Usage: ./valkey-upgrade-latency.sh <cache-name-or-node-id> [hours, default 48]
# Optional env: DIM_NAME (default clusterId; use CacheClusterId for node based),
#               AWS_REGION
set -euo pipefail

TARGET="${1:?pass the serverless cache name or a node id}"
HOURS="${2:-48}"
DIM_NAME="${DIM_NAME:-clusterId}"

END=$(date -u +%Y-%m-%dT%H:%M:%SZ)
START=$(date -u -d "-${HOURS} hours" +%Y-%m-%dT%H:%M:%SZ 2>/dev/null \
  || date -u -v-"${HOURS}"H +%Y-%m-%dT%H:%M:%SZ)

pull() {
  local metric="$1"; shift
  echo
  echo "== ${metric} =="
  aws cloudwatch get-metric-statistics \
    --namespace AWS/ElastiCache \
    --metric-name "$metric" \
    --dimensions Name="$DIM_NAME",Value="$TARGET" \
    --start-time "$START" --end-time "$END" \
    --period 3600 "$@" \
    --output text
}

# Latency in microseconds, as hourly p50 and p99.
for m in SuccessfulReadRequestLatency SuccessfulWriteRequestLatency; do
  pull "$m" --extended-statistics p50 p99 \
    --query 'sort_by(Datapoints,&Timestamp)[].[Timestamp,ExtendedStatistics.p50,ExtendedStatistics.p99]'
done

# Rule outs: throttling should be zero, hit rate should be steady.
pull ThrottledCmds --statistics Sum \
  --query 'sort_by(Datapoints,&Timestamp)[].[Timestamp,Sum]'
pull CacheHitRate --statistics Average \
  --query 'sort_by(Datapoints,&Timestamp)[].[Timestamp,Average]'

# How much of the read traffic is hash commands.
pull HashBasedCmds --statistics Sum \
  --query 'sort_by(Datapoints,&Timestamp)[].[Timestamp,Sum]'
EOF
chmod +x valkey-upgrade-latency.sh

If read p99 has moved by much more than read p50, the regression is concentrated in a subset of calls, which points towards large replies; if both moved together and HashBasedCmds is a large share of traffic, the hash read path in section 2.3 is the first suspect.

11. The Verdict

The Redis fork has produced genuine competition for the first time in the in memory data store space, and both projects are better for it. Valkey is not a maintenance fork; it has shipped two major releases since the original version of this guide, closed its biggest feature gap with full text search, and remains backed by engineers who wrote much of the original Redis codebase and by the largest cloud providers. Redis, for its part, has answered with a steady stream of releases and has matched Valkey on atomic slot migration, while staying ahead on time series, search maturity, native vector sets and, for now, reading whole hashes.

For enterprise architects, the calculus is still mostly straightforward, but the reasons have shifted. Performance is no longer a decisive differentiator in either direction without your own benchmarks, and our own upgrade is the best argument for that: write latency fell by roughly two thirds while read latency rose by several times on the same cache. Licensing, cloud alignment and cost are the durable differentiators. On AWS and GCP, Valkey is cheaper, open source and the only engine the managed services are investing in. On Azure, the platform is taking you to Redis Enterprise whether you planned for it or not. And if you are already on Redis 7.4 or later, the RDB break means the switch is a project, not a configuration change.

The commercial signals on AWS remain unambiguous: Valkey is priced 20% to 33% below Redis OSS on ElastiCache and 30% below on MemoryDB, reservations transfer, and the in place upgrade is zero downtime for anyone still on ElastiCache Redis OSS. Zero downtime is not the same as zero risk, though; test your read path on a restored copy before you flip production, and do it again when the upstream hash fixes ship.

The Redis licence changes in 2024 were intended to monetise cloud provider usage. Instead, they unified the two largest clouds behind an alternative that now competes on every axis. The return to AGPLv3 in 2025 acknowledged the strategic error, and Redis has executed well since, but the momentum in open source infrastructure has shifted.

Redis is open source again. But much of the community that made it great is building Valkey.