Redis: The 67k-Star Cache That Changed Its License and Split in Two

Here is the most important thing to understand about Redis in 2026: there are now two Redis-shaped databases, they speak the exact same wire protocol, and they have different licenses, different governance, and increasingly different feature sets. If you are starting a new project today, the question is no longer "should I use Redis?" but "should I use Redis, or should I use Valkey?" That distinction did not exist before March 2024, and it is the entire reason this article exists.

For fifteen years Redis was the boring, reliable, permissively licensed in-memory data store that everyone reached for. It sat under BSD-3-Clause, the same chill license as so much of the open-source world, and it powered session stores, caches, queues, rate limiters, and leaderboards across millions of deployments. Then the company behind it decided the cloud providers were extracting all the value and giving nothing back, changed the license, and accidentally created the most successful database fork of the decade. This is the story of that fork, what it means for you, and how to make the call.

This review covers what Redis is, the fifteen quiet BSD years, the March 2024 relicensing, the cloud economics that caused it, the Valkey fork that landed in under a week, why migration is nearly free, Redis's AGPL olive branch in version 8, how the two projects have diverged since, real self-hosting and managed costs, where your keys actually live, and an honest verdict for a sovereignty-minded operator.

Redis in-memory data store

1. What Redis Actually Is

Redis is an in-memory data structure store. "In-memory" means it keeps its primary working set in RAM for speed, and "data structure store" means it is not just a key-value blob bucket — it natively speaks strings, hashes, lists, sets, sorted sets, streams, bitmaps, hyperloglogs, and geospatial indexes. That richness is the reason Redis outgrew the word "cache." You can build a job queue with lists and streams, a real-time leaderboard with sorted sets, a rate limiter with counters, a pub/sub channel for messaging, and a session store with hashes — all on one server.

The core job Redis takes is "give me data fast, with the right shape." Latency is measured in sub-millisecond to single-digit-millisecond ranges because there is no disk seek in the hot path for reads of resident data. It persists asynchronously to disk via RDB snapshots and/or an AOF append-only log, so it survives restarts, but its identity is speed. Redis was created by Salvatore Sanfilippo — antirez — and first released in 2009. It is, by any measure, foundational infrastructure.

2. The BSD Years (2009–2024)

For its first fifteen years Redis shipped under BSD-3-Clause. That license is about as permissive as software gets: you can use it commercially, modify it, embed it, redistribute it, and offer it as a managed service without asking anyone's permission or publishing your own source. That freedom is precisely why cloud providers — AWS, Google Cloud, Azure — built managed Redis services (ElastiCache, Memorystore, Azure Cache for Redis) on top of the open codebase. They were fully within their rights under BSD.

This is the quiet setup to the entire conflict. BSD let Redis become ubiquitous; ubiquity made it the default caching layer; being the default made it the thing cloud providers resold as a managed service; and once it was a managed service, Redis Inc. (formerly Redis Labs) watched the margin on "Redis-as-a-service" flow to the hyperscalers rather than to the company employing the core maintainers. The license that made Redis popular was the same license that, from the company's perspective, gave away the commercial upside. Nothing about BSD changed; the company's appetite for that arrangement did.

3. March 2024: The Relicensing

On March 20, 2024, Redis Ltd. announced that from version 7.4 onward, Redis would leave BSD-3-Clause for a dual source-available model: the Redis Source Available License v2 (RSALv2) and the Server Side Public License v1 (SSPLv1). Neither is OSI-approved open source. The change was not retroactive — every Redis release up to and including 7.2.4 remains BSD-3-Clause forever. That detail matters enormously, because 7.2.4 became the precise branch point for everything that followed.

What do the two new licenses actually forbid? RSALv2 is permissive for internal use but prohibits offering the software to third parties as a managed database service. SSPLv1 is the copyleft license MongoDB wrote: if you deliver the software as a service, you must release your entire service stack — management layers, APIs, orchestration, backups — under SSPL. OSI has rejected SSPL as not open source. For an ordinary application developer connecting Redis to their own app, internal use is fully allowed under both licenses. The restrictions bite cloud providers and anyone building a competing managed offering. The relicensing was laser-targeted at AWS, Google, and Alibaba reselling Redis without a commercial agreement.

4. Why Redis Did It (The Cloud Economics)

The motivation was identical to Elastic, HashiCorp, and MongoDB before it: the value capture problem. When a hyperscaler offers "Redis, managed, on our cloud," they capture the recurring revenue while the open-source vendor carries the engineering cost of the core. Redis Inc. had been trying to monetize through Redis Enterprise and add-on modules, but the free OSS core remained the thing everyone actually deployed. By tightening the core license, the company aimed to force managed providers to either pay for a license or stop reselling the unmodified software.

The strategy is defensible from a business standpoint and infuriating from a community standpoint, and both things are true. A company that pays the core engineers deserves a path to revenue. But a community that built the ecosystem around a BSD promise reasonably feels the rug moved. This tension is the recurring plot of the 2021–2024 license wave, and Redis was its highest-profile database installment.

5. Valkey: The Fork That Landed in a Week

The response was immediate and organized. Within roughly a week of the March 20 announcement, AWS, Google Cloud, Oracle, Ericsson, and Snap backed a new project under the Linux Foundation: Valkey, forked from the last BSD commit, Redis 7.2.4, and keeping BSD-3-Clause. Madelyn Olson, a top Redis core maintainer, moved over as a Valkey maintainer. The Linux Foundation's neutral governance was the masterstroke — it took the fork out of any single company's control and signaled to every distribution and cloud that this was the safe horse.

That governance point cannot be overstated. Fedora, Debian, and Ubuntu — distributions that cannot ship source-available software in their main repositories — began moving toward Valkey because it remained genuinely open. When the operating system you install ships Valkey by default, the fork is no longer a protest; it is the mainstream. Valkey shipped 7.2.5 in April 2024 (Redis-compatible), then 8.0 in September 2024 with independent features (rewritten multi-threaded I/O), and by mid-2026 it reached the 9.x line (9.1.0/9.1.1), with a large, active contributor base and roughly 25,000–29,000 GitHub stars accumulated in just over two years.

6. Wire Compatibility: The Reason Migration Is Trivial

The single most important fact for most teams is this: Valkey and Redis speak the identical wire protocol, RESP (REdis Serialization Protocol), including both RESP2 and RESP3. Because Valkey began as a literal source fork of Redis 7.2.4, its protocol handler is the same code. A client has no way to tell, at the byte level, whether it is talking to Redis or Valkey during a standard handshake. Every major client library — redis-py, ioredis, Jedis, Lettuce, go-redis, StackExchange.Redis, node-redis — connects to a Valkey server with zero code changes.

This is why the fork is not a "rewrite your app" event. Your application calls SET, GET, HGETALL, ZADD, XADD, and the server answers in the same framing. Pipelines, pub/sub framing, and cluster redirection messages (MOVED, ASK) behave identically. The protocol that carries the commands is unchanged; only the command set and internals diverge, and only for commands added after the 7.2.4 fork point. For the vast majority of deployments using the common command surface, migration is a binary swap, not a code rewrite.

7. Redis Fights Back: Redis 8 and the AGPL Olive Branch

Redis did not stand still. In May 2025, with Redis 8.0, the company added a third license option: AGPLv3. AGPLv3 is OSI-approved, so Redis became tri-licensed — RSALv2, SSPLv1, and AGPLv3 — and by the strict definition, "open source again." At the same time, Redis 8 folded the previously separate Redis Stack modules — JSON, Time Series, probabilistic structures, and the Query Engine — into the core under that tri-license, and introduced Vector Sets as a new data type.

The community reaction was, charitably, "too late." By May 2025 Valkey already had AWS, Google Cloud, and Oracle backing it, was 20–33% cheaper on AWS managed services, and had shipped cluster features Redis lacked. The dominant sentiment on Hacker News and Reddit was that the olive branch arrived after the party had moved venues. Redis 8 is a strong release and the AGPL option is real — but for many teams the license uncertainty itself had already justified the fork, and a license is a promise that was broken once.

8. The Two Diverge: Feature Roads Apart

The fork is no longer "Valkey is old Redis." Both engines have shipped independently since 2024. As of mid-2026, Valkey's stable line is 9.1.x (with 8.1.x maintained), and Redis is on 8.x (8.8.0 in May 2026). Neither is a stale copy of the other. The divergence shows up in two places: optional modules and newer commands. The protocol is shared; the feature set is drifting apart one release at a time, and within a year or two more libraries and tooling will support only one side cleanly.

The practical implication: pick based on which features you actually need today, but recognize you are now choosing a future, not just a binary. The good news is that the shared protocol means you can switch later with low code cost, as long as you have not married a Redis-only module.

9. Valkey's Standout Features

Valkey has leaned into raw performance and cluster reliability rather than module breadth. Its 8.0 release rewrote multi-threaded I/O, offloading expensive socket polling from the main thread while keeping command execution single-threaded (so no locking complexity, no client compatibility break). Published benchmarks on large instances show roughly a 2–3x single-node throughput improvement and a 69% latency reduction versus the pre-rewrite baseline. Valkey 9.0 pushed clusters to documented billion-RPS scale with improved multi-node failure recovery and atomic slot migration.

Valkey has also added features Redis does not have: per-field TTL inside a hash (handy for session stores and feature flags with auto-expiry), multi-database support in cluster mode (workload isolation without separate instances), atomic slot migration for zero-error resharding, and a CLUSTERSCAN command for consistent key scanning across an entire cluster. Valkey Search and a JSON module exist but are younger and less complete than Redis's equivalents, which is the honest trade.

10. Redis's Standout Features

Redis, conversely, has leaned into being a full-featured data platform. Since Redis 8, JSON, Time Series, Bloom/probabilistic structures, and the Query Engine are baked into the core. If you need RediSearch full-text search, RedisJSON document storage, RedisTimeSeries, or the integrated vector/semantic capabilities, Redis has the mature, in-core implementation. Redis 8 also added Vector Sets authored by antirez himself, positioning Redis for AI retrieval workloads.

The trade is license and cost, not capability. If you are already deep in Redis Stack modules, Valkey does not yet offer drop-in equivalents, and the migration math flips: the feature gap justifies staying on Redis. For greenfield projects that only need core data structures, the gap does not exist and Valkey's BSD license and lower managed cost win.

11. Performance: Where the Numbers Actually Come From

Performance claims in this space are noisy because vendors benchmark on different hardware and workloads. The honest summary: in pure key-value operations at high concurrency (hundreds of clients, tens of thousands of QPS), Valkey's multi-threaded I/O gives it a clear, measurable edge — the kind of 2–3x headline you see in AWS-driven benchmarks. Redis 8 claims its own ~2x throughput improvement, but the test conditions differ from Valkey's, so direct comparison is apples-to-oranges.

The real-world caveat: if your Redis instance serves a few hundred QPS, you will not feel either improvement. The advantage shows up at scale, under heavy client counts and large datasets, where I/O threading removes a bottleneck. For most small-to-medium apps, the license and cost difference matters far more than the last 20% of throughput. Do not pick a side based on a benchmark you will never reproduce in production.

12. The Module Question

This is the decision hinge. Redis Stack modules — Search, JSON, TimeSeries, Bloom, the Query Engine — are mature and now in Redis core. If your architecture depends on them, Valkey's younger Valkey Search and JSON implementations are not yet at parity, and you should stay on Redis or plan a module migration. If you use only the classic data structures (strings, hashes, lists, sets, sorted sets, streams), Valkey is a near-perfect drop-in with a better license and lower cost.

Treat modules as the switching cost, not the protocol. The protocol is free to move; the modules are not. Audit your MODULE LIST output before you commit to a fork, because that is where the "trivial migration" story quietly ends.

13. Cloud Provider Positions

The cloud picture has shifted decisively toward Valkey. AWS ElastiCache and MemoryDB, Google Cloud Memorystore, Heroku, and Aiven all offer Valkey, and AWS made Valkey the default for new ElastiCache creations. Google Memorystore added a Valkey option. Redis Cloud and Azure's Redis offering still serve Redis. The signal is clear: the hyperscalers that Redis tried to fence out with the 2024 license are now the biggest Valkey backers, and they are steering new customers to the BSD fork. If you are on AWS, the path of least resistance in 2026 is Valkey.

14. Real Cost: Self-Hosting vs Managed

Self-hosting either engine is "free" in license terms only if you pick Valkey (BSD) or the AGPL option of Redis. The real costs are infrastructure and operations. A single small Valkey/Redis node on a 2 vCPU / 4 GB RAM machine handles a surprising amount of cache traffic and costs roughly the price of that VM — call it $15–40/month on a modest cloud instance, plus your time to patch, monitor, and back up. The moment you need high availability, you are running at least three nodes, and the bill and operational surface triple.

Managed services change the math differently. On AWS, Valkey-based ElastiCache is documented at 20–33% cheaper than the Redis-based equivalent for comparable managed capacity, because AWS prices its own fork more aggressively. Redis Cloud pricing was simplified post-8.0 but remains oriented around the commercial product. The honest cost table: self-host = low direct cost, high ops cost; managed Valkey = moderate direct cost, low ops cost, cheapest managed option; managed Redis = moderate-to-high direct cost, low ops cost, richest features. Pick the row that matches your team size, not your ideology.

15. Data Sovereignty: Where Your Keys Live

This is the part a sovereignty-minded operator cares about most. Redis and Valkey are both self-hostable, which means your data lives on hardware you control — your VM, your cluster, your region. There is no mandatory phone-home, no telemetry that ships your keys offsite (Redis's optional telemetry is off by default and toggleable; Valkey ships none). Unlike a purely hosted product, you can run either engine air-gapped, encrypted at rest with your own keys, and replicated only to nodes you own.

The sovereignty nuance is governance, not data flow. With Valkey under the Linux Foundation, no single vendor can change the license out from under you — the foundation structure is the guarantee. With Redis, the company has already changed the license once; the AGPL option is a current promise, not a permanent one, and a future owner could theoretically adjust the non-AGPL terms. For operators who treat license stability as part of their data sovereignty posture, Valkey's foundation governance is the stronger position.

16. Migration: From Redis OSS to Valkey

For the common case — Redis OSS (BSD) 7.2 or earlier, core data structures only — migration is close to painless:

1. Stop writes, take an RDB/AOF snapshot (formats are compatible).
2. Install Valkey on the target host; its config file format is compatible with Redis.
3. Point Valkey at the snapshot; it loads the same persistence format.
4. Update your connection string's host to the Valkey instance. Client libraries need no changes.
5. Resume writes and watch latency/throughput.

You do not migrate data by re-inserting it; you migrate by swapping the binary and reloading the same files. The two real caveats: if you use Redis 7.4+ features, confirm Valkey supports them; if you use Redis Stack modules, plan a module replacement. Everything else is a binary swap with compatibility risk already amortized by two years of production use.

17. When to Choose Valkey

Choose Valkey for any new project that uses core Redis data structures and does not depend on Redis Stack modules. Choose it if you run on AWS (default ElastiCache is Valkey). Choose it if your organization has a policy against non-OSI-approved licenses, because BSD is unambiguously open. Choose it if cost sensitivity on managed services matters, since it is the cheaper managed option. Choose it if license stability is part of your risk model, because the Linux Foundation cannot unilaterally relicense. For the majority of cache, session, queue, and rate-limiter use cases, Valkey is the better default in 2026.

18. When to Choose Redis

Choose Redis if you depend on Redis Stack modules (Search, JSON, TimeSeries, Bloom, Query Engine) and want the mature in-core implementation. Choose it if you need active-active replication via Redis Enterprise, or deeply integrated vector/semantic search with Vector Sets. Choose it if your stack is already wired to Redis-specific features added after 7.2.4. Choose the AGPLv3 option specifically if you want the OSI-approved license while keeping Redis's feature lead. Redis is not "the bad guy" here — it is the feature-rich, commercially backed option with a more complicated license story, and for some workloads that is the right trade.

19. The Honest Limitations

Both engines share Redis's inherent limits: it is memory-bound (RAM is the ceiling on working set), so very large datasets get expensive fast; it is primarily single-threaded for command execution (Valkey's I/O threading helps but command execution is still serialized per shard); and persistence is asynchronous by default, so a hard crash can lose the last shard of writes unless you tune AOF fsync. On the license side, the honest limitation is asymmetric: Valkey's module ecosystem is younger, and Redis's license requires you to actually select and comply with one of three options, the least permissive of which (SSPL) can surprise you if you drift into offering it as a service. Neither is "just install and forget" at scale.

20. Who Should Care in 2026

If you are a backend engineer, this is a choosing-your-future decision, not a trivia question. If you are a platform team, your default cache engine for new services should be a conscious Valkey-versus-Redis call, documented in your architecture standards. If you are a CTO weighing license risk, the Redis story is the clearest case study in "the license you trusted can change," and Valkey is the clearest case study in "the community can rebuild." The fork is mature, the migration is cheap, and the cost difference is real. Indifference is no longer defensible.

21. Redis in the Wild: Typical Production Architectures

It helps to see how teams actually deploy this thing before you pick a side. The most common pattern is the cache-in-front-of-database: an application checks Redis/Valkey for a value, misses, reads from Postgres, writes the value back with a TTL, and subsequent requests are served from memory. Done well, this cuts database load by an order of magnitude. Done poorly — with unbounded key growth and no eviction policy — it becomes a memory leak wearing a cache costume.

The second common architecture is the session store, where user sessions live in hashes with per-session TTLs, letting you scale stateless app servers horizontally because any server can read any session. The third is the rate limiter, using sorted sets or counters with EXPIRE to throttle API abuse. The fourth is the job queue or stream, using Redis lists/streams with consumers groups for reliable background work. And the fifth is the real-time leaderboard or fan-out, using sorted sets and pub/sub. All five work identically on Redis and Valkey because they use core data structures only — which is exactly the deployment profile where Valkey is the frictionless default.

22. Common Operational Mistakes

The mistakes are predictable and expensive. Mistake one: no eviction policy, so the instance grows until it hits maxmemory and starts returning errors instead of evicting. Set an explicit maxmemory-policy (usually allkeys-lru for caches). Mistake two: treating it as a system of record when it is a cache — if your only copy of data lives in Redis and the node dies, that data is gone unless you tuned AOF. Mistake three: using it as a large-object store; Redis is for small, hot values, not 10 MB blobs, which bloat memory and slow replication. Mistake four: ignoring keyspace notifications and large-key monitoring until latency spikes. Mistake five, and the one this article exists to prevent: assuming the license you read about in 2023 still applies in 2026. Verify against the current LICENSE file of whichever engine you run.

23. Alternatives Beyond Valkey

If neither Redis nor Valkey fits, the field has other in-memory options. KeyDB, now under the Linux Foundation, is another Redis fork with multi-threading and Active-Active replication, also BSD-leaning. Dragonfly markets itself as a drop-in Redis replacement with a different architecture (single-threaded fibers, huge memory efficiency) and its own license that you must read carefully. Memcached remains the simplest pure-cache option if you need only key-value and want minimal surface area. And for durability-first workloads, a database with a cache tier (like Postgres with a Redis front) often beats overloading Redis as the source of truth. The point is that "Redis-shaped" is now a category with several engines, and the license-aware choice is Valkey for the default case.

24. Monitoring What Matters

Whichever engine you run, watch a small set of signals: memory usage versus maxmemory (evictions and rejected connections are your early warnings), hit rate (a cache with a 50% hit rate is doing half its job), latency percentiles (p99 matters more than average), and replication lag if you run replicas. Both engines expose INFO and INFO COMMANDSTATS, and both integrate with the Prometheus exporter pattern — which, incidentally, is exactly the kind of observability the Grafana article in this series covers. Set an alert on evictions and on memory pressure before you need it; the first time you discover the cache is full is usually during an incident, not a quiet Tuesday.

25. Security: What You Must Enable

A self-hosted cache is a juicy target, and the default install is not secure. At minimum: bind to private interfaces, not 0.0.0.0 on a public IP; set a strong requirepass (or, better, ACLs) so unauthorized clients cannot read or flush your data; enable TLS for client and replica traffic if data crosses a network you do not fully trust; and restrict the FLUSHALL/CONFIG/DEBUG commands via ACLs for application users. Both Redis and Valkey support ACLs, and Valkey's governance means these security features are free and open, not gated. A Redis/Valkey instance with no password exposed to the internet is a cryptocurrency-miner recruitment poster within minutes — this is one of the most common breaches in the self-hosted world, and it is entirely preventable.

26. The Five-Year Outlook

Where does this go? The pattern of the 2021–2025 license wave is now clear: a company relicenses, a foundation-backed fork appears within weeks, the company adds an OSI license back as an olive branch, and the fork keeps the momentum because trust, once broken, does not fully return. For Redis/Valkey, expect the two to diverge further on modules and clustering while staying protocol-compatible for years. The safe prediction: Valkey becomes the default for new open-source-aligned projects, Redis remains the feature-rich commercial platform, and the protocol compatibility keeps switching costs low. The lesson for operators is durable: treat the license as a first-class architectural input, not a footer you read after the fact.

27. When NOT to Use Redis or Valkey

Knowing what these engines are bad at is as important as knowing what they are good at. Do not use them as your system of record: if losing the last few seconds of writes on a crash is unacceptable, you need a disk-first database with stronger durability guarantees, not an in-memory cache whose AOF is asynchronous by default. Do not use them to store large binary objects — a 10 MB value per key murders memory efficiency and replication speed; object storage exists for that. Do not use them as a queue when you need strict ordering and exactly-once delivery across failures at scale; dedicated queuing systems handle that better. Do not reach for them when a relational database with good indexing already serves your read pattern — adding a cache "just in case" creates a consistency problem you then have to solve. And do not adopt either without a clear eviction and memory policy, because an unconfigured instance is a time bomb, not a cache. The right mental model is: Redis and Valkey are accelerants for data you can reconstruct, not the vault for data you cannot lose.

28. Redis Cluster vs Sentinel: Choosing a Topology

When you outgrow a single node, you face two classic topologies, and both apply equally to Redis and Valkey. Sentinel provides high availability for a master-replica setup: replicas take over if the master fails, and Sentinel monitors and orchestrates the failover. It is relatively simple and covers the "don't lose the cache when a box dies" requirement for most teams. Cluster mode, by contrast, shards your data across multiple master nodes, each with replicas, so you get both availability and horizontal scale — essential once your working set exceeds one machine's RAM. The trade is complexity: Cluster mode changes some client behaviors (keys for a multi-key operation must live in the same hash slot) and adds operational surface. Valkey's 9.x line has invested heavily in cluster reliability — multi-node failure recovery, atomic slot migration, and CLUSTERSCAN — precisely because cluster mode is where Redis historically had rough edges. The honest guidance: start with Sentinel plus a replica for HA, move to Cluster only when RAM or throughput forces sharding, and if you are going to run Cluster at scale, Valkey's recent cluster work is a genuine reason to prefer it.

29. A Note on Redis Enterprise and the Paid Tier

It would be incomplete to discuss Redis without naming Redis Enterprise, the commercial product that the relicensing was meant to protect. Enterprise adds active-active geo-replication, advanced clustering, and the mature Redis Stack modules (Search, JSON, TimeSeries, Bloom) as managed, supported features. If your architecture genuinely depends on active-active CRDT replication across regions or you want vendor SLAs on the module stack, Redis Enterprise is the legitimate paid answer — and the AGPL option means even the open core is OSI-approved now. The honest framing is not "Redis bad, Valkey good" but "Valkey is the open default; Redis Enterprise is the supported premium." Most teams do not need the premium; the ones that do already know it. The relicensing saga is really the story of a company drawing the line between the free BSD-compatible core (now Valkey) and the paid, differentiated platform (Redis Enterprise) — and the community deciding the core was too important to let drift.

30. Getting Started: A Five-Minute Local Spin-Up

The fastest way to feel the Redis/Valkey difference is to run one locally. With Docker, docker run -p 6379:6379 redis:7.2 gives you the last BSD Redis; swap the image for valkey/valkey:9 and you have the fork — same port, same client, same redis-cli. Connect, run SET foo bar then GET foo, and you have confirmed the protocol compatibility this article hinges on. Try redis-benchmark to see throughput, add a requirepass to practice the security basics, and stand up a replica with --replicaof to see HA. The point of a five-minute spin-up is to demystify: these are a single binary speaking a simple protocol, and the fork means you choose which binary. Start with Valkey for new work, keep the Redis image if you depend on a Stack module, and you have made the architectural choice this entire article argues for. This is also the cheapest possible insurance against license risk: by keeping the Valkey image one line away, you have already hedged. If Redis changes terms again, your migration is a tag swap, not a project — and that option is precisely the freedom the 2024 fork secured for you.

31. Bottom Line

Redis did not die in 2024; it split. The BSD core lives on as Valkey under the Linux Foundation, faster and cheaper and unambiguously open, while Redis itself became a tri-licensed, feature-rich, commercially steered platform. For new projects on core data structures, Valkey is the recommendation: better license, lower cost, comparable or better performance, and foundation governance that cannot pull the rug. For module-heavy or enterprise-redis workloads, Redis remains the capable choice. Either way, verify the current license of whatever you deploy against the project's LICENSE file — not against a blog post from before 2024 — because in this corner of infrastructure, the license is the feature that changed everything.

Redis: The 67k-Star Cache That Changed Its License and Split in Two — A Deep Dive Into the Valkey Fork