Valkey vs Redis: Differences, Licensing, and Which to Run in 2026

Valkey vs Redis: The Short Answer

Valkey vs Redis comes down to license, governance and roadmap more than protocol. Valkey is a BSD-3-Clause fork of Redis 7.2.4 run by the Linux Foundation. Redis 8+ is tri-licensed (RSALv2, SSPLv1 or AGPLv3) and run by Redis Ltd. Core commands and clients work on both. Newer features, data files and managed-service options differ.

If you run Redis 7.2 or earlier for caching, sessions, rate limiting or queues, the two are interchangeable at the application layer today. The differences show up in the license your legal team reviews, the features you’ll want next, and the managed service your cloud provider pushes you toward.

What Happened: The 2024 License Change and the Fork

On March 20, 2024, Redis Ltd. announced that Redis 7.4 onward would be dual-licensed under the Redis Source Available License v2 (RSALv2) and the Server Side Public License v1 (SSPLv1), replacing BSD-3-Clause. The accompanying FAQ acknowledged that “neither RSALv2 nor SSPL is an OSI-approved license.” The stated reason was that most commercial Redis sales were “channeled through the largest cloud service providers.”

On March 28, 2024, the Linux Foundation launched Valkey from Redis 7.2.4 under the original BSD-3-Clause license. Madelyn Olson, quoted in the launch, had spent four years on the Redis core team that drove open-source Redis through 7.2.

Licensing in 2026: BSD vs RSALv2, SSPLv1 and AGPLv3

Licensing is still the biggest practical difference. Redis’s license page sets it out by version:

RSALv2 allows use, modification and redistribution, but not offering Redis to others as a managed service or a competing product. SSPLv1 extends AGPL’s network clause: offer the software as a service and you must release the source of your whole service stack, including management and monitoring tooling. AGPLv3 is OSI-approved and allows any use, but if you modify Redis and users interact with it over a network, you must offer them your modified source.

For most teams running Redis internally behind their own application, none of this requires anything; Redis’s FAQ states that hosting Redis “for the internal use of your organization is permitted.” The license matters when you embed or redistribute the server, offer Redis-backed functionality as a hosted service, maintain internal server patches under a no-AGPL policy, or work where legal blocks non-OSI licenses outright.

Adding AGPL did not stall Valkey. AWS and Google kept shipping new Valkey versions through 2026, and AGPL covers only Redis 8 and later. Valkey’s BSD license has no copyleft terms, which is the simplest answer a legal team can get.

Governance: Foundation Project vs Company Project

Valkey is run by a Technical Steering Committee of repository maintainers. Its governance document caps any one organization at a third of TSC seats and requires a two-thirds super-majority for governance changes, so no single vendor can relicense it. Valkey counted 346 active contributors in 2025 (year-end review).

Redis is developed by Redis Ltd., which owns the trademark and requires a contributor license agreement for outside contributions. One company can move fast (bundling Redis Stack into the core and adding AGPL were both company decisions), and one company can also change the license, as it did in 2024. Foundation governance protects against unilateral change. Company governance gives you a single accountable owner and a commercial support path from the people who write the code.

Feature Divergence Since the Fork

Redis: more data types in the core. Redis 8.0 made the query engine, JSON, time series and five probabilistic structures part of the default distribution, plus a vector set type in preview (8.0 release notes). Since then (what’s new), 8.4 added atomic slot migration and compare-and-set for strings, 8.6 added stream idempotency and hot-key detection, 8.8 added an Array type, and 8.10 added compact hashes and incremental backup.

Valkey: cluster operations, efficiency, modules. Valkey 8.0 rewrote I/O threading and 8.1 introduced a new hash table. Valkey 9.0 added atomic slot migration, numbered databases in cluster mode and hash field expiration (announcement). Valkey 9.1 added database-level ACLs and a visual cluster tool, Valkey Admin (announcement). JSON, Bloom, vector search and LDAP ship as modules, pre-loaded in the valkey-bundle image.

Same idea, different command. Both projects built some features separately. For conditional writes on strings, Valkey uses SET with IFEQ (8.1) and DELIFEQ (9.0), while Redis 8.4 added its own SET extensions and DELEX (Redis 8.4, ElastiCache engine notes). Hash field expiration uses the same command names on both (HEXPIRE, HSETEX, HGETEX). Matching names don’t guarantee matching arguments or edge cases, so test any post-7.2 command against the engine you plan to run.

Is Valkey Compatible with Redis?

For the core, yes. Valkey’s migration guide states it “is compatible with Redis OSS 7.2 and all earlier open-source Redis versions.” Existing clients (redis-cli, redis-py, Jedis, Lettuce, go-redis, ioredis, StackExchange.Redis) connect without changes. Valkey’s own client, GLIDE, supports Python, Java, Node.js and Go, and works against Valkey 7.2 through 9.0 and Redis OSS 6.2 through 7.2.

Compatibility breaks in three places:

• Data files. “Redis Community Edition (CE) version 7.4 and later produce data files that are not compatible with Valkey,” per the same guide. A Redis 7.4 or 8.x snapshot will not restore into Valkey.
• Post-fork features. Redis vector sets, Arrays, time series and FT.* queries aren’t in core Valkey. Valkey’s cluster-mode databases and DELIFEQ aren’t in Redis.
• Modules. Redis 8 modules and Valkey modules are separate code with no guarantee of matching syntax.

If your application uses strings, hashes, lists, sets, sorted sets, streams, pub/sub and Lua, you are unlikely to notice which engine is underneath.

Valkey vs Redis Performance

There is no neutral, current head-to-head benchmark worth pointing to. Each project publishes numbers against its own previous version, on hardware it chose:

• Valkey 8.0: “up to 1.2 million requests per second on AWS r7g instances, over 3x higher than the previous version” (Linux Foundation).
• Valkey 9.0: up to 40% higher throughput from pipeline prefetching, and cluster changes the project says allow 2,000 nodes and over 1 billion requests per second across a cluster (Valkey).
• Valkey 9.1: up to 17% more throughput from redesigned I/O threading and up to 20% less memory for strings under 128 bytes (Valkey).
• Redis 8.0: p50 latency down 5.4% to 87.4% on 90 of 149 command tests versus Redis 7.2.5, and up to 112% more throughput with eight I/O threads (Redis).

Both engines now use multi-threaded I/O and both have spent two years on memory efficiency. For a cache, network round trips, pipelining and key design usually matter more than the engine. If per-node throughput drives your bill, benchmark your own command mix and value sizes on the instance type you’ll run.

Managed Services: What the Clouds Run

The managed-service picture has moved further than the code.

AWS. Per the October 2024 announcement, ElastiCache Serverless for Valkey is priced 33% below Serverless for Redis OSS, node-based Valkey 20% below, and MemoryDB for Valkey 30% below MemoryDB on Redis OSS. ElastiCache lists Valkey up to 9.1, while its Redis OSS support stops at 7.1; Redis OSS 6 leaves standard support on January 31, 2027. Some items on that page, such as the Multi-AZ durability option for “ElastiCache version 9.0 for Valkey,” are AWS additions, not open-source Valkey features.

Google Cloud. Memorystore for Valkey reached GA on April 2, 2025 and supports Valkey 7.2 through 9.1 (release notes). Memorystore for Redis tops out at 7.2.

Azure. Azure went the other way. Azure Managed Redis runs Redis Enterprise software, and Azure Cache for Redis is retiring: Enterprise tiers on March 31, 2027, and Basic, Standard and Premium on September 30, 2028 (Microsoft Learn). Microsoft’s guidance lists no Valkey option.

Others. DigitalOcean ended new deployments of its Redis-based Managed Caching on April 30, 2025 in favor of Managed Caching for Valkey. Heroku’s Key-Value Store, formerly Heroku Redis, runs Valkey. Redis Cloud is the managed path to current Redis on any cloud.

Migrating from Redis to Valkey

From Redis 7.2 or earlier. Valkey’s migration guide offers two routes. For minimal downtime, make Valkey a replica of your Redis primary with REPLICAOF, let it sync, then cut clients over and promote it; the guide warns that writes during the sync can be lost, so pause writes or verify before cutover. Where downtime is acceptable, copy the latest RDB snapshot into Valkey and start it.

From Redis 7.4 or 8.x. Snapshots and replication won’t work. Do a logical copy: dual-write from the application, replay from your source of truth, or use a tool that reads each key from Redis and rewrites it into Valkey. Inventory Redis 8 data types and FT.* indexes first; they need a Valkey module or a redesign.

On ElastiCache. AWS supports an in-place cross-engine upgrade. The endpoint stays the same, reads continue throughout, and writes pause only for a failover of a few seconds from Redis OSS 5.0.6 or later. Rollback is supported only from Valkey 7.2 to Redis OSS 7.1, so if you want a way back, land on Valkey 7.2 first, validate, then move up.

Before cutover, check every post-7.2 command your code uses against the target Valkey version, and confirm your dashboards and exporters parse Valkey’s INFO output correctly.

Valkey vs Redis vs Dragonfly (and Memcached)

Two other engines come up in the same search. Dragonfly is not a fork: it is a separate in-memory store written from scratch that speaks the Redis and Memcached protocols, so existing clients connect to it (GitHub). Its compatibility table tracks which Redis commands and options it accepts, and notes that supported does not mean identical behavior. It ships under the Business Source License 1.1, which bars offering it as a managed in-memory data store service and converts to Apache 2.0 on November 1, 2030. Teams consider it when they want Redis-protocol compatibility from an engine outside the Redis codebase and can accept a source-available license.

Memcached is the simpler model: an “in-memory key-value store for small arbitrary data (strings, objects)” that “does not understand data structures” (Memcached docs). There are no hashes, sorted sets or streams on the server; you store pre-serialized values. It still fits a pure look-aside cache of serialized objects, and ElastiCache offers it alongside Valkey and Redis OSS. Once you need server-side data structures, you are back to Valkey or Redis. The Redis alternatives guide compares these and the options beyond the Redis family.

Which to Run: Decision Table

If the problem isn’t which Redis-family engine to run, the Redis alternatives guide covers Dragonfly and the options beyond the Redis family.

When the Question Isn’t Which Cache

Some teams arrive at “valkey vs redis” because the license or the bill changed. Others arrive because the cache keeps causing incidents, and swapping one Redis-protocol engine for another won’t touch that.

The pattern: a decision (a fraud check, a credit limit, a recommendation, an agent’s next action) needs derived state such as a velocity count, a running balance or a risk tier. That state is computed upstream, pushed into the cache, and read at decision time. The real work is keeping the cached value in step with the source: invalidation logic, guessed TTLs, backfill jobs and reconciliation when a pipeline falls behind. When it slips, the decision acts on stale data. Valkey and Redis serve an out-of-date value just as fast as a current one.

The Tacnode Context Lake™ is built for that case. Tacnode holds the decision context: source data arriving from the systems you already run, derived signals computed from it and updated incrementally, sub-second behind each write, and the decisions themselves written back so the next one reads them. It is all served from one consistent snapshot, with no separate cache to invalidate. That is the Shared property: every service reads the same version of state.

To be clear on scope: Tacnode does not speak the Redis protocol and is not a drop-in for either engine; it presents the PostgreSQL wire protocol. If you need a key-value cache, run Valkey or Redis. If the cache exists only so a decision can read derived state, and keeping it fresh is the hard part, ask whether you need the cache at all.

Frequently Asked Questions