Valkey vs Redis: A Complete 2026 Comparison

Valkey and Redis are both high-performance, in-memory data stores used for caching, messaging and low-latency data access. They share a codebase: Valkey was forked from Redis OSS 7.2.4 in March 2024 and remains wire- and command-compatible with it. The practical differences today are licensing, the pace and direction of engine development, and — the part most comparisons skip — which optional modules each one ships.

Much of what was written about this split in 2024 is now out of date. Redis changed its licence again in 2025, both projects have shipped two major releases since, and the module ecosystems have diverged in ways that matter more than raw benchmark numbers. Here is where things actually stand.

Valkey vs Redis at a Glance

Current as of July 2026. Both projects patch frequently, so treat specific version numbers as a snapshot.

How the Two Diverged

The timeline matters, because a lot of the commentary about this split describes a situation that no longer exists.

Before March 2024, Redis shipped under the permissive BSD 3-Clause licence. Every release up to and including Redis 7.2.4 remains BSD-licensed; the change was not retroactive.

March 2024: Redis Ltd. announced that from version 7.4, Redis would ship under a dual model — the Redis Source Available License v2 (RSALv2) and the Server Side Public License v1 (SSPLv1). Neither is OSI-approved. Within days, the Linux Foundation forked Redis OSS 7.2.4 as Valkey, retaining the BSD licence. AWS, Google Cloud, Oracle, Ericsson and Snap backed the project.

May 2025: Redis 8.0 added AGPLv3 as a third licence option alongside RSALv2 and SSPLv1. AGPLv3 is OSI-approved, so Redis returned to being open source by that definition. Redis 8 also folded the previously separate Redis Stack modules — JSON, Time Series, probabilistic data structures and the Query Engine — into core under the same tri-licence, and introduced Vector Sets as a new data type.

Since then, both engines have shipped independently. Valkey released 8.1, 9.0 and 9.1; Redis moved through the 8.x line to 8.8. Neither is a stale fork of the other.

Licensing: The Honest Current Picture

This is the decision driver for most organisations, and it is more nuanced than "Redis is not open source" — a claim that stopped being accurate in May 2025.

Valkey is BSD 3-Clause. Permissive, non-copyleft, no restrictions on commercial use or on offering it as a managed service. For organisations with strict software distribution policies, this is the simplest possible position.

Redis gives you three options, and you choose one. RSALv2 is permissive but forbids offering the software to third parties as a managed service. SSPLv1 is copyleft with broad service-side obligations and is not OSI-approved. AGPLv3 is OSI-approved but is strong copyleft: if you modify the source and run it as a network service, you may be obliged to publish your modifications.

In practice, the AGPLv3 option is where enterprise Java teams run into trouble. Many organisations maintain blanket policies prohibiting AGPL-licensed dependencies, because legal teams are wary of the copyleft reach even where the obligations would not actually be triggered by ordinary use. That policy — rather than any technical judgement about the engines — is what pushes a large share of teams towards Valkey.

One option worth naming so you can rule it out: staying on Redis 7.2.4, the last BSD release. It works and it is licence-clean, but community security backports to that line are not guaranteed indefinitely, and freezing a data store accumulates risk quickly. If you want BSD-licensed and actively maintained, Valkey is the supported path.

Performance and Architecture

Both engines preserve the single-threaded command execution model that gives Redis its predictable atomic semantics. The performance work in both has gone into everything around that loop.

Valkey

Valkey 8.0 introduced asynchronous I/O threading, moving connection handling and write-buffer flushing onto dedicated threads. It also replaced the cluster keyslot linked list with a per-slot dictionary, which cuts roughly 16 bytes of overhead per key-value pair without degrading performance, and added dual IPv4/IPv6 support and lighter cluster pub/sub messages. Separately, dictionary-level memory work in the same release reduced overall memory usage by around 9–10% in scenarios with 16-byte keys and 8- or 16-byte values.

Valkey 9.0 continued with pipeline memory prefetching and the project's most aggressive round of SIMD acceleration to date, targeting AVX512 on x86 and NEON on ARM. These are transparent — no configuration required. AWS reports up to 40% higher throughput for pipelined workloads on Valkey 9.0.

Redis

Redis 8.0 reported substantial gains of its own, including significantly faster command execution and higher operations per second against earlier releases. Redis 8.8 added batched prefetch for MGET, MSET and HGETALL.

On RDMA

Valkey supports Remote Direct Memory Access, and it is frequently cited as a Valkey advantage. It is worth being precise about what that support currently is: RDMA remains experimental, is Linux-only, does not support TLS, and is not compatible with replication — TCP or TLS is still required for the replication link. From Valkey 9.0, valkey-cli and valkey-benchmark accept an --rdma flag. It is a genuinely interesting capability for specialised, single-node, high-throughput environments on RDMA-capable fabric. It is not something most production deployments can use today.

The broader point on performance: published benchmark differences between the two are in the single-digit to low-double-digit percentage range and depend heavily on workload shape, hardware and configuration. For the overwhelming majority of applications, this is not the deciding factor. Licensing and feature availability are.

Where They Actually Diverge: Data Structures and Modules

This is the most consequential difference in 2026, and the one least covered elsewhere. Core data types — strings, hashes, lists, sets, sorted sets, streams, bitmaps, HyperLogLog, geospatial indexes — are equivalent, and both now support per-field TTLs on hashes via the HSETEX, HGETEX, HTTL and HPERSIST command family. The divergence is in the optional extensions.

Redis 8 absorbed the Redis Stack modules into core. Valkey provides equivalents as separate BSD-licensed modules — valkey-json, valkey-bloom, valkey-search and valkey-ldap — which can be deployed together via the valkey-bundle container. Coverage is not uniform:

• JSON is close to parity. valkey-json implements the JSON command set almost completely, with JSONPath support and a maximum nesting depth of 128.
• Search is a genuine subset. valkey-search exposes six commands — FT.CREATE, FT.SEARCH, FT.AGGREGATE, FT.INFO, FT.DROPINDEX and FT._LIST. Autocomplete, synonyms, spellcheck, index aliasing, query profiling, cursors and GEOSHAPE polygon queries are all absent. If your search layer uses any of those, Valkey is not a drop-in.
• Probabilistic structures are partial. valkey-bloom provides Bloom filters. Cuckoo filters, Top-K, T-Digest and Count-Min Sketch have no Valkey module and no client-side substitute in the major Java clients, so applications using them have no Valkey path today.
• Time series has no Valkey equivalent at all. There are no TS.* commands in Valkey. For teams using RedisTimeSeries, this is usually the hardest part of a move.

If you are evaluating a switch, run MODULE LIST against every primary node before you plan anything else. Module dependencies are the most common source of unpleasant surprises, and they are far easier to discover during evaluation than during a cutover.

Which Should You Choose?

The engines are close enough that the decision usually comes down to four questions.

Does your organisation prohibit AGPL-licensed dependencies? If yes, choose Valkey. This is the most common deciding factor and it ends the discussion quickly.

Do you depend on Redis Stack modules? Check for time series, Cuckoo filters, Top-K, T-Digest, or advanced search features. If you rely on any of them, either stay on Redis or plan a replacement before committing to Valkey.

Where do you run? Valkey is available as a managed service on AWS ElastiCache and MemoryDB, Google Cloud Memorystore, Heroku and Aiven. On AWS, Valkey is now the default engine for new ElastiCache and MemoryDB clusters — which matters operationally, because environments provisioned from Terraform modules or templates will land on Valkey unless someone explicitly overrides it.

Azure is the outlier: there is no first-party managed Valkey offering, and Microsoft's position remains Redis-backed under its own commercial arrangement. Running Valkey on Azure means self-managing it, typically on AKS, though .NET Aspire does provide a Valkey resource.

Azure customers have a second consideration that changes the calculation. Microsoft has announced the retirement of Azure Cache for Redis: the Enterprise and Enterprise Flash tiers on 31 March 2027, and the Basic, Standard and Premium tiers on 30 September 2028, with Azure Managed Redis as the destination and migration tooling rolling out through 2026. If you are on Azure Cache for Redis, you are facing a migration regardless of what you decide here — which makes this a sensible moment to evaluate the alternatives properly rather than migrating twice.

Is your workload vector search at scale? Redis 8's Query Engine currently leads valkey-search on vector throughput. For retrieval-augmented generation and large-scale semantic search, that gap is worth measuring against your own data before deciding.

Absent any of these constraints, either engine will serve a typical distributed caching, session-store or messaging workload well. Valkey's permissive licence and vendor-neutral governance make it the lower-friction default for most new deployments; Redis remains the stronger choice where the integrated module set is doing real work.

What the Split Means for Java Applications

For a Java application, this decision is less disruptive than it looks — provided your Redis or Valkey Java client supports both engines.

Redisson does. The same API, the same distributed objects and the same integrations work against Valkey and Redis alike, so the choice between engines does not propagate into your application code. Redisson supports Valkey deployments from 7.2.5 through current releases, accepts the valkey://, valkeys:// (TLS) and valkey+uds:// (Unix domain socket) URL schemes alongside the traditional redis:// forms, and is listed in the official Valkey project client directory as an approved Java driver.

Three things follow from that, all of which reduce the risk of the decision.

You can defer the choice

Building against Redisson means the engine is a configuration detail rather than an architectural commitment. If licensing policy changes — as it has twice since 2024 — you are changing a connection string, not rewriting a data layer.

Client capability is not equal across the field

The Valkey project publishes its own comparison of advanced features across recommended clients. Among the three Java clients it lists, the results are worth knowing before you commit:

Two of these matter specifically during a migration. CLIENT CAPA redirect was added in Valkey 8 so that a replica can redirect data-access commands to the primary during an upgrade, avoiding errors in standalone mode — useful precisely when you are moving nodes around. And client-side caching, which Redisson is currently the only Java client on the list to support, absorbs the latency cost of a cutover by serving hot reads locally while the topology settles.

Some module gaps close, and some do not

A few capabilities that exist only as server modules are implemented inside Redisson itself, on top of core data structures. RTimeSeries is the important one: it uses no TS.* commands, so it works on any Valkey or Redis deployment and closes the single largest Valkey module gap outright. Redisson's standard RBloomFilter is likewise implemented client-side and needs no module, though an RBloomFilterNative variant is available where one is present.

Be aware of the limits, though. Redisson's RCuckooFilter, RTopK and RTDigest objects wrap the server's CF.*, TOPK.* and TDIGEST.* commands rather than reimplementing them. Valkey provides none of those commands, so these objects cannot work against Valkey — and neither can any other client's equivalent, because the commands are simply not there. If your application relies on Cuckoo filters, Top-K or T-Digest today, there is currently no Valkey path for them. That is a blocker to identify during evaluation, not during a cutover.

Beyond that, Redisson adds distributed locks, semaphores, rate limiters, reliable queues and messaging that neither engine provides natively, along with integrations for Spring, Spring Boot, Hibernate, MyBatis, Quarkus, Micronaut and JCache.

If you have already decided to move, the mechanics are covered in our guides to migrating a Java app from Redis Cluster to Valkey Cluster and upgrading a Valkey cluster with zero downtime.

Getting Started

Whichever engine you choose, Redisson gives Java developers a single client and a single API across both, along with distributed objects and services that neither provides out of the box. Compare the Redisson PRO and Community Edition feature sets, or start a free trial.

Moving an existing Java application across? Our guide to migrating from Redis to Valkey in Java covers every deployment topology.