Why redis is losing friends and valkey is gaining them

You highlighted How a license change triggered an open-source revolt, why major Linux distros are dropping Redis, and how Valkey is stepping up as the quiet hero developers didn’t know they needed Introduction: From hero to forked why redis is losing devs’ trust Redis used to be the in-memory data store everyone loved fast, dependable, battle-tested. You’d throw it in your stack without a second thought. Caching? Use Redis. Rate limiting? Redis. Real-time leaderboard for your wannabe game? Redis again. But lately, the vibe has shifted. The project that once symbolized the best of open source is now under fire for something that has little to do with code and everything to do with control: its license. Developers are talking. Linux distributions are acting. And a new contender, Valkey, has quietly walked into the room not as a flashy startup-backed rewrite, but as a drop-in replacement that wants none of the drama. So what the hell happened? This isn’t just a nerdy licensing argument. It’s a turning point in how devs, ops teams, and cloud providers decide what software deserves a place in their stack. We’re talking about the soul of open source, forks as a form of resistance, and why something like Valkey might just outlive the giant it replaced. Ready to dive into the weird world where legal fine print breaks software adoption? Let’s go. Section 1: When open source stops feeling open Here’s the TL;DR: Redis Labs, the company behind Redis, decided it was tired of cloud providers (like AWS and friends) offering Redis as a service and making bank without contributing much back. So, they did what many other companies have done in the past few years they changed the license. Redis moved away from the permissive BSD license and started releasing many of its modules under the Server Side Public License (SSPL) the same controversial license MongoDB adopted back in 2018. Let’s break that down without legalese-induced migraines: The SSPL says you can use the software unless you offer it as a service to others. If you do, you’re required to open-source your entire stack. Which sounds “fair” until you realize that no cloud provider in their right mind is going to open-source their infrastructure code just to keep using Redis. So, yeah that’s not really “open source” anymore. In fact, the Open Source Initiative (OSI) explicitly says SSPL does not qualify as an open source license. That move by Redis Labs? It felt less like protecting a community and more like putting up a “No Cloud Providers Allowed” sign on the front door. And if history has taught us anything (hey MongoDB), dev communities don’t take kindly to license bait-and-switches. It’s not just about ideology either legal murkiness scares distro maintainers, enterprise teams, and sysadmins who don’t want to get caught in compliance quicksand. So what happened next? Spoiler: the Linux world started hitting the eject button. Section 2: linux distros say “no thanks.” When Linux distros start dropping your package, it’s not because they don’t like you anymore it’s because you’ve become legally spicy. That’s exactly what happened to Redis. Soon after the license switch, several major Linux distributions decided they weren’t going to play legal Jenga with the SSPL. One by one, they began removing Redis from their official repositories: Debian: yeeted it right out in the Bookworm release. Fedora: marked it for removal. Alpine: gone. openSUSE: adiós. These aren’t fringe players. These are the default environments for container images, VPS setups, and enterprise servers all over the world. When distros kick out your software, it has ripple effects: CI/CD pipelines break. Containers need rebuilds. DevOps teams scramble to find drop-in alternatives. Newcomers stop learning your tool because it’s not available with a simple apt install. Even if Redis still works fine and is maintained, it’s now become harder to trust not for technical reasons, but because you can’t ship your stack with legal uncertainty baked in. And that’s when something interesting happened. Instead of begging Redis Labs to reverse the decision, the community just said: “Fine. We’ll build our own Redis. With blackjack and BSD licensing.” Enter: Valkey. Section 3: Enter Valkynot a fork, a lifeboat When trust breaks in open source, devs don’t wait for PR statements they fork. That’s how we got Valkey. Valkey isn’t just a community fork of Redis it’s a declaration of independence. Spun up by core contributors and maintainers who weren’t thrilled with Redis Labs’ licensing detour, Valkey sticks to the old-school BSD 3-Clause license. The kind devs can actually use without alerting legal. Even better? It’s backed by the Linux Foundation the same folks behind Kubernetes, Node.js, and other boringly reliable infrastructure projects. That means long-term stability, a real governance model, and no bait-and-switch surprises hiding behind a corporate curtain. Here’s what makes Valkey special:

May 18, 2025 - 02:00

Why redis is losing friends and valkey is gaining them

You highlighted

How a license change triggered an open-source revolt, why major Linux distros are dropping Redis, and how Valkey is stepping up as the quiet hero developers didn’t know they needed

Introduction: From hero to forked why redis is losing devs’ trust

Redis used to be the in-memory data store everyone loved fast, dependable, battle-tested. You’d throw it in your stack without a second thought. Caching? Use Redis. Rate limiting? Redis. Real-time leaderboard for your wannabe game? Redis again.

But lately, the vibe has shifted.

The project that once symbolized the best of open source is now under fire for something that has little to do with code and everything to do with control: its license.

Developers are talking. Linux distributions are acting. And a new contender, Valkey, has quietly walked into the room not as a flashy startup-backed rewrite, but as a drop-in replacement that wants none of the drama.

So what the hell happened?

This isn’t just a nerdy licensing argument. It’s a turning point in how devs, ops teams, and cloud providers decide what software deserves a place in their stack. We’re talking about the soul of open source, forks as a form of resistance, and why something like Valkey might just outlive the giant it replaced.

Ready to dive into the weird world where legal fine print breaks software adoption?
Let’s go.

Section 1: When open source stops feeling open

Here’s the TL;DR: Redis Labs, the company behind Redis, decided it was tired of cloud providers (like AWS and friends) offering Redis as a service and making bank without contributing much back. So, they did what many other companies have done in the past few years they changed the license.

Redis moved away from the permissive BSD license and started releasing many of its modules under the Server Side Public License (SSPL) the same controversial license MongoDB adopted back in 2018.

Let’s break that down without legalese-induced migraines:
The SSPL says you can use the software unless you offer it as a service to others. If you do, you’re required to open-source your entire stack. Which sounds “fair” until you realize that no cloud provider in their right mind is going to open-source their infrastructure code just to keep using Redis.

So, yeah that’s not really “open source” anymore.
In fact, the Open Source Initiative (OSI) explicitly says SSPL does not qualify as an open source license.

That move by Redis Labs? It felt less like protecting a community and more like putting up a “No Cloud Providers Allowed” sign on the front door. And if history has taught us anything (hey MongoDB), dev communities don’t take kindly to license bait-and-switches.

It’s not just about ideology either legal murkiness scares distro maintainers, enterprise teams, and sysadmins who don’t want to get caught in compliance quicksand.

So what happened next?

Spoiler: the Linux world started hitting the eject button.

Section 2: linux distros say “no thanks.”

When Linux distros start dropping your package, it’s not because they don’t like you anymore it’s because you’ve become legally spicy.

That’s exactly what happened to Redis.

Soon after the license switch, several major Linux distributions decided they weren’t going to play legal Jenga with the SSPL. One by one, they began removing Redis from their official repositories:

Debian: yeeted it right out in the Bookworm release.
Fedora: marked it for removal.
Alpine: gone.
openSUSE: adiós.

These aren’t fringe players. These are the default environments for container images, VPS setups, and enterprise servers all over the world.

When distros kick out your software, it has ripple effects:

CI/CD pipelines break.
Containers need rebuilds.
DevOps teams scramble to find drop-in alternatives.
Newcomers stop learning your tool because it’s not available with a simple apt install.

Even if Redis still works fine and is maintained, it’s now become harder to trust not for technical reasons, but because you can’t ship your stack with legal uncertainty baked in.

And that’s when something interesting happened.

Instead of begging Redis Labs to reverse the decision, the community just said:
“Fine. We’ll build our own Redis. With blackjack and BSD licensing.”

Enter: Valkey.

Section 3: Enter Valkynot a fork, a lifeboat

When trust breaks in open source, devs don’t wait for PR statements they fork.

That’s how we got Valkey.

Valkey isn’t just a community fork of Redis it’s a declaration of independence. Spun up by core contributors and maintainers who weren’t thrilled with Redis Labs’ licensing detour, Valkey sticks to the old-school BSD 3-Clause license. The kind devs can actually use without alerting legal.

Even better? It’s backed by the Linux Foundation the same folks behind Kubernetes, Node.js, and other boringly reliable infrastructure projects. That means long-term stability, a real governance model, and no bait-and-switch surprises hiding behind a corporate curtain.

Here’s what makes Valkey special:

Same API, same commands: If you know Redis, you know Valkey. Your client libraries? Still work. Your existing infrastructure? Probably won’t even notice.
Actively maintained by Redis core contributors: This isn’t some random GitHub repo with one contributor from 2016. These are the same folks who helped build Redis into what it is today.
Community over corporation: No one entity “owns” Valkey. It’s a genuinely open project with transparent development, open meetings, and clear roadmaps.

Valkey isn’t trying to be the next shiny database. It’s trying to be the reliable Redis alternative you don’t have to feel weird about deploying.

And that mission? It’s starting to catch on including among cloud providers.

For instance, UpCloud recently announced native Valkey support on their platform a subtle but clear signal that even infra companies are shifting toward forks that stay true to the spirit of open source.

When the people who run the internet start switching out Redis behind the scenes, you know something big is happening.

Section 4: From cloud to code major platforms start to switch

You know things are getting real when infrastructure providers the ones running thousands of production databases start quietly replacing Redis with Valkey.

It’s not a flashy transition. No confetti, no Twitter drama (yet). Just changelogs, blog posts, and release notes subtly saying: “Now supporting Valkey.”

One notable example? UpCloud.

Instead of waiting for the license dust to settle, UpCloud made the proactive move to support Valkey as a core service. Their announcement didn’t throw shade or spark a war they just aligned with what their developer customers want: open, stable, license-clean alternatives that don’t come with legal baggage.

And it’s not just about ideology. Here’s why cloud providers care:

Compliance simplicity: They don’t want lawyers breathing down their necks every time a client spins up a managed database.
Future-proofing: When upstream projects become uncertain, providers prefer forks with long-term guarantees.
Developer trust: Devs don’t like surprises. “Hey, your stack is now a licensing minefield” isn’t exactly a confidence booster.

Under the hood, Valkey behaves like Redis. From a cloud provider’s perspective, it’s the same operationally just minus the SSPL drama. For developers and teams, that means no breaking changes, no migration hell, and no surprise fees (or lawsuits).

And as more platforms quietly adopt Valkey behind the scenes, Redis starts to look less like an industry standard and more like a legacy choice waiting to be replaced. UpCloud — European leading cloud hosting provider for fast VPS and cloud servers | Devlink Tips Give a try to UpCloud with €50 free credits for 30 days (signup here)

Section 5: But isn’t redis still better? (let’s talk real talk)

Let’s be honest Redis didn’t become a staple of modern web stacks for nothing.

It’s been fast, elegant, and rock-solid for years. So the natural question is:
“Is Valkey really up to the task?”

Short answer? Yes.
Longer answer? Let’s break it down.

Performance

Valkey is practically a 1:1 fork of Redis as of the last permissively licensed version. That means:

Same blazing-fast in-memory performance
Same pub/sub behavior, data structures, and commands
Zero difference for 99.9% of apps using it today

If you’re benchmarking Valkey vs Redis side-by-side right now? You’re splitting hairs.

Ecosystem

Redis definitely has a richer ecosystem for now.
It has more integrations, modules, hosted providers, and third-party tooling. But here’s the catch many of those modules are under SSPL too. That’s the part that triggered this whole mess.

Valkey is rebuilding the ecosystem under a truly open license, but yes, it will take some time to reach parity in terms of community contributions and extensions. If you rely heavily on advanced Redis modules, this might be the one reason to hold back temporarily.

Trust

This is where things flip.

Valkey isn’t just a fork it’s a philosophical reboot. It’s a bet that trust, openness, and transparency matter more to developers than corporate control or brand legacy.

Redis Labs’ SSPL move made devs pause and ask:

“If this changed once, what stops it from changing again?”

Valkey, by contrast, is out in the open. Governed by a neutral foundation. Maintained by a real community. No closed-door licensing pivots.

That’s the kind of thing devs bet careers on.

So sure Redis might still have some swagger left. But Valkey is quickly gaining the one thing that matters most in the long run: developer trust.

Section 7: What should devs do now?

So here you are a developer, a DevOps engineer, maybe even the “accidental Redis admin” of your team. What do you actually do with all this information?

Let’s break it down based on how you’re using Redis right now:

If you’re self-hosting Redis

Strongly consider switching to Valkey.
It’s a drop-in replacement. Same config. Same CLI. Same commands. Zero drama.

Just uninstall Redis
Install Valkey (available in many distros now or via Docker)
Change your service name if needed
Profit (legally this time)

If your company cares about compliance (hint: they do), this move makes you look like the forward-thinking engineer who read the room.

If you’re using managed Redis in the cloud

You’re not off the hook.

While many cloud providers (AWS, Azure, etc.) still use Redis, they may not advertise how they’re complying with SSPL or even if they are. That’s risky long-term.

Start by:

Asking your provider if they offer Valkey or plan to
Keeping your Redis layer abstracted use wrappers or clients that let you swap easily
Testing Valkey in staging or dev environments

Many developers don’t realize until it’s too late that their infra has quietly gone from “open source” to “open question.”

If you’re building tooling or platforms

If you’re the kind of dev who’s embedding Redis into other platforms or SaaS tools, you must plan for a potential switch or at least give your users the choice.

Add support for Valkey explicitly
Make licensing part of your architecture decisions
Document the switch path (many will need it soon)

In short? Redis isn’t suddenly unusable. But it is now something you have to think twice about.
And the smartest devs are already planning around it.

Section 8: the future of in-memory databases

So where do we go from here?

Redis isn’t vanishing overnight it still powers thousands of apps, supports countless real-time systems, and has brand recognition most projects would kill for. But the writing’s on the wall, and it’s spray-painted in bright red: Licenses matter. Trust matters more.

Let’s explore what the future looks like:

Redis doubles down

Don’t expect Redis Labs to reverse their SSPL decision. If anything, they’re likely to lean further into commercial offerings and “open core” strategies. That means:

More modules under restrictive licenses
Deeper vendor lock-in
Increased divergence between Redis and community forks

Good for business? Maybe.
Good for open source? Not really.

Valkey keeps gaining ground

Valkey has momentum not because it’s exciting, but because it’s boring in the best way. Stable. Transparent. Community-driven.

Expect to see:

More distros adopting Valkey as the default
More cloud providers quietly switching
A new wave of contributors breathing life into ecosystem tools

Valkey isn’t just chasing Redisit’s playing the long game for trust.

Devs become more license-aware

This whole episode is part of a broader shift: developers are becoming more license-savvy. We’ve gone from:

“Is it open source?”
to
“What kind of open source?”

The days of tossing dependencies into a repo without thinking are numbered. Projects like Valkey show that the community will fork and adopt when core values are violated.

In-memory data is more relevant than ever (hello, real-time apps, AI, and edge computing), but we’re moving into an era where governance and openness are just as important as speed and features.

Section 9: follow the trust, not just the code

Redis isn’t going anywhere but it’s no longer the no-brainer choice it once was.

In a world where developers are drowning in tools, libraries, and frameworks, trust is what makes something stand out. Not just trust in performance, but in governance, licensing, and future-proofing.

Valkey didn’t emerge because Redis was slow or buggy. It happened because Redis Labs changed the rules of the game and the community refused to play along.

This story isn’t just about a database. It’s about:

The consequences of open-core licensing
The quiet power of developer communities
How forks can become the future when they stand on principle

So whether you’re shipping to prod, scaling your infra, or just trying to understand what’s happening under your docker-compose.yaml take this as a reminder:

Don’t just trust the code. Trust the people and the process behind it.

Redis may still be running your app, but Valkey might be running your next one.

Section 10: helpful resources

If you want to dive deeper into the licensing drama, explore Valkey hands-on, or just follow the breadcrumbs of what’s really going on behind the scenes here’s your cheat sheet:

Articles & Blogs

GitHub & Code

Talks & Community

FOSDEM: “The Open Source Licensing Crisis”
Reddit Thread: r/devops on Redis License Switch (search for latest)
Linux Foundation Valkey Working Group

Tools & Helpers

Blog Sponsor of the Month: UpCloud

UpCloud is a Finland-based developer and European cloud hosting provider known for its exceptional reliability, speed, and performance. Built for developers who demand control and efficiency, UpCloud offers robust infrastructure with transparent pricing and global data centres.
For our readers, UpCloud is offering €50 in free credits for an extended 30-day trial. Test the platform using this signup link or apply promo code DEVLINK50 at signup.
Tried it out? Drop a comment below, we’d love to hear your feedback and experiences.