Valkey vs Redis: Choosing a Cache for Your Linux VPS

A caching layer is one of those pieces of a VPS stack that people install once and stop thinking about — until the license under which it ships changes and suddenly matters again. That's exactly what happened with Redis, and it's why anyone provisioning a new Linux VPS for a session store, a queue backend, or a query cache now has a real decision to make instead of a default. This guide covers what actually changed, what Valkey is, and how to decide which one belongs on your server.

The License Change That Started It

For most of its history, Redis shipped under the permissive BSD 3-Clause license — the same category of license that let any hosting provider, cloud vendor, or individual operator bundle it, modify it, and redistribute it without asking permission. That changed in March 2024, when Redis's maintaining company announced it was moving Redis to a dual RSALv2 (Redis Source Available License) and SSPLv1 (Server Side Public License) model going forward, as Redis's own announcement explains. Both licenses let you read, modify, and self-host the code, but neither is an OSI-approved open-source license, and both place restrictions aimed squarely at cloud providers who want to resell Redis as a managed service without contributing back or licensing it commercially.

The change was covered widely in trade press at the time — InfoQ's report on the license shift lays out the community reaction, which included immediate pushback from major Linux distributions and cloud vendors who had built businesses on Redis being unambiguously open source. That reaction is what produced Valkey within weeks of the announcement.

For a VPS operator, the practical question isn't really about redistribution — you're running the software, not reselling it. The question is whether you're comfortable with a dependency that isn't open source anymore, whether you want to stay on the version lineage where new features keep landing, and whether your organization has any policy (many do) that requires OSI-licensed components.

What Valkey Is

Valkey is a fork of Redis, created from the last BSD-3-Clause-licensed Redis codebase in response to the 2024 license change, and it's developed as a project under the Linux Foundation rather than a single company. That governance model is the core of its pitch: no single vendor controls the license terms, and the code stays under a permissive open-source license that any distribution, cloud provider, or self-hoster can use without restriction. Redis's own account of the split, in its "what is Valkey" post, acknowledges the fork directly.

Valkey has kept moving since the split — the project's current release is version 9.1.0, published on 2026-05-19, and development has continued with its own roadmap rather than simply trailing Redis release-for-release. It's not a frozen snapshot of old Redis; it's an actively maintained project with its own contributors and its own feature additions layered on top of the shared codebase both projects started from.

Compatibility: Can You Just Swap One for the Other?

The reason this decision is low-stakes for most VPS setups is protocol compatibility. Valkey was forked to preserve compatibility with the existing Redis ecosystem, so client libraries, the RESP wire protocol, and most commands behave the same way. The Valkey migration guide walks through moving an existing Redis deployment over, and the short version is that most applications talking to Redis over a standard client library don't need code changes to talk to Valkey instead — you're largely swapping the server binary and, for a clean cutover, restoring or replicating your existing dataset.

That compatibility is not guaranteed to hold forever. Both projects have continued independent development since the fork, and newer Redis-only features or newer Valkey-only features can diverge over time. If you depend on a specific recent feature from either project, check its own release notes before assuming parity — don't assume day-one compatibility claims still apply to whatever the newest release adds.

Where You Can Run Each One

Because both are software you install yourself, either runs fine on a standard Linux VPS with enough RAM to hold your working data set — caching workloads are memory-bound far more often than CPU-bound. If you'd rather not manage the service yourself, managed options exist on both sides: Amazon ElastiCache for Redis is the long-standing managed offering for Redis-compatible caching if you want the operational overhead handled by a cloud provider instead of your own VPS.

On a self-managed VPS, the practical setup work is nearly identical for either project: install the package for your distribution (or build from source if your distro's repository doesn't carry the version you want), bind the service to the interfaces you intend to use, set a password with requirepass or the equivalent access-control mechanism, and decide on a persistence strategy — RDB snapshots, AOF logging, or both — before you put anything you can't afford to lose in front of it. That operational shape doesn't change based on which of the two you pick.

Who Should Choose Which

Good fit for Valkey:

• New deployments with no existing Redis-specific dependency
• Organizations with a policy requiring OSI-approved open-source licenses
• Anyone who wants a caching layer whose license terms aren't controlled by a single vendor

Good fit for staying on Redis:

• Existing deployments already running current Redis with no license-driven pressure to migrate
• Teams using Redis Enterprise's commercial support and tooling directly
• Applications that depend on a Redis feature not yet mirrored in Valkey's release line

Not the deciding factor either way:

• Raw performance on a typical VPS cache workload — both are the same lineage of code and behave similarly for standard get/set, list, and pub/sub patterns
• Client library support — mainstream Redis client libraries work against both

Pros and Cons

Valkey

• Permissive BSD-3-Clause license, no vendor-controlled terms
• Linux Foundation governance model
• Drop-in protocol compatibility with existing Redis clients

Redis

• Longer track record and larger existing deployment base
• Commercial support option through Redis Enterprise
• No longer OSI-approved open source under its current dual license

Final Verdict

If you're standing up a new cache on a Linux VPS today with no existing Redis investment pulling you one direction, Valkey is the lower-friction default: same protocol, same operational model, and a license that doesn't require you to track a vendor's terms going forward. If you're already running Redis and nothing about the license change actually affects your use case — you're not redistributing it, you're not building a competing managed service — there's no urgent reason to migrate. The one thing not to do is ignore the question entirely; know which license your cache runs under before it becomes a compliance surprise.

References

• Redis's dual-license shift, explained — InfoQ
• Amazon ElastiCache for Redis