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.

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, and the migration constraints that now matter more than they did at the fork.

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 introduced another new I/O threading model and 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, pipelining depth and TLS settings, because the gap is narrower and more workload dependent than it was a year ago.

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.

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.

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.

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.

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.

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.

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. 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.

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.

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.

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 and offloads more object deallocation from the main thread, so benchmark your thread count again after upgrading rather than carrying the old setting forward.

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.

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 and native vector sets.

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. Licensing, cloud alignment and cost are. 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.

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.