Valkey isn’t just a fork of Redis; it’s a deliberate divergence aiming to preserve the open-source spirit that many felt was threatened.
Let’s see Valkey in action, not as a theoretical concept, but as a running service. Imagine this simple redis-cli session, now connected to a Valkey instance:
$ valkey-cli
valkey [127.0.0.1:6379]> SET mykey "hello valkey"
OK
valkey [127.0.0.1:6379]> GET mykey
"hello valkey"
valkey [127.0.0.1:6379]> INFO memory
# Memory
used_memory:123456
used_memory_human:117.75K
...
This familiar interaction highlights the immediate compatibility for basic operations. The core functionality you’re used to is there, but the underlying motivations and future trajectory are what set Valkey apart.
The primary problem Valkey solves is the perceived shift in Redis’s licensing and governance. Redis Labs (now Redis Ltd.) introduced a dual-licensing model with Redis 7.4, offering a source-available license (RSALv2/SSPLv1) alongside a commercial license. This move was seen by many in the community as a departure from the fully open-source ethos that had fostered Redis’s growth. Valkey, initiated by the Linux Foundation and a consortium of companies, aims to provide a truly open-source alternative, governed by a community-driven model, ensuring continued free and open development.
Internally, Valkey inherits the robust architecture of Redis. It’s an in-memory data structure store, used as a database, cache, and message broker. It supports various data structures like strings, hashes, lists, sets, sorted sets, bitmaps, hyperloglogs, and geospatial indexes. Its core performance relies on its single-threaded, event-driven architecture, which uses an I/O multiplexing mechanism (like epoll or kqueue) to handle multiple client connections efficiently without the overhead of thread creation and context switching. Valkey retains this fundamental design, ensuring high throughput and low latency for common operations.
The key levers you control in Valkey, much like Redis, revolve around configuration and command usage. Configuration parameters in valkey.conf (or equivalent) dictate memory limits (maxmemory 4gb), persistence strategies (RDB snapshots via save 900 1, save 300 10, save 60 1000; AOF logging via appendonly yes), replication (replicaof <masterip> <masterport>), and network settings. On the command side, you leverage its rich command set for data manipulation (GET, SET, HSET, LPUSH, SADD, ZADD), managing server state (INFO, CONFIG GET *), and enabling advanced features like Pub/Sub (PUBLISH, SUBSCRIBE).
The most surprising true thing about Valkey’s genesis is that the fork wasn’t driven by a single technical flaw or a missing feature in Redis’s latest releases. Instead, it was a proactive response to a perceived shift in the project’s governance and licensing strategy, aiming to safeguard the future of a truly open-source, community-managed data store. This is why many of the core commands and performance characteristics remain identical, allowing for a relatively seamless transition for users who prioritize an open-source license and community stewardship.
The next conceptual hurdle for users migrating or adopting Valkey will be understanding how the community governance model impacts the release cycle and feature roadmap compared to a commercial entity’s direction.