The Redis project moved from the BSD license to the SSPL and RSALv2 in March 2024. This decision prompted AWS, Google Cloud, Oracle, and Ericsson to fork Redis 7.2.4 and create Valkey under the Linux Foundation. Redis added the AGPLv3 as a third option in May 2025. I see this as a cycle where companies attempt to restrict cloud providers, lose to community forks, and then eventually return to open licenses. The pattern of companies changing licenses to prevent cloud providers from reselling their code, seeing a community fork emerge, and then eventually reverting to open licenses repeats across the software industry for several years.
Technical performance differences
Performance remains a primary consideration for engineers selecting an in-memory data store. Valkey and Redis share a similar architecture, including in-memory storage, a key-value model, and replication capabilities. However, the performance of Valkey changed significantly following its rearchitecture of I/O threads.
In Valkey 7.2.13, 8 MB values produced 21 Gbps on reads and 23 Gbps on writes. Valkey 8.1.8 improved these numbers to 33 Gbps for reads and 137 Gbps for writes. Valkey 9.0 changed the way the system handles large objects by passing a reference to the I/O threads instead of copying the entire object into a connection reply buffer. This change resulted in 8 MB reads reaching 200 Gbps and 8 MB writes reaching 134 Gbps. Valkey 9.1 further improved 8 MB writes to 166 Gbps.
For smaller objects, the improvements are also visible. Valkey 8.1.8 increased 1 MB read throughput from 32 Gbps to 183 Gbps. Valkey 9.0 increased 1 MB read throughput to 201 Gbps. Valkey 9.1 increased 1 MB write throughput to 201 Gbps. These benchmarks show that Valkey is a fast option for high-throughput workloads.
| Feature | Valkey | Redis |
|---|---|---|
| Open Governance | Yes | Limited |
| Community Driven | Yes | Partial |
| Redis Protocol Compatible | Yes | Native |
| Existing Ecosystem | Growing | Mature |
| Migration Complexity | Low | N/A |
| Enterprise Adoption | Growing | Extensive |
| Tool Compatibility | High | Native |
The Snap migration experience
Snap used KeyDB for its caching infrastructure for two years. KeyDB provided multithreaded command execution and zone-aware read routing. It also provided forkless background saves and same-zone replica behavior. Snap acquired the team behind KeyDB in May 2022 and moved KeyDB Pro features into the open source codebase.
The decision to move away from KeyDB happened in 2025. The creator of KeyDB left the company in January 2025 and stated that development efforts should move to Valkey because it has momentum. Snap migrated its workloads to Valkey using a RESP proxy layer. This abstraction layer allowed the team to migrate 30 caches per week without requiring application changes.
The migration was not without friction. Snap performed a gap analysis and found that KeyDB supported the MGET command across slots, while Valkey does not. This discrepancy caused command parsing pressure for Snap in large batching workloads. Snap had to port a custom cross-slot MGET to its internal build to resolve the issue. You should verify that your specific command usage is supported by the fork before you commit to a migration.
License change cycles
The history of open source shows a recurring pattern of license shifts. In 2018, MongoDB moved from AGPL to SSPL. In 2021, Elastic moved Elasticsearch from Apache-2.0 to a model using SSPL and the Elastic License, then added AGPLv3 in 2024. In 2023, HashiCorp moved Terraform to BSL 1.1, which led to the creation of OpenTofu. IBM acquired HashiCorp in February 2025.
The pattern of companies changing licenses to prevent cloud providers from reselling their code, seeing a community fork emerge, and then eventually reverting to open licenses repeats across the software industry for several years. This occurs when a single company controls a project rather than a foundation. When a cloud provider sells that software as a service without making substantial development contributions, the company often seeks a new license to capture more revenue.
The market remains split. A huge, free half of the market uses permissive licenses, while a smaller, expensive half captures profit through managed services. Companies like MongoDB and Elastic have found that they can grow by selling the managed service even while the core project remains under a restrictive license. However, the rise of forks like OpenSearch and OpenTofu shows that the community can create viable alternatives.
Cloud service costs
Cloud providers provide managed versions of these databases to reduce operational pain. AWS offers ElastiCache Serverless for Valkey. For a 10 GB dataset with 50,000 requests per second, the total hourly charge is $1.254. This includes $0.84 for data storage and $0.414 for ECPU usage.
For an application with spiky traffic that reaches 1 million requests per second and 100 GB of data, the serverless cost is $2.919 per hour. This calculation includes $1.47 for data storage and $1.449 for ECPUs. If you choose on-demand nodes for this same workload, the cost is higher. A cluster of 12 nodes using r7g.xlarge instances costs $4.1952 per hour. After adding $1.46 for data transfer, the total cost for on-demand nodes is $5.6552 per hour.
Memcached also remains an option for simple caching. For a 20 GB idle dataset that grows to 150 GB during peaks, a serverless Memcached setup costs $5.48 per hour. This includes $3.85 for data storage and $1.63 for ECPUs. An on-demand cluster of 14 nodes for Memcached costs $8.36 per hour. This includes $6.12 for node charges and $2.24 for data transfer.
Governance and foundations
The governance model is a main reason organizations choose Valkey over Redis. Valkey is a community-driven project under the Linux Foundation. It has a Technical Steering Committee with members from multiple companies. This structure ensures that no single vendor controls the roadmap.
Redis is managed by Redis Ltd. This means the company makes the decisions regarding the codebase and the license. While Redis has added the AGPLv3 to its licensing menu, the company still maintains control. In contrast, the Valkey project is built on the idea that the community should drive development.
The Linux Foundation provides a neutral home for projects. This neutrality is important for cloud providers that want to contribute to a project without fearing that a single vendor will change the terms. This model helps prevent the kind of conflict seen with the NATS project and the CNCF. When a project is under a foundation, it is much harder for a single company to pull it back into private control.
Maintainer economics
The sustainability of open source relies on people who often do not get paid. Tidelift measured that 60% of open source maintainers do not receive any payment for their work. This figure has remained unchanged in 2021, 2023, and 2024. Most of these developers work alone. Specifically, 61% of unpaid maintainers work without a second person to cover for them.
The workload is highly concentrated. According to the Linux Foundation’s Census II, 136 developers write more than 80% of the code in the 50 most-used open source packages. A Harvard study found that 5% of developers produce 96% of the value generated by open source. If these developers stop working, the cost to replace them would be $8.8 trillion.
The industry is testing new ways to fund these individuals. Some suggest using the registry as a point of payment. This would involve charging companies a fee when they download a package through registries like npm or PyPI. However, registries are often small foundations or companies that do not have the budget to act as regulators. For now, companies continue to rely on voluntary donations and corporate sponsorships.
Operational considerations
Managing an in-memory database requires careful planning. Users must monitor RAM consumption because data is stored in memory. It is also necessary to design consistent key naming to improve maintainability.
When choosing between Valkey and Redis, evaluate the following:
| Feature | Valkey | Redis |
|---|---|---|
| Open Governance | Yes | Limited |
| Community Driven | Yes | Partial |
| Redis Protocol Compatible | Yes | Native |
| Existing Ecosystem | Growing | Mature |
| Migration Complexity | Low | N/A |
| Enterprise Adoption | Growing | Extensive |
| Tool Compatibility | High | Native |
For most applications, such as session management or API caching, performance differences are unlikely to be noticeable. The decision usually rests on governance and long-term strategy. If you value community control, Valkey is the logical choice. If you rely on existing third-party integrations and operational expertise, Redis is the standard.
You should check the specific version of your components before you assume the license remains unchanged. Internal use without redistribution triggers no disclosure obligation for AGPL. For services provided to third parties that include your own modifications, you must review the terms. Will the industry eventually move away from proprietary managed services as the market for open-source distributions grows?
