Valkey forked from Redis because the Redis open-source project’s licensing changes and governance model were perceived by many contributors as a departure from its original open-source ethos.
Let’s see Valkey in action. Imagine a simple key-value store scenario. We’ll use redis-cli (which will work with Valkey as well, given the compatibility) to demonstrate.
First, start a Valkey server. If you’ve built Valkey from source, you’d run:
./src/valkey-server
If you’re using a pre-built package, it might be:
valkey-server
Now, open another terminal and connect to it:
./src/redis-cli
# or if installed system-wide
redis-cli
Inside redis-cli, you can perform basic operations:
127.0.0.1:6379> SET mykey "hello valkey"
OK
127.0.0.1:6379> GET mykey
"hello valkey"
127.0.0.1:6379> INCR counter
(integer) 1
127.0.0.1:6379> INCR counter
(integer) 2
127.0.0.1:6379> HSET user:1 name "Alice" age 30
(integer) 2
127.0.0.1:6379> HGETALL user:1
1) "name"
2) "Alice"
3) "age"
4) "30"
127.0.0.1:6379> QUIT
This shows the fundamental command-response mechanism, the core of what makes Redis (and now Valkey) so fast. It’s an in-memory data structure store, meaning all data resides in RAM, allowing for sub-millisecond latency on typical operations. The commands are simple, text-based protocols, making clients easy to implement.
The problem Valkey aims to solve, or rather, continue solving in the spirit of its origins, is providing a high-performance, flexible data store that remains truly open-source. Redis, under its previous BSD license, was a popular choice for many applications due to its speed, versatility (supporting strings, lists, sets, sorted sets, hashes, bitmaps, hyperloglogs, streams, and geospatial indexes), and robust feature set. It could be used as a cache, a message broker, a database, and more.
Internally, Valkey operates on a single-threaded event loop for command processing, which is key to its performance. This avoids the overhead of context switching and complex locking mechanisms that plague multi-threaded approaches for I/O-bound tasks. However, it does use background threads for operations that might block the main thread, like disk persistence (RDB snapshots and AOF rewrites) or slow I/O operations. When a command arrives, it’s added to an event queue. The single thread processes these events, reads the command, executes it against the in-memory data structures, and writes the reply back to the client. Replication and clustering are handled via separate processes or connections, managed to not block the primary event loop.
The fork occurred because Redis Labs (now Redis Ltd.) announced a change in licensing for Redis, moving from the permissive BSD 3-clause license to the RSALv2/SSPLv1 dual license. This was a significant shift, as RSALv2 and SSPLv1 are considered non-open-source by many definitions, particularly for commercial use and for cloud providers offering Redis as a managed service. The community felt this move restricted the freedom to use, modify, and distribute Redis, especially for companies wanting to build services on top of it without becoming Redis Ltd. customers. The Valkey project was initiated by members of the open-source Redis community, including former core contributors and major companies that relied heavily on Redis, to ensure the continued availability of a truly open-source, community-driven version of the software.
A common misconception is that the fork was solely about cost or competition. While commercial implications were a major driver, the core issue was the perceived abandonment of open-source principles. The governance model also played a role; the community desired a more collaborative, open decision-making process for the project’s direction, which they felt was diminishing under the new licensing and corporate structure. Valkey aims to restore a more community-centric development and governance model, allowing for broader contributions and a clearer path for innovation that doesn’t hinge on a single vendor’s commercial strategy.
The next challenge for Valkey will be to attract and retain a diverse contributor base and to continue innovating while maintaining the high compatibility that users expect from a Redis fork.