Valkey vs Redis for new projects in 2024

Redis spent a decade as the default answer for “we need a fast in-memory cache.” Session stores, job queues, rate limiters, pub/sub fan-out: if latency mattered, someone proposed Redis. That changed in March 2024, when Redis Inc. announced license changes for new releases, moving away from the permissive BSD terms many teams assumed would never move.

The community response was Valkey, a Linux Foundation project forked from Redis OSS 7.2.4, continuing under the BSD 3-clause license. If you are starting a greenfield service in 2024, you are not choosing “Redis vs nothing.” You are choosing which lineage, license, and vendor relationship you want for the next five years.

What actually changed with Redis licensing

Redis 7.2.4 was widely treated as the last release under the classic open-source Redis licensing posture teams had built on for years. Starting with Redis 7.4, Redis Inc. moved new versions to a source-available dual license (RSALv2 and SSPLv1), which restricts how some cloud providers and redistributors can offer the software without a commercial agreement.

Redis Inc. has since expanded options (including AGPL paths in later announcements), but the damage for many operators was trust and predictability: license terms can change, and procurement/legal review suddenly belongs in a cache conversation that used to be “apt install and go.”

Valkey’s launch statement from the Linux Foundation (March 28, 2024) frames the fork as community-led continuity: same problem space, BSD license, multi-vendor governance instead of a single vendor steering the roadmap.

Official references:

• Linux Foundation announces Valkey
• Redis license overview (Redis Inc.)

Read both sides. Your lawyer cares about redistribution, SaaS embedding, and support contracts, not blog hot takes.

What Valkey is, technically

Valkey started from the Redis 7.2.4 codebase and aimed for compatibility so existing clients and commands largely work unchanged. Major cloud vendors lined up behind Valkey quickly (AWS, Google Cloud, Oracle, and others appear in launch materials), which means you are less likely to compile from source on Ubuntu LTS when your platform packages Valkey as the default Redis-compatible engine.

Project home: valkey.io

When new projects should prefer Valkey

Default to Valkey for new self-hosted or bring-your-own-cache deployments if these are true:

• You want a permissive OSI-friendly license without negotiating a commercial Redis license for embedding or redistribution.
• You deploy on Linux VMs, Kubernetes, or a cloud that offers managed Valkey and you prefer vendor-neutral governance.
• Your app uses standard Redis protocols and mainstream client libraries (most do) rather than Redis Inc.-exclusive enterprise modules you pay for separately.
• You are building internal tools, SaaS backends, or client infrastructure where legal review of SSPL/RSAL language would slow you down.

Valkey is especially sensible when the project lives in a monorepo or appliance you ship to customers. “We bundle a cache” triggers license questions fast. BSD Valkey answers many of them cleanly.

When staying on Redis still makes sense

Stick with Redis Inc.’s product line when:

• You already pay for Redis Enterprise / Redis Cloud and your support contract, SLAs, and staffing assume that stack.
• You rely on Redis-specific commercial modules or enterprise features that are not mirrored in Valkey’s roadmap on your timeline.
• Your organization standardized on Redis Inc. support for compliance and incident response, and migration cost exceeds licensing friction.
• You are not starting fresh: a mature production cluster with tuned persistence, shard migration playbooks, and on-call runbooks may not justify a fork swap during a quiet quarter.

Do not migrate for ideology alone. Migrate when license risk, packaging, or cloud billing forces a decision.

Running Redis 7.2.x past its support window is a third path into trouble. Redis Inc. has published EOL guidance for older open-source lines; treat unsupported caches like unsupported databases: budget replacement or paid extended support.

Complementary to the AGPL conversation

Some teams will evaluate Redis 8’s AGPL option against Valkey’s BSD model. See our Redis AGPL license change write-up for that thread. Short version: AGPL may suit internal-only services; BSD Valkey is simpler when you ship software to clients; commercial Redis wins when you want enterprise modules and one vendor contract.

If you are an MSP, document one default per tier so technicians are not re-debating licenses on every SOW.

Practical migration notes

For new projects, start on Valkey. For existing Redis OSS, inventory clients and custom modules, test replication in staging, plan a cutover window, and update monitoring. Managed services may hide the engine rename; know what you are buying.

Most small businesses never touch Redis directly. This matters when you operate the cache: agencies, dev shops, and MSPs hosting Linux apps.

Bottom line: For most new open-source or self-managed projects after the 2024 license shift, Valkey is the conservative default: BSD license, Redis-compatible API, foundation governance, and broad vendor support. Stay on Redis Inc. when enterprise features, existing contracts, or managed services already solve your problem. The mistake is treating “Redis” as a single timeless product; today it is a family of lines with different license strings attached.