When Redis changed its license on March 20, 2024, it triggered one of the fastest open-source forks in recent memory. Eight days later, on March 28, 2024, the Linux Foundation announced Valkey — a community fork built from the last BSD-licensed Redis release, version 7.2.4 (Valkey migration docs). Two years on, the practical question for engineers isn't political. It's technical: how compatible are these two systems really, at the wire, at the disk, and at the command level?

This deep-dive answers that. We'll look at the RESP protocol both projects speak, the RDB and AOF on-disk formats they read and write, the exact point where their command sets and file formats begin to diverge, and what the performance gap actually looks like once you anchor it to real hardware.

Key TakeawaysValkey forked from Redis OSS 7.2.4 and speaks an identical RESP2/RESP3 wire protocol — existing Redis clients connect unchanged (Valkey protocol spec, 2025).RDB and AOF files are fully interchangeable at the Redis 7.2 baseline, but RDB files written by Redis CE 7.4+ will not load into Valkey — the central forward-compatibility risk (Valkey, 2025).Valkey 8.0 reached roughly 1.2M requests/sec on AWS hardware — a ~230% jump over the 7.2 baseline on the same instance (Valkey, Sept 2024).Redis 8 (May 2025) folded the former Stack modules into core under a tri-license; Valkey keeps equivalents as separate BSD modules.

Why did Valkey fork from Redis in the first place?

In March 2024, Redis Ltd. relicensed Redis from the permissive BSD-3-Clause to a dual source-available model — RSALv2 and SSPLv1 — starting with the 7.4 release (Percona, March 20, 2024). Source-available is not open source: the SSPL in particular restricts offering the software as a managed service, which directly affected cloud providers and distributions.

The response was immediate. Within a week, AWS, Google Cloud, Oracle, and others rallied behind a Linux Foundation fork of the last BSD commit. That fork became Valkey, forked from Redis OSS 7.2.4 (Valkey migration docs). Major Linux distributions that ship default packages — Fedora, Debian, Ubuntu — moved toward Valkey because they cannot ship source-available software in their main repositories.

The story didn't end there. In November 2024, Redis creator Salvatore Sanfilippo (antirez) rejoined the company, and on May 1, 2025, Redis added AGPLv3 as a third license option starting with Redis 8 (Redis blog, May 1, 2025). Redis is once again available under a true open-source license — but by then Valkey had its own momentum, governance, and release cadence.

As of mid-2026, both projects are healthy and shipping. Valkey's current line is 9.1.x (9.1.0 landed May 2026) with an 8.1.x maintenance branch, while Redis is on its 8.x line (endoflife.date).

Milestone

Date

What changed

Redis relicense

Mar 20, 2024

BSD-3 → RSALv2 + SSPLv1 (from 7.4)

Valkey fork

Mar 28, 2024

Forked from Redis 7.2.4 under the Linux Foundation

antirez returns

Nov 2024

Redis creator rejoins Redis Ltd.

Redis 8 + AGPLv3

May 1, 2025

Tri-license: RSALv2 / SSPLv1 / AGPLv3

Are Valkey and Redis API-compatible at the protocol level?

Yes — at the wire-protocol level they are identical. Both Valkey and Redis speak the REdis Serialization Protocol (RESP), supporting both RESP2 and the newer RESP3 introduced in Redis 6 (Valkey protocol spec). Because Valkey began as a literal fork of the Redis 7.2.4 source tree, its protocol handler is the same code. A client has no way to tell, at the byte level, whether it is talking to one or the other during a standard handshake and command exchange.

This is the single most important compatibility fact for most teams. Your existing client library — redis-py, ioredis, Jedis, Lettuce, go-redis, StackExchange.Redis — connects to a Valkey server with no code change. The protocol negotiation, pipelining, pub/sub framing, and cluster redirection messages (MOVED, ASK) all behave the same.

Consider a raw RESP exchange. A SET command followed by GET looks like this on the wire, and the framing is byte-for-byte the same on both servers:

C: *3\r\n$3\r\nSET\r\n$3\r\nfoo\r\n$3\r\nbar\r\n
S: +OK\r\n

C: *2\r\n$3\r\nGET\r\n$3\r\nfoo\r\n
S: $3\r\nbar\r\n

RESP3 adds typed replies — maps, sets, doubles, big numbers, and push messages for client-side caching. Both projects negotiate RESP3 through the HELLO 3 command identically. So whether you use HELLO to upgrade the connection or stay on RESP2, the behavior is consistent across both servers.

Because Valkey is a source-level fork of Redis 7.2.4, it inherits the exact RESP2/RESP3 implementation. No client library, proxy, or monitoring agent that speaks the Redis protocol needs modification to work against Valkey — the wire format is unchanged (Valkey, 2025).

Where do the command sets actually diverge?

Divergence is not at the protocol layer — it's at the command-set layer, and it grows with each release past the 7.2.4 fork point. Both projects keep adding commands independently, so command parity is a per-version question, not a yes/no answer. The protocol that carries the commands stays identical; the available verbs do not.

On the Redis side, Redis 7.4 introduced Hash Field Expiration — the HEXPIRE, HPEXPIRE, HEXPIREAT, and HTTL family — which lets you set TTLs on individual hash fields rather than the whole key. Valkey added equivalent functionality later, with hash-field expiration landing in the Valkey 9.0 cycle. The behavior converges, but the timing and edge-case semantics can differ, so test against your target version.

Valkey has shipped its own operational additions too. Valkey 8.1 introduced SET ... IFEQ, a conditional update that only writes if the current value matches an expected one — useful for optimistic concurrency without a full Lua script (Valkey, April 2025). The same release added COMMANDLOG, extending the older slowlog concept to track large requests and replies, not just slow ones.

Capability

Redis

Valkey

RESP2 / RESP3

Yes

Yes (identical)

Hash field expiration (HEXPIRE family)

Since 7.4

Since 9.0

Conditional SET ... IFEQ

Not native

Since 8.1

COMMANDLOG

No

Since 8.1

Vector sets

Since 8 (antirez)

Via valkey-search module

The practical takeaway: if your application sticks to the core data-type commands that existed at 7.2.4 — strings, hashes, lists, sets, sorted sets, streams, pub/sub, transactions, scripting — you have near-total portability in both directions. The moment you adopt a command added after the fork, verify it exists and behaves the same on the other project at the specific version you target.

Are RDB and AOF data formats compatible between Valkey and Redis?

At the Redis 7.2 baseline, completely. Valkey reads and writes RDB snapshot files and AOF (append-only file) logs that are compatible with Redis OSS 7.2 — the RDB version 11 format (Valkey migration docs). This is what makes migration so painless for teams still on Redis 7.2 or earlier: you stop Redis, point Valkey at the same dump.rdb or AOF directory, and start it. The data loads natively.

The same compatibility underpins replication-based migration. Because Valkey speaks the Redis replication protocol and understands the Redis 7.2 RDB stream, you can configure a Valkey instance as a replica of a Redis 7.2 primary, let it sync, then promote it — a near-zero-downtime cutover.

But there is a hard edge, and it's the most important caveat in this entire comparison. RDB files produced by Redis CE 7.4 and later are not compatible with Valkey (Valkey migration docs). After the 7.2.4 fork, Redis evolved its RDB format to support new in-core data types — and those newer RDB files will not load into a Valkey server. The formats have diverged.

RDB interoperability is anchored to the 7.2 fork point, not to "Redis" in general. Valkey loads RDB and AOF files from Redis OSS 7.2, but Redis CE 7.4+ RDB files will not load into Valkey because both projects extended the format independently after the split (Valkey, 2025).

Two consequences follow. First, if you're on Redis 7.4 or 8, a file-level migration to Valkey is no longer a drop-in copy — you need a logical migration path (replication from a compatible version, or a tool that reads keys over the wire and rewrites them). Second, treat the reverse direction with caution: loading Valkey-written files into Redis is not officially documented as supported, so don't assume bidirectional file interop. Plan migrations as one-directional from a known-compatible baseline.

What this means for your migration plan

If you're on Redis ≤ 7.2: file copy or replica-promotion both work cleanly. If you're on Redis 7.4+ or Redis 8: use live replication where the source version allows it, or a key-by-key migration tool that operates at the command level rather than the file level. Always validate with a representative dataset before cutover, and snapshot both sides so you can roll back.

How does Valkey 8.x performance compare to Redis?

This is where the fork stopped being a copy and started pulling ahead on its own engineering. Valkey 8.0 delivered roughly 1.2M requests per second on AWS hardware — a separate published test measured a jump from about 360K to 1.19M RPS, a ~230% gain, on a c7g.16xlarge instance with 8 I/O threads (Valkey, Sept 2024). That number is real, but it is hardware-specific: it reflects a high-core-count ARM instance with multiple I/O threads and a particular payload. Don't quote it as a universal figure.

Three architectural changes drove the Valkey 8.0 leap (Valkey 8.0 RC1, Aug 2024):

• Asynchronous I/O multithreading — offloads socket reads, writes, and command parsing (including epoll_wait handling) to I/O threads, freeing the main thread for command execution.
• Per-slot dictionaries — in cluster mode, each hash slot gets its own dictionary instead of one shared linked structure, cutting roughly 16 bytes per key-value pair and improving cache locality.
• Dual-channel replication — streams the RDB snapshot and the replication backlog in parallel over two channels, reducing full-sync time by up to 50%.

Valkey 8.1 (April 2, 2025) pushed efficiency further: memory dropped by about 20 bytes per key-value pair without a TTL and 30 bytes with one, TLS connection-accept throughput rose roughly 300%, SET and GET over TLS improved ~10% and ~22%, and BITCOUNT gained an AVX2-accelerated path measured at +514% (Valkey 8.1 GA). Independent benchmarking corroborates the throughput claims — Momento measured Valkey 8.1.1 at roughly 1M SET RPS on a c8g.2xlarge with sub-millisecond p99 latency.

Metric (c7g.16xlarge, 8 I/O threads)

Valkey 7.2 baseline

Valkey 8.0

Throughput (RPS)

~360K

~1.19M (+230%)

Memory per KV (cluster)

baseline

−16 bytes

Full-sync time

baseline

up to −50%

Redis 8 is no slouch — it shipped its own performance work and the bundled query engine — but the multithreaded I/O path and per-slot memory model give Valkey a clear, independently verified edge on high-core-count hardware. For latency-sensitive, high-throughput workloads, that gap is worth benchmarking on your own instance types.

How do the module and ecosystem stories differ?

This is the sharpest architectural divergence. Redis 8 folded the former Redis Stack modules directly into the core server: native JSON, time series, five probabilistic structures (Bloom, Cuckoo, Count-Min Sketch, Top-K, t-digest), vector sets, and the Redis Query Engine (the former RediSearch) — all shipping in-core under the tri-license (Redis, 2025).

Valkey took the opposite path: it keeps the core lean and ships equivalent capabilities as separate, BSD-licensed modules in the Valkey Bundle — valkey-search (vector and secondary indexing), valkey-json, valkey-bloom, and valkey-ldap, with modules reaching GA through the 8.1 and 9.0 cycles. One philosophy bundles everything into a single binary; the other keeps a minimal core you extend deliberately.

For client compatibility, this distinction mostly doesn't matter — standard RESP clients work against both servers because the protocol is shared. Where it matters is module-specific clients and query syntax: if you depend on RediSearch query features or RedisJSON path semantics, validate that the corresponding Valkey module matches the behavior you rely on, since they're now independently maintained codebases.

Which platforms have adopted Valkey?

Adoption moved fast, led by the cloud providers most affected by the license change. AWS added Valkey to both ElastiCache and MemoryDB in October 2024, with a zero-downtime in-place upgrade path from Redis 7.2 — and priced it below the Redis-compatible option (AWS, Oct 2024). Google Cloud added Valkey to Memorystore, and Oracle ships it on OCI.

The community numbers reflect that backing. By its first anniversary, Valkey had passed 100 million+ Docker pulls and drawn 150+ contributors from 50+ organizations including Google, Oracle, AWS, Ericsson, ByteDance, Aiven, and Percona (AWS, 2025). On the distribution side, Fedora, Debian, and Ubuntu moved their default in-memory data store package to Valkey, which means a large share of new Linux deployments now get Valkey by default rather than Redis.

For teams running their own infrastructure, the deployment story for Valkey and Redis is effectively identical — same config file format, same ports, same operational tooling. If you're standing up either on managed servers, a platform that provisions and manages your data store removes most of the day-two operational burden regardless of which engine you pick.

Should you migrate from Redis to Valkey?

The decision usually comes down to three factors: licensing, version, and feature dependency. If you need a permissive open-source license — for distribution, for compliance, or to avoid the source-available restrictions — Valkey (BSD-3) or Redis 8 under AGPLv3 both qualify, where the older RSALv2/SSPLv1-only releases do not.

If you're on Redis 7.2 or earlier and want the performance gains, Valkey 8.x is a low-risk upgrade: the wire protocol is identical, your clients don't change, and the RDB/AOF files load natively. If you depend on the bundled Redis 8 modules with their exact query semantics, weigh whether the Valkey module equivalents cover your use cases before committing. And if you're already on Redis 7.4+, remember that file-level migration to Valkey no longer works — plan a logical or replication-based path.

Frequently Asked Questions

Is Valkey a drop-in replacement for Redis?

For most workloads, yes. Valkey forked from Redis 7.2.4 and uses the identical RESP2/RESP3 protocol, so existing clients connect without code changes and RDB/AOF files from Redis 7.2 load natively (Valkey, 2025). The exceptions are commands added after the fork and the bundled Redis 8 modules, which you should validate per version.

Can Valkey read Redis RDB files?

Valkey reads RDB and AOF files compatible with Redis OSS 7.2 (RDB version 11). However, RDB files written by Redis CE 7.4 and later are not compatible with Valkey, because the on-disk format diverged after the 7.2.4 fork point (Valkey migration docs).

Is Valkey faster than Redis?

On high-core-count hardware, Valkey 8.0 showed roughly a 230% throughput gain over the 7.2 baseline — up to ~1.2M RPS on a c7g.16xlarge with 8 I/O threads (Valkey, Sept 2024). The gains come from async I/O threading and per-slot dictionaries. Always benchmark on your own instance types, since the figures are hardware-specific.

Do I need different client libraries for Valkey?

No. Because the wire protocol is identical to Redis, standard Redis client libraries — redis-py, ioredis, Jedis, go-redis, and others — work against Valkey unchanged. Dedicated Valkey clients exist but are optional; the protocol compatibility is what matters (Valkey protocol spec).

Is Redis still open source in 2026?

Yes, again. Redis added AGPLv3 as a license option starting with Redis 8 in May 2025, making it open source under OSI-approved terms alongside the source-available RSALv2 and SSPLv1 options (Redis, May 2025). Releases between 7.4 and 8 were source-available only.

Conclusion

Valkey and Redis remain remarkably compatible where it counts most — the RESP wire protocol is byte-identical, and your client code, monitoring, and proxies carry over with zero changes. The real divergence lives at two layers: the command set, which grows apart with each release past 7.2.4, and the on-disk RDB format, which is interoperable only at the Redis 7.2 baseline and breaks for Redis 7.4+ files.

For teams on Redis 7.2 or earlier, Valkey 8.x is a fast, low-risk upgrade with a genuine, independently verified performance edge. For teams on Redis 7.4+, migration is still very doable — it just requires a logical or replication-based path rather than a file copy. Either way, benchmark on your own hardware, pin to specific versions when you test command and module behavior, and snapshot both sides before you cut over.

Sources: *Valkey — Migration from Redis · Valkey — Protocol spec · Valkey 8.0 RC1 · Valkey — 1M RPS · Valkey 8.1 GA · Redis — AGPLv3 · Redis — What is Valkey · Percona — Redis license change · AWS — Year One of Valkey. Retrieved 2026-06-16.*