In March 2024, Redis dropped the BSD licence and switched to SSPL and RSALv2. Within months, enterprises were moving in serious numbers. Aiven shifted thousands of Redis servers to Valkey. MaiCoin completed a blue/green migration of their cryptocurrency exchange in weeks.
Legal departments started flagging compliance risks. Finance teams saw vendor lock-in issues—but also potential cost savings of 20-33% by switching to managed Valkey services.
The Linux Foundation launched Valkey in April 2024, with backing from AWS, Google Cloud, and Oracle. Within weeks, the fork had established itself as a real alternative—150+ contributors, 1000+ commits, and production-ready releases that maintained full Redis protocol compatibility.
This article is part of our comprehensive guide on open source licensing wars, where we examine how companies like Redis and HashiCorp are responding to cloud provider competition through restrictive licensing—and how the open source community is fighting back through governance and forks.
This article digs into why Redis Inc changed its licensing, how the community responded, what the performance benchmarks show, and what migration decisions you need to make.
Jump to: License Change Motivations | Performance Comparison | Migration Checklist
Why Did Redis Change Its License from BSD to SSPL in March 2024?
Redis Inc changed from BSD to SSPL and RSALv2 in March 2024 because cloud providers like AWS ElastiCache were making money from Redis without contributing anything back. The company had a “1% conversion problem”—only 1% of Redis users ever became paying Redis Enterprise customers, while AWS captured all the infrastructure revenue. The licensing change was designed to stop cloud providers from offering Redis as a managed service without paying up.
Understanding the full context of open source license types helps clarify why Redis Inc viewed SSPL as their best option—and why the community saw it as a betrayal of open source principles.
The AWS ElastiCache Revenue Threat
AWS ElastiCache was generating hundreds of millions in revenue while Redis Inc struggled to make money. Out of millions of Redis users, only 1% converted to Redis Enterprise customers.
The economics weren’t working. Cloud providers built thriving businesses on BSD-licensed Redis without needing to licence anything from Redis Inc. The company needed a different approach.
This dynamic represents the core of the cloud provider freeloading debate, where maintainers argue cloud providers exploit open source projects while cloud providers counter that they provide infrastructure value and customer access.
What Redis Inc Announced
On March 20, 2024, Redis Inc announced an immediate licence change. Redis would now use dual licensing: SSPL for core Redis and RSALv2 for modules like Redis Stack, RedisJSON, RediSearch, and RedisBloom.
The target was explicit—stop cloud providers from offering “Redis as a Service” without licensing fees. Redis Inc said self-hosted Redis users weren’t affected, only “service providers” were in the firing line.
But a 15-year BSD licence doesn’t just disappear without breaking trust.
Community Immediate Reaction
SSPL isn’t OSI-approved, which meant Redis wasn’t truly open source anymore by the standard definition. You don’t revoke a 15-year BSD licence without consequences.
AWS, Google Cloud, and other providers started evaluating fork possibilities within days. Community discussions showed opposition to what many saw as a licensing “bait and switch.”
Enterprise legal departments flagged compliance risk. Procurement froze Redis upgrades while lawyers reviewed the new terms.
What Is the SSPL License and Why Is It Controversial?
The Server Side Public Licence (SSPL) requires anyone offering software as a service to open source their entire infrastructure stack—including proprietary tools, monitoring systems, and orchestration code. The Open Source Initiative rejected it as not meeting the Open Source Definition, making SSPL-licensed software “source available” rather than truly open source. Cloud providers see SSPL as specifically designed to make managed services commercially impossible unless they pay licensing fees.
For a deeper exploration of how SSPL differs from traditional open source licenses like BSD, Apache, and GPL, see our complete guide to open source licenses.
SSPL Technical Requirements
MongoDB created SSPL in October 2018. Section 13 requires service providers to release “all programs that you use to make the Program available as a service.” That includes load balancers, monitoring tools, orchestration systems, backup utilities, and networking configurations.
The practical impact? It would require AWS to open source ElastiCache infrastructure. That’s commercially impossible for cloud providers.
The compliance complexity is serious. The ambiguous language about what constitutes “making available as a service” creates legal uncertainty. Does providing Redis to internal teams count?
Why OSI Rejected SSPL
In 2018, MongoDB submitted SSPL to the Open Source Initiative for approval. The OSI rejected it. Bruce Perens explained: “Section 13 is very obviously intended to be a restriction against the field of endeavour of offering the software as a service”, violating OSD Principle #6.
SSPL adds restrictions beyond source code availability. That makes it “source available” not open source by the OSI definition. This distinction matters—open source means freedom to use software for any purpose. SSPL restricts that freedom specifically to extract revenue from cloud providers.
Enterprise Compliance Concerns
Enterprises now need legal review before upgrading Redis. Self-hosted Redis is theoretically unaffected, but the uncertainty about what “service” means creates risk.
Many enterprises chose migration to BSD-licensed Valkey rather than ongoing legal review. The risk mitigation strategy was simple—avoid SSPL entirely.
How Did the Linux Foundation Create Valkey as a Redis Fork?
The Linux Foundation announced Valkey on April 1, 2024, as a BSD-licensed fork of Redis 7.2, with backing from AWS, Google Cloud, and Oracle. The project established neutral governance through a Technical Steering Committee, preventing single-vendor control while maintaining full Redis protocol compatibility. Within weeks, Valkey achieved 50+ contributing companies, 150+ individual contributors, and 1000+ commits—rapid community mobilisation.
Valkey’s governance structure exemplifies the community-governed open source model that prevents single-vendor control and ensures long-term project sustainability—a critical factor in fork viability.
Timeline of Fork Formation
March 20, 2024: Redis announced the licensing change. Within days, AWS, Google Cloud, and Oracle coordinated fork strategy. By April 1, 2024, the Linux Foundation announced Valkey.
The first Valkey release (7.2.5) arrived mid-April, achieving protocol parity with Redis. By May 2024, cloud providers announced managed Valkey support roadmaps. In June 2024, Valkey 7.2.6 shipped with AWS’s Async I/O Threading contribution, enabling 3x throughput improvement.
Linux Foundation Governance Model
No single company controls Valkey direction. The Technical Steering Committee ensures balanced decision-making with multi-company representation.
Madelyn Olson, Valkey project lead, emphasised: “All the meetings are public. If we ever see people trying to host private meetings, we will force them to cancel them and make them public.” This transparency was a direct response to Redis Inc’s opaque governance.
The Linux Foundation owns the “Valkey” trademark, preventing hijacking.
Why Enterprises Trust Valkey
It’s a drop-in replacement for Redis 7.2—no code changes required. Performance benchmarks show equivalent or better performance versus Redis. Managed services from AWS, Google, Azure, and Oracle remove operational burden.
The BSD licence provides legal clarity versus SSPL ambiguity. And cloud provider support matters—if AWS, Google, and Oracle are backing Valkey, enterprises can trust it’s not disappearing.
Which Cloud Providers Support Valkey?
AWS ElastiCache, Google Cloud Memorystore, Microsoft Azure Cache, and Oracle Cloud Infrastructure all provide managed Valkey support. AWS contributed major performance improvements including Async I/O Threading (3x throughput gain) and offers Valkey in ElastiCache with 20% cost savings versus Redis.
AWS ElastiCache for Valkey
Valkey became available in ElastiCache in June 2024 across all major AWS regions. AWS contributed the Async I/O Threading model that delivered 3x throughput improvement. ElastiCache Valkey pricing runs 20% lower than equivalent Redis instances.
Google Cloud Memorystore
Google Cloud announced Valkey support in Memorystore in May 2024, with general availability in Q3 2024. Google positioned Valkey as the standard Redis-compatible option across their multi-cloud strategy.
Cost Comparison
AWS ElastiCache cache.m6g.large instances: $0.034/hr for Redis, $0.027/hr for Valkey—20% savings. Google Memorystore: $0.054/GB-hour for Redis, $0.043/GB-hour for Valkey—20% reduction.
For enterprises running large Redis deployments, 20% savings represents serious budget impact.
Redis vs Valkey Performance – Which Is Faster?
Independent benchmarks by Momento show Valkey 7.2.6 delivers 37% higher SET throughput and 16% higher GET throughput compared to Redis 8.0, with 30% better tail latency (p99). AWS’s Async I/O Threading contribution to Valkey enables nearly 1 million requests per second on 8-vCPU instances—3x improvement over the single-threaded model.
Momento Independent Benchmarks
Momento’s engineering team ran benchmarks in July 2024 using isolated AWS c7gn.2xlarge instances (8 vCPU, 16 GB RAM) with memtier_benchmark tool.
Results showed Valkey at 673k ops/sec for SET versus Redis at 491k ops/sec. GET operations: Valkey achieved 982k ops/sec versus Redis at 847k ops/sec—16% improvement.
Tail latency matters for user experience. Valkey’s p99 latency was 0.7ms versus Redis’s 1.0ms—30% better.
AWS Async I/O Threading Performance Impact
The Async I/O Threading architecture separates network I/O from command processing. Network I/O gets handled by dedicated threads while command execution runs on separate cores.
Without I/O threads, Valkey showed 239K RPS on SETs. With 6 threads: 678K RPS. P99 latencies dropped from 1.68ms to 0.93ms despite handling nearly 3x the throughput.
This feature is available in Valkey 7.2.6 and later, but not in Redis 8.0. That’s a competitive advantage for Valkey.
Real-World Performance Validation
MaiCoin validated that Valkey met their latency requirements for their cryptocurrency exchange. Aiven ran thousands of servers in production without performance degradation. AWS and Google Cloud offer the same performance guarantees for Valkey as Redis in their managed services.
How Fast Did Enterprises Migrate to Valkey After the Fork?
Aiven migrated 15,000 Redis servers to Valkey (11,000 automated, 4,000 user-initiated), while MaiCoin completed blue/green migration of its cryptocurrency exchange in weeks. The rapid adoption was enabled by drop-in Redis protocol compatibility, managed cloud services, and migration tools minimising downtime.
Aiven 15,000 Server Migration
Aiven completed the largest documented Redis to Valkey migration—15,000 servers over three months from May to August 2024. The approach split between 11,000 servers using automated migration tooling and 4,000 through user-initiated opt-in.
The migration achieved zero-downtime using replication-based migration with REPLICAOF. No performance degradation occurred. Aiven passed 20% cost savings to customers on Valkey instances.
MaiCoin Blue/Green Migration
MaiCoin runs a cryptocurrency exchange requiring 24/7 uptime. Their migration strategy used parallel Redis and Valkey environments with gradual traffic cutover. Testing took 2 weeks with synthetic production traffic. Cutover was percentage-based over 48 hours.
Results: zero customer-facing downtime, latency requirements maintained.
If you’re evaluating a migration, our migration and risk assessment playbook provides a systematic framework for assessing immediate risk, deciding whether to migrate or stay, and executing migrations without breaking production systems.
Why Migration Happened So Fast
Drop-in compatibility meant no code changes required. Cloud provider support through ElastiCache and Memorystore provided managed migration paths. Legal urgency from SSPL compliance risk motivated quick migration.
Migration tools like RedisShake reduced technical barriers. Performance benchmarks confirmed no performance penalty. And 20% cloud cost savings provided CFO-level motivation.
Is Your Redis Deployment Affected by the License Change? Compliance Checklist
Your Redis deployment is affected by the SSPL licence change if you run Redis 7.4 or later and offer it as a service to external customers, whether free or paid. Self-hosted Redis for internal company use theoretically remains unaffected, but the legal ambiguity about “offering as a service” creates compliance risk.
For a comprehensive decision framework beyond just Redis, see our migration and risk assessment playbook covering both Redis to Valkey and Terraform to OpenTofu evaluations.
Compliance Decision Tree
Step 1: Check Your Redis Version
Redis 7.2.x and earlier remain BSD-licensed—no SSPL restrictions apply. Redis 7.4.x and later use SSPL/RSALv2 licensing.
Staying on Redis 7.2.x avoids SSPL but misses security updates post-March 2024. You’ll need to self-patch vulnerabilities.
Step 2: Identify Your Deployment Model
Self-hosted (internal): Running Redis on your own infrastructure for internal applications. Managed service (customer-facing): Offering Redis as a service to external customers. SaaS component: Redis powers your SaaS product used by external customers.
Step 3: Assess “Offering as a Service” Risk
Clear SSPL violation: Offering managed Redis to external customers makes you a competitor to Redis Inc. Grey areas include internal developer platforms providing Redis to internal teams, SaaS products using Redis as a backend component, and multi-tenant applications with Redis shared across customer workloads.
Step 4: Evaluate Your Options
- Migrate to Valkey: Eliminates compliance risk, maintains Redis compatibility
- Stay on Redis 7.2.x: Avoids SSPL but forgoes updates (security risk)
- Licence Redis Enterprise: Pay Redis Inc for commercial licence
- Seek Legal Opinion: Have counsel interpret SSPL for your specific deployment
When to Migrate vs Stay
Migrate to Valkey if your legal department flags SSPL compliance risk, you value open source guarantees, you want 20% cloud cost savings, you prefer community-governed projects, or you anticipate future Redis licensing changes.
Consider staying on Redis if you have a Redis Enterprise relationship with Redis Inc, your deployment clearly qualifies as internal use only, you need specific Redis Enterprise features not in Valkey, or migration effort exceeds compliance risk.
Cloud Provider Managed Service Users
AWS ElastiCache Redis: AWS handles compliance; you’re not “offering service,” you’re consuming it. Google Memorystore Redis: Same logic—Google’s licence relationship covers your usage.
Managed service users generally aren’t affected. Providers handle licensing relationships.
What’s Next for Valkey – Roadmap and Long-Term Viability
Valkey’s roadmap includes continuing Redis 7.x feature parity, implementing community-driven enhancements like improved Async I/O, and maintaining protocol compatibility while diverging on proprietary Redis Enterprise features. The project has demonstrated long-term viability with 150+ contributors, 1000+ commits in first six months, 5M+ Docker pulls, and sustained backing from AWS, Google Cloud, and Oracle.
The project’s governance structure and multi-company backing exemplify the principles we explore in our guide to open source governance models—showing how proper governance prevents vendor control and ensures long-term sustainability.
Valkey Development Metrics
150+ individual contributors from diverse organisations contributed in the first six months. 1000+ commits since April 2024 show active development. 5M+ Valkey Docker image downloads indicate adoption. 19.8K GitHub stars show community interest.
Technical Roadmap
Maintain Redis 7.x protocol compatibility. Continue Async I/O Threading optimisation, explore DPDK integration for performance improvements. Implement frequently requested features Redis Inc deprioritised.
The divergence strategy maintains protocol compatibility but doesn’t force feature parity with proprietary Redis Enterprise.
Governance Sustainability
The Linux Foundation model provides proven governance structure. Technical Steering Committee ensures multi-company decision-making prevents single-vendor capture. Linux Foundation owns the Valkey trademark.
No single company dominates contributions. AWS contributes approximately 30%, other organisations 70%. That distribution prevents single-vendor control.
Cloud Provider Commitment
AWS shows long-term commitment to Valkey in ElastiCache. Google Cloud positions Memorystore Valkey as standard Redis-compatible offering. Microsoft Azure added Valkey support in 2024.
No cloud provider maintains dual Redis/Valkey support, suggesting Valkey as the primary path forward.
What Could Derail Valkey
Fragmentation risk if the community splits on direction is mitigated by governance structure. If Redis Inc reverted to BSD, some enterprises might return—unlikely given AGPLv3 Redis 8.0.
Risk assessment: Low. Linux Foundation governance and multi-company backing provide stability.
For a complete understanding of the broader open source licensing crisis, including how this pattern emerged from MongoDB to Redis and what might come next, explore our comprehensive content hub on infrastructure licensing wars.
FAQ
Can I use Redis 7.2 indefinitely without migrating?
Yes, Redis 7.2.x remains BSD-licensed and can be used indefinitely. However, Redis Inc stopped providing security updates for Redis 7.2 after March 2024, so you’ll need to self-patch vulnerabilities or migrate to Valkey (which continues Redis 7.2.x security support).
Will Valkey support Redis Cluster?
Yes, Valkey fully supports Redis Cluster mode for horizontal scaling across multiple nodes. Cluster functionality is part of Redis 7.2 protocol compatibility that Valkey maintains.
What Redis Enterprise features are missing from Valkey?
Valkey doesn’t include proprietary Redis Enterprise features like Active-Active Geo-Distribution, Redis on Flash (RoF), or Auto-Tiering. However, cloud providers offer equivalent features through their managed services (for example, AWS Global Datastore for ElastiCache).
How do I join the Valkey community?
Join Valkey development through GitHub (github.com/valkey-io/valkey), participate in monthly community calls, join the #valkey channel on CNCF Slack, or subscribe to the valkey-dev mailing list.
Does Valkey work with existing Redis client libraries?
Yes, all Redis client libraries (redis-py, node-redis, Jedis, StackExchange.Redis, etc.) work with Valkey without modification due to full Redis protocol compatibility. Simply change the connection string to point to Valkey endpoint.
Is Valkey slower than Redis because it’s a fork?
No, independent benchmarks show Valkey performs 16-37% faster than Redis 8.0 on key operations. Forks can outperform originals when the community contributes optimisations like AWS’s Async I/O Threading (3x throughput improvement).
What’s the difference between Valkey and KeyDB?
KeyDB is a separate Redis fork (created 2019) focused on multithreading. Valkey is newer (2024), has broader ecosystem backing (Linux Foundation, AWS, Google), and aims for protocol compatibility while adding community-driven features. Both are BSD-licensed Redis alternatives.
Does Valkey support Redis modules like RedisJSON?
Valkey supports Redis modules that are open source. RedisJSON, RediSearch, and other modules changed to RSALv2 (proprietary) and aren’t compatible with Valkey. The community is developing open source alternatives for popular module functionality.
How much does it cost to migrate to Valkey?
Migration cost depends on approach. Replication-based migration costs minimal downtime (seconds to minutes). Managed service migrations (ElastiCache, Memorystore) often have zero migration cost and offer 20% ongoing savings. Self-managed migrations require engineering time for testing and execution.
