Valkey Won the Default: What a git-push PaaS Should Bundle Now That the Redis Fork Became the Safe Choice

In March 2024, Redis gave up the BSD license, and the ecosystem did something it rarely does: it agreed on a replacement within weeks. The Linux Foundation forked Redis 7.2.4 as Valkey under BSD-3, backed by AWS, Google, Oracle, and Ericsson — and two years later, the fork is the path of least resistance. Fedora replaced Redis with Valkey outright. Debian, Ubuntu, and Arch serve redis from Valkey packages. AWS prices ElastiCache Serverless for Valkey 33% below Redis OSS, calls Valkey its recommended engine, and Google's Memorystore for Valkey is generally available.

So here is the verdict up front, for anyone running a git-push platform: defaulting your one-click cache and session store to Valkey instead of Redis costs a typical tenant functionally nothing, removes a licensing risk from your roadmap, and buys a 20–33% price edge on managed hosting. The only tenants who should stay on Redis are the ones whose workloads depend on Redis Stack modules. That is the whole post in one paragraph — the rest is the receipts and the boundary line:

Two things to read off this table before the detail. First, the top row is nearly every cache and session workload a PaaS tenant ever deploys — the exotic row is the exception, not the rule. Second, the middle row is a today statement, not a forever one: Valkey 9.0 folded JSON, Bloom, and vector search support into official modules, so the boundary is moving. Default accordingly, and re-check the boundary yearly.

How a relicense moved the default in four dates​

March 2024: Redis abandons BSD. Redis Ltd. switched the core repository from BSD-3 to dual RSALv2/SSPLv1 licensing — source-available terms that forbid offering the software as a managed service without a commercial agreement. Whatever you think of the business logic, the effect on downstream packagers was immediate: a copyleft-shaped restriction had landed in a dependency that shipped inside everything.

March 28, 2024: the fork lands with corporate backing on day one. The Linux Foundation announced Valkey, forked from Redis 7.2.4, keeping the BSD-3 license. This was not a hobby fork: AWS contributed the initial work, and Google, Oracle, Ericsson, Snap, Alibaba, Huawei, and Tencent put engineers on it. The governance point matters more than the sponsor list — no single company can unilaterally relicense Valkey out from under its users, which is precisely the failure mode everyone had just watched.

Late 2024 – 2025: Valkey stops being "just a fork." Valkey 8.0 shipped about six months after the fork with reworked I/O multithreading that pushed throughput past 3× the 7.2 baseline on multi-core machines — the project deliberately became more than a license refuge. Valkey 8.1 followed in April 2025. Meanwhile the distros moved: Fedora approved an in-place replacement of Redis with Valkey, and Debian, Ubuntu, and Arch began serving the redis package name from Valkey builds with redis-compat symlinks, so apt install and existing redis-cli habits kept working.

May 2025 – 2026: the clouds and the modules catch up. Redis Ltd. added AGPLv3 as a third license option in Redis 8 — a genuine concession worth naming honestly, though AGPL's copyleft still bites anyone embedding the engine in a hosted service, which is exactly what a PaaS does. On the Valkey side, AWS made it the recommended engine on ElastiCache with Valkey 9.0 support landing in May 2026, and Valkey 9.0 itself (April 2026) shipped the single most-requested feature, hash field expiration, plus a faster resharding algorithm and official JSON/Bloom/vector-search modules.

The honest summary: Redis is not dead, and Redis 8's AGPL option narrows the license gap for anyone who can live with copyleft. But "can you live with copyleft in your platform's data path" is a question no platform team wants to keep answering — and Valkey is what you pick when you'd rather stop answering it.

The receipts: who switched, and what it prices at​

Distro packaging is the quietest signal and the most telling. Maintainers don't switch a default package for fashion; they do it when the old license makes distribution legally awkward. Fedora's change proposal says it outright — Redis's new terms were incompatible with Fedora's FOSS commitments, so Valkey took its place, flowing downstream to RHEL, AlmaLinux, and friends. Debian, Ubuntu, and Arch took the softer path (Valkey builds providing the redis name plus compat packages), but the direction is identical: a fresh Linux install in 2026 that asks for Redis gets Valkey.

The cloud numbers are louder:

Note what AWS did not do: it didn't delete Redis. It priced Valkey below Redis and pointed new users at it — which, for a platform choosing a default, is the same thing with extra steps. When the biggest managed-Redis vendor on earth tells you the fork is the recommended engine and charges you a fifth less to agree, the default has moved whether or not anyone held a vote.

The compatibility ledger: what transfers, and where the line is​

This is the section the title owes you, so here it is as a ledger rather than prose.

Transfers verbatim — zero migration cost. Valkey speaks RESP and matches the Redis OSS 7.2 API, so for the workloads that make up nearly all PaaS cache usage, there is nothing to port: strings, hashes, lists, sets, sorted sets, streams, HyperLogLog, bitmaps, geospatial indexes, TTLs, transactions, Lua scripts, Pub/Sub, and Sentinel-based failover all behave the same. Your clients keep working — ioredis, node-redis, Python's redis-py, Go's go-redis — because the wire protocol didn't change. AWS's own migration writeup describes a customer moving to ElastiCache for Valkey as a drop-in replacement without application code changes, pocketing the 20% node-based saving. For a tenant, the migration is a connection-string flip: point REDIS_URL at the Valkey endpoint and watch the hit rate not move.

The boundary — check before you migrate. Redis 8 bundles the old Redis Stack modules (JSON, Search, and the newer vector sets) directly into the single distribution. Valkey deliberately didn't inherit those proprietary-licensed modules, and its replacements — Valkey-Search, Valkey-JSON — shipped as separate modules that spent 2025 catching up. Valkey 9.0 narrowed this substantially by blessing official modules for JSON, Bloom filters, and vector search, but independent 2026 comparisons still give Redis the edge on vector-search throughput, and anyone running RediSearch query syntax in production should treat "Valkey-Search is improving fast" as a roadmap statement, not a migration clearance.

The bright-line rule for your platform docs:

If your app uses Redis as a cache, session store, queue, or rate limiter — the data structures, not the modules — Valkey is a lateral move. If FT.SEARCH, JSON.GET, or vector similarity is load-bearing in your request path, stay on Redis and re-evaluate yearly.

That rule covers the representative case honestly. The overwhelming majority of REDIS_URL consumers on any PaaS are in the first sentence; the second sentence exists so the one team doing hybrid semantic-plus-keyword retrieval doesn't learn about the boundary during an incident.

What a git-push PaaS should actually do​

Concretely, for a self-hosted platform deciding what its one-click cache add-on provisions:

1. Make Valkey the default engine for the cache/session-store add-on. New tenants get Valkey unless they opt out. The license story means you will never have to migrate them again for legal reasons, and the 20–33% managed-price delta (or the zero-cost apt install valkey on your own nodes) compounds across every tenant.
2. Keep Redis as a documented escape hatch, gated on modules. Not a second equal citizen — a checkbox labeled "I need RediSearch/RedisJSON/vector search" that provisions Redis instead. Escape hatches you have to justify using stay rare; defaults you have to justify leaving stay put.
3. Write the cutover runbook once, reuse it per tenant. Measure working-set size and hit rate first, stand up Valkey alongside, dual-write or drain-first for sessions depending on your tolerance for a cold cache, flip REDIS_URL, keep the old instance warm for one TTL window, then decommission. No client library changes, no query rewrites — the runbook is short because the protocol didn't move.
4. Say the quiet part in your docs: you won't run it for them. A word on scope, since this blog lives on a PaaS site: bex deliberately does not offer managed databases — no hosted cache tier to migrate, no premium to pay. That non-goal is what makes the Valkey default cheaper for a bex tenant than for anyone on a hosted platform: the "managed-data-layer premium" other vendors charge for failover automation and proxy routing is simply absent, and the engine choice reduces to which binary your compose file or machine image installs.

One more consideration for the performance-minded: Valkey 8's multithreading means the open-source engine now benches comparably to enterprise Redis builds on multi-core nodes. If your fleet's cache nodes were sized under the old single-threaded assumption — one hot core, the rest idle — re-benchmark before you copy the old sizing over. The bottleneck moved, and your capacity plan should move with it.

The default already moved; update your golden path​

Two years after the fork, the shape of the outcome is clear: the license fight is over, the ecosystem picked the BSD-licensed fork, the clouds priced it to win, and the engine itself is faster than what it forked from. The remaining Redis advantage is real but narrow — modules for search, JSON documents, and vectors — and it shrinks with every Valkey release. For a git-push PaaS, that makes the decision a rare easy one: bless Valkey as the default, keep Redis behind a modules-only escape hatch, and spend the platform energy you save on problems your tenants can't solve with a connection-string flip.

Ready to run your own fleet on machines you own, with boring, fork-proof defaults? Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service. Star the repo on GitHub or deploy your first app today.