Redis Open Source 7.2 is no longer the default forward path for the in-memory store it anchors in most stacks. The last BSD-licensed Redis release shipped in 2023, the commercial7.2 software branch reached end-of-life on February 28, 2026, and every subsequent Redis release is now tri-licensed under RSALv2, SSPLv1, and AGPLv3. Platform engineers who deferred the licensing decision when the fork was announced are now operating against an unpatched, unsupportable baseline. This article maps the three realistic upgrade paths from Redis 7.2 — Redis 8, Valkey, and the commercial Redis line — and lays out the trade-offs a team must weigh before choosing one.
Redis Open Source 7.2.4 shipped in 2023 as the final release under the BSD 3-Clause license, and the commercial Redis Software 7.2 branch reached formal end-of-life on February 28, 2026 (Redis FAQ on Valkey). That date is not symbolic. Once a Redis line is EOL, the vendor stops producing bug fixes, security patches, and compatibility backports for it. Operationally, this means three concrete losses:
The fork that the BSD Redis 7.2.4 codebase enabled — Valkey — chose the opposite trajectory. According to the Valkey releases page, the Valkey 7.2 branch (initially released 2024-04-16) is actively maintained:
| Support type | Valkey 7.2 end date |
|---|---|
| Maintenance (bug fixes + security fixes) | 2027-04-16 |
| Security support | 2029-04-16 |
That timeline is not theoretical. The Valkey 7.2 branch received security point releases in July and August 2026, including 7.2.14 on 2026-07-21, addressing CVE-2026-56684 (a use-after-free in TLS connection handling reachable via CLIENT KILL) (Valkey GitHub releases). Any team still on Redis 7.2 has no equivalent patch available on the Redis Inc. side.
At this point, the three viable paths off Redis 7.2 — Redis 8, Valkey, and Redis Enterprise / Redis Cloud — deliver broadly similar wire-protocol compatibility and largely overlapping feature sets. The remaining differentiators are licensing posture (BSD vs. AGPLv3/RSALv2/SSPLv1 vs. commercial) and governance (Linux Foundation vs. Redis Ltd. vs. vendor-managed). In other words, the question has stopped being "which engine is faster or more capable" and become "which license and which governing body can your organization commit to for the next three to five years."
The licensing backdrop matters more than the version number, because the terms attached to a Redis release line are fixed at build time, not at the moment a team deploys it. Three dates on the calendar define the split most platform engineers underestimated when the fork was announced.
On March 20, 2024, Redis Ltd. announced that Redis would move from the BSD 3-Clause license to a dual source-available model under RSALv2 (Redis Source Available License v2) and SSPLv1 (Server Side Public License v1), effective with the 7.4 release line. The accompanying repository change was committed the same day. Neither RSALv2 nor SSPLv1 qualifies as open source under the Open Source Initiative's definition: both place field-of-use restrictions on competitors offering database-as-a-service products. Under the old BSD terms, any party could package and resell managed Redis without negotiation; under the new terms, doing so without a commercial agreement is out of bounds.
The community response was immediate. On March 28, 2024, the Linux Foundation forked the last BSD-licensed Redis commit, Redis 7.2.4, into the Valkey project, preserving the original BSD-3 terms. Backers included AWS, Google Cloud, Oracle, Ericsson, Alibaba, Huawei, and Tencent — organizations whose infrastructure investments depended on a permissively licensed Redis-class engine. The fork shipped its first release within roughly two months and has since evolved independently under Linux Foundation governance, as documented on the Valkey history page.
Redis Ltd. did not stand still. On May 1, 2025, the company added AGPLv3 as a third licensing option beginning with Redis 8. That addition returned Redis to OSI-approved open-source status, but with a copyleft caveat: AGPLv3 is generally interpreted to require source disclosure for modifications served over a network. Running unmodified Redis as an internal backend is widely understood not to trigger that obligation, but organizations with blanket AGPL prohibitions still treat the new terms as a blocker. The Redis license change announcement and its follow-up coverage note the commitment to keep AGPLv3 as a permanent option.
The practical implications for an upgrade decision are straightforward:
A final version-sensitive point often missed: the license governing a running deployment is determined by the release line that was built, not by the calendar date the binary was started. A Redis 7.2 binary compiled before March 2024 remains BSD-3; a Redis 7.4 binary is dual RSALv2/SSPLv1; a Redis 8 binary is tri-licensed. That distinction is what makes the 7.2 end-of-life decision consequential rather than routine.
The Redis 8 line is the feature-led upgrade for teams that can absorb AGPLv3 obligations. Redis Ltd. has shipped four major point releases in roughly twelve months, and the cumulative performance delta versus the 7.2 baseline is substantial:
FT.HYBRID for combined full-text and vector search with score fusion in a single query, atomic slot migration for safer cluster rebalancing, and up to 92% memory reduction for JSON numeric arrays.The headline change for teams that previously licensed Redis Stack is consolidation. Redis 8 ships the following natively in the open-source distribution rather than as separately installed modules:
FT.HYBRIDThat single-binary model eliminates the module deployment and compatibility matrix that 7.2-era Stack users had to maintain.
The cost is licensing. Redis 8 is tri-licensed under RSALv2, SSPLv1, and AGPLv3. AGPLv3 is OSI-approved, but its Section 13 network copyleft clause means that anyone who modifies Redis and offers the modified build over a network must offer the corresponding source to interacting users. Running Redis 8 unmodified as a backend store inside an application is generally understood not to trigger that obligation, but a hosted or managed-service offering built on a modified build does. AWS's ElastiCache documentation is explicit on the enterprise reception: AGPLv3's copyleft provision creates legal and commercial risks, and many organizations strictly forbid adoption of AGPLv3 software. Teams with a standing policy against AGPLv3, or those that resell Redis as a service, should treat this path as closed before they begin performance evaluation.
For teams that have already cleared AGPLv3 with legal, Redis 8 is the most direct upgrade from Redis 7.2 in operational terms: the RESP protocol, core command set, and client libraries are unchanged, so the migration is largely a version bump and a Stack-module retirement.
Sources: Redis 8 release notes and feature comparison, AWS ElastiCache Redis vs Valkey guidance.
For teams that want to remain on a permissive open-source license, Valkey is the lowest-friction exit from Redis 7.2. The Valkey project, governed by the Linux Foundation, forked from Redis OSS 7.2.4 and continues to ship under BSD-3, leaving behind the RSALv2/SSPLv1/AGPLv3 stack that now governs every Redis release. Because the 7.2 codebase is shared, the move is an engine swap rather than a platform change.
Compatibility at the protocol and data layer
Valkey 7.2.x is wire-compatible with Redis OSS 7.2. The RESP2 and RESP3 wire protocols are unchanged, RDB and AOF files move across directly, and the configuration syntax — including all Redis 7.2 directives — is accepted as-is. Existing client libraries, Lua scripts, and redis:// connection URLs work without modification. Even redis-cli talks to Valkey servers, and INFO continues to report redis_version:7.2.4 for backward compatibility; server_name and valkey_version are used to identify the actual engine.
Supported version matrix
The compatibility matrix published by the Valkey migration topic page and reproduced in the Percona migration guide defines the supported paths:
Redis 7.2 is therefore the most flexible source. The matrix applies in reverse when stepping up the Valkey line: from Valkey 7.2.x a team can move to 8.0.x, 8.1.x, 9.0.x, or 9.1.x without a dump-and-reload.
What 8.1 and the 9.x line add
Valkey 8.1 (released March 31, 2025) ships infrastructure improvements that are transparent to clients: a new dictionary implementation that delivers roughly a 20% memory reduction versus the Redis 7.2 baseline, hash field TTL (on parity with Redis 8.0), TLS accept throughput up 300% versus 8.0, TLS full handshakes 18% faster, and fork copy-on-write cost during persistence cut by 47%. Valkey 9.0 added further cluster improvements, and Valkey 9.1 (May 19, 2026) introduces database-level ACLs, a new IO-threading model that improves throughput up to 17%, and per-key memory reductions up to 44% for strings.
Support windows
According to the Valkey releases page, each minor version receives three years of maintenance support and five years of security support:
| Version | Initial release | Maintenance end | Security end |
|---|---|---|---|
| 7.2 | 2024-04-16 | 2027-04-16 | 2029-04-16 |
| 8.0 | 2024-09-15 | 2027-09-15 | 2027-09-15 |
| 8.1 | 2025-03-31 | 2028-03-31 | 2030-03-31 |
| 9.0 | 2025-10-21 | 2028-10-21 | 2028-10-21 |
| 9.1 | 2026-05-19 | 2029-05-19 | 2031-05-19 |
Packaging and procurement signals
Adoption has reached critical mass across the ecosystem. AWS ElastiCache defaults new Redis-compatible clusters to Valkey, Ubuntu 24.10+ and Debian 13+ ship Valkey as the default redis-server package, Fedora Rawhide replaced Redis with Valkey, and Homebrew replaced the redis formula with valkey. For enterprise procurement, that convergence reduces risk: package signatures, CVE feeds, and managed-service SKUs increasingly assume Valkey is the baseline.
Choosing the commercial line is a deliberate procurement decision rather than the path of least resistance. Redis Software 7.2 — the last commercially supported branch aligned with the BSD-licensed era — reached end-of-life on February 28, 2026, according to the Redis Inc. Valkey FAQ. Any team that stayed on the commercial 7.2 branch without renewing is now running unsupported binaries, and renewing means moving to a current Redis Software release or migrating workloads to Redis Cloud, both delivered under RSALv2 commercial terms rather than the original BSD-3 framework.
What the commercial tier actually buys, per the same FAQ and the broader Redis enterprise feature set:
The trade-offs are equally concrete:
One factor softens the lock-in concern: the commercial line preserves the same RESP protocol and core command set as Redis Open Source 8, so application code, client libraries, RDB/AOF files, and Lua scripts remain portable. A team that later decides to exit the commercial contract can move to Redis 8 under the AGPLv3/RSALv2/SSPLv1 tri-license, or to a RESP-compatible engine like Valkey, with code changes limited to the connection endpoint and any modules unique to Redis Enterprise. That portability makes Path C a defensible choice when the enterprise features — especially Active-Active v2 and contractual SLAs — justify the recurring cost, but it is not a free option and should be priced against the engineering effort the alternative paths would absorb.
This is not a recommendation. It is a five-check decision framework a platform engineer can walk through before scheduling the cutover.
1. Is AGPLv3 on the company's approved-licenses list, and if not, is there an internal exception process?
Every Redis release after 7.4 is tri-licensed under RSALv2, SSPLv1, and AGPLv3. SSPLv1 is not OSI-approved, and RSALv2 restricts managed-service redistribution, so many enterprise legal teams treat the package as effectively AGPLv3-or-commercial. Valkey is BSD3-Clause under the Linux Foundation, which clears the bar for most permissive-license policies without an exception. If AGPLv3 has no precedent in your organization and the exception process is slow, Valkey or the commercial Redis line are the only paths that survive legal review.
2. Does the workload use any Redis 8 features that Valkey would only match via a community module?
Redis 8 absorbed the Redis Stack modules into core: native JSON, time series, five probabilistic structures, the Query Engine, and Vector Sets. Subsequent point releases added FT.HYBRID (Redis 8.4) and idempotent streams production (Redis 8.6), as well as Redis Functions 2.0 with WebAssembly support. Valkey offers JSON, Bloom filters, and basic search only as separate BSD-licensed modules; time series, the broader probabilistic set, vector sets, semantic caching, and the full Query Engine have no first-party Valkey equivalent. If a service depends on FT.HYBRID, JSON Path filtering, or idempotent stream producers, Redis 8 is the only path that delivers those features in core.
3. Is the deployment self-hosted, on ElastiCache, or on another managed provider, and does that provider already default to Valkey?
AWS ElastiCache and MemoryDB, Google Cloud Memorystore, Akamai Linode Managed Databases, and Heroku have all adopted Valkey, with ElastiCache Serverless defaulting new clusters to the Valkey engine. Azure has no first-party managed Valkey offering and is steering customers toward Azure Managed Redis. If the workload already runs on ElastiCache or Memorystore, the operational answer is often already Valkey whether the team chose it or not. Self-hosted deployments carry no such default and need an explicit decision.
4. Does the team depend on a Redis Inc. commercial feature that is not in Valkey?
Active-Active geo-distribution with CRDT conflict resolution, Redis Flex (hybrid RAM/flash), Redis Data Integration, published99.999% SLAs, RBAC, SAML, audit logging, and Redis LangCache for semantic caching all remain gated behind Redis Enterprise or Redis Cloud. None of these exist in Valkey, open-source Redis, or any Valkey module today. If a regulated workload requires RBAC, audit trails, or a contractual SLA, the commercial Redis line is the only viable path.
5. What is the rollback story?
This is the asymmetric part of the decision. RDB and AOF files from Redis OSS 7.2 can be loaded by Valkey 7.2.x or Valkey 8.0.x, and existing RESP2/RESP3 client libraries connect to either engine unchanged. Migration from Redis 7.2 to Valkey is effectively a reversible upgrade. The reverse is not true: once a cluster has been cut over to Valkey 8 or to Redis 8, RDB format differences make going back a destructive operation. Treat the cutover as a one-way door and keep a tested 7.2 snapshot until the new stack has been validated in production.
For the majority of caching, session-store, queue, and pub/sub workloads running on Redis 7.2 today, Valkey 8.x is the lowest-friction path because RESP, RDB, AOF, and the existing client libraries are all unchanged. Workloads that lean on the Redis 8 feature set or on Redis Inc. commercial capabilities do not share that path and need a different answer.