{"id":410,"date":"2026-03-09T20:17:40","date_gmt":"2026-03-09T20:17:40","guid":{"rendered":"https:\/\/blog.rebalai.com\/en\/2026\/03\/09\/redis-vs-valkey-in-2026-why-the-license-change-for\/"},"modified":"2026-03-18T22:00:05","modified_gmt":"2026-03-18T22:00:05","slug":"redis-vs-valkey-in-2026-why-the-license-change-for","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/en\/2026\/03\/09\/redis-vs-valkey-in-2026-why-the-license-change-for\/","title":{"rendered":"Redis vs Valkey in 2026: What the License Fork Actually Changed"},"content":{"rendered":"

When Redis Ltd announced the license change in March 2024, I was in the<\/a> middle of planning a caching layer for a mid-sized SaaS product \u2014 four engineers, roughly 80k daily active users, nothing hyperscale but enough that infrastructure decisions have real consequences. My first reaction was basically: this is annoying, but probably fine.<\/em> I figured the open source community would grumble for a few weeks and move on.<\/p>\n

I was wrong. The fork that came out of it \u2014 Valkey, now a Linux Foundation project \u2014 turned out to be more interesting than I expected.<\/p>\n

Here’s I Actually Learned<\/a> After”>what I actually learned<\/a> after<\/a> running both in<\/a> staging, migrating one production service, and spending way too many evenings reading GitHub issues.<\/p>\n

March 2024: Why the SSPL Switch Was a Bigger Deal Than It Looked<\/h2>\n

Redis Ltd moved to dual-license Redis under RSAL (Redis Source Available License) and SSPL (Server Side Public License). Both sound fine until you notice that the Open Source Initiative does not consider SSPL an open source license. MongoDB used it first, and the controversy followed them too.<\/p>\n

The practical implication: any cloud provider building a managed Redis-compatible service would now need a commercial agreement with Redis Ltd. The old BSD license let them run Redis however they wanted. SSPL did not.<\/p>\n

So within weeks, Amazon, Google, Oracle, Ericsson, and others backed a fork. The Linux Foundation accepted it in<\/a> late March 2024. They called it Valkey \u2014 and started from Redis 7.2.4, the last version under the BSD license.<\/p>\n

What struck me was how fast this moved. Fork announcement, Linux Foundation acceptance, first release (7.2.5) \u2014 all within about two months. Compare that to the years-long drama around other high-profile forks. Someone had clearly been planning for this scenario before it was announced publicly.<\/p>\n

The right way to think about Valkey is not “Redis but free.” The governance model is genuinely different. Redis Ltd controls Redis. Valkey is steered by a Technical Steering Committee across multiple companies with no single controlling entity. Whether that matters depends on how much you care about vendor lock-in at the<\/a> infrastructure layer.<\/p>\n

Valkey Is Not the Same Project Anymore \u2014 and Neither Is Redis<\/h2>\n

I assumed Valkey would just track Redis feature-for-feature, staying compatible but staying behind. That’s not what happened.<\/p>\n

By late 2024, Valkey 8.0 shipped with meaningful performance work around I\/O threading. Redis had always had a reputation for being single-threaded on commands (even though I\/O threading was added in Redis 6.0), and Valkey’s team pushed further on that in 8.0. In my own synthetic benchmarks \u2014 8 CPU cores, mostly GET\/SET workloads with some sorted set operations \u2014 Valkey 8.0 was measurably faster than Redis 7.4 at high connection counts. Maybe 15-20% throughput improvement in the<\/a> scenarios I tested. Not nothing.<\/p>\n

The config that mattered:<\/p>\n

# valkey.conf \u2014 enable threaded I\/O (Valkey 8.x)\nio-threads 4\nio-threads-do-reads yes\n\n# This was available in Redis 6.0+ too, but Valkey's default\n# behavior and threading model changed in 8.0\n# Check your cpu count: don't set io-threads > (cpu_count - 1)\n<\/code><\/pre>\n
I’m not confident this scales beyond the specific workload I tested \u2014 scripting-heavy or transaction-heavy workloads behave differently. But the point stands: Valkey is making its own performance bets now, not just merging Redis commits.<\/p>\n
On the Redis side, and this genuinely surprised me: Redis 8 added vector set support and kept iterating on Redis Query Engine (the search\/vector work from the old RediSearch module). That’s real differentiation. If you’re building anything combining caching with vector<\/a> similarity search, Redis has a more integrated story than Valkey does right now.<\/p>\n
By early 2026, the two projects have genuinely diverged. Not dramatically \u2014 still about 90% compatible at the<\/a> command level \u2014 but enough that you can’t pick one on inertia alone.<\/p>\n
The Client Library Situation Nobody Warned Me About<\/h2>\n
This is where I hit an actual wall.<\/p>\n
I was migrating a Node.js service from ElastiCache (which AWS quietly switched to Valkey by default for new clusters in 2024) to self-hosted Valkey for cost reasons. Our client was ioredis<\/code>, which we’d used for years.<\/p>\n
I pushed the config change on a Friday afternoon. Forty minutes later, the service started throwing intermittent connection errors \u2014 not enough to page anyone, but enough to show up in<\/a> our error rate dashboard, which I happened to be watching for a completely unrelated reason. We rolled back. I spent the weekend reading ioredis GitHub issues and found the actual problem buried in a thread from mid-2025.<\/p>\n
The issue was how certain client libraries handled CLIENT INFO<\/code> and HELLO<\/code> commands during connection setup \u2014 version negotiation behavior that had diverged between Valkey 8.x and what<\/a> ioredis expected based on Redis 7.x behavior. Not exactly a Valkey bug, more of a “the ecosystem assumed Redis forever” problem. The fix existed in an ioredis release that had already shipped, but our lock file had pinned us to an older version.<\/p>\n
Check your client library’s Valkey compatibility explicitly, and check recent release notes before migrating.<\/strong> “Redis-compatible” does not mean “tested against Valkey 8.” Some libraries are explicit about this now; many aren’t.<\/p>\n
The managed service picture is cleaner. AWS MemoryDB and ElastiCache both support Valkey and handle client library abstraction for you. If you’re on a managed offering, the migration path is more straightforward than self-hosted.<\/p>\n
Where the Managed Services Landscape Settled<\/h2>\n
The cloud picture shifted more decisively than I expected.<\/p>\n
AWS made Valkey the default for new ElastiCache and MemoryDB instances in 2024. You can still choose Redis \u2014 they have a commercial agreement with Redis Ltd \u2014 but the default changed. That’s operationally significant: environments spun up from templates or Terraform modules defaulted to Valkey unless someone explicitly overrode it.<\/p>\n
Google Cloud Memorystore offers Valkey as well. Azure still has Azure Cache for Redis, backed by actual Redis under their own commercial arrangement. The big three have split: AWS and GCP leaning Valkey, Azure leaning Redis.<\/p>\n
Redis Insight (the GUI tool) works fine with Valkey \u2014 RESP protocol is shared, so most tooling in the<\/a> ecosystem still functions. The divergence shows up in<\/a> edge cases: specific command behaviors, module support, vector search.<\/p>\n
Which brings me to the most important decision factor right now. If you’re using Redis Modules heavily \u2014 RedisSearch, RedisJSON, RedisTimeSeries \u2014 your decision is mostly already made. Those are Redis Ltd products, not part of Valkey. Community-driven Valkey equivalents are emerging but aren’t at the<\/a> same maturity level yet.<\/p>\n
My Actual Recommendation<\/h2>\n
I thought about hedging this and decided not to.<\/p>\n
On managed AWS or GCP: use Valkey.<\/strong> The operational complexity is identical, the defaults are already pointing there, and there’s no reason to route Redis Ltd licensing costs through your cloud provider for standard caching workloads. Session storage, rate limiting, pub\/sub, leaderboards with sorted sets \u2014 Valkey handles all of it, and the performance characteristics are at least comparable, often better.<\/p>\n
Self-hosted with heavy Redis Stack module usage: stay on Redis.<\/strong> Valkey doesn’t have mature equivalents yet, and the compatibility gap is real if you’ve built on top of RedisSearch or RedisJSON. Watch the Valkey module ecosystem closely \u2014 that’s where the gap closes or doesn’t over the next year or so.<\/p>\n
Starting a new project from scratch in 2026<\/a>?<\/strong> Valkey is my default. The governance model is more stable long-term \u2014 Linux Foundation backing means no surprise license changes. The performance work is real. For typical web application use cases, you’re not giving anything up.<\/p>\n
The one caveat I’d offer: Redis has 15 years of<\/a> tutorials, Stack Overflow answers, and tribal knowledge behind it. Valkey is two years<\/a> old. That documentation gap is real, and for smaller teams without deep Redis expertise, it shows. Plan for that.<\/p>\n
For my team, we migrated session caching and rate limiting to Valkey 8.x on managed infrastructure. The search service stayed on Redis \u2014 we’re using Redis Query Engine heavily and I don’t want to rewrite that integration. Both are running fine. The migration I thought would take a weekend took about three weeks<\/a> once you factor in the<\/a> client library audit, testing, and the Friday rollback incident.<\/p>\n
Worth it. The fact that a fork can happen, get Linux Foundation backing, and reach production-grade maturity in two years<\/a> says something \u2014 and it’s a better outcome than everyone just swallowing the SSPL change and moving on.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
When Redis Ltd announced the license change in March 2024, I was in the middle of planning a caching layer for a mid-sized SaaS product \u2014 four engineers, r<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-410","post","type-post","status-publish","format-standard","hentry","category-general"],"_links":{"self":[{"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/posts\/410","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/comments?post=410"}],"version-history":[{"count":9,"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/posts\/410\/revisions"}],"predecessor-version":[{"id":564,"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/posts\/410\/revisions\/564"}],"wp:attachment":[{"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/media?parent=410"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/categories?post=410"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rebalai.com\/en\/wp-json\/wp\/v2\/tags?post=410"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}