If you are a solo founder picking a cache, queue, or key-value store in 2026, here is the decision rule up front: unless you plan to resell the datastore itself as a managed service, the entire Redis licensing saga does not apply to you — so choose on ecosystem and operations, not on license fear. The copyleft and "as a service" restrictions that made headlines only trigger when you distribute the software or offer it as a hosted product. Running it behind your own app is not that. With that settled, the honest engineering question is narrow: do you want the safest drop-in, the richest built-in feature set, or the simplest path to vertical scale?

Let me get the history right first, because the internet is full of half-remembered versions of it.

What Actually Happened to the License#

In March 2024, Redis Ltd moved Redis off the permissive BSD 3-clause license it had used for over a decade. New versions shipped under a dual license: the Redis Source Available License v2 (RSALv2) and the Server Side Public License v1 (SSPLv1). Neither is considered open source by the Open Source Initiative. The trigger was commercial: the licenses are aimed at cloud providers who sell Redis-as-a-service without contributing back.

Days later, the Linux Foundation launched Valkey, a fork of Redis 7.2.4 kept under the original BSD 3-clause license, backed by AWS, Google Cloud, Oracle, Ericsson, and Snap. Valkey put governance under a neutral, multi-vendor Technical Steering Committee — a deliberate answer to the single-vendor control that caused the relicense in the first place.

Then the plot turned. In November 2024, Redis creator Salvatore Sanfilippo (antirez) rejoined the company and pushed for a return to open source. In May 2025, Redis 8 shipped GA and added the OSI-approved AGPLv3 as a third license option, creating a tri-license: AGPLv3, RSALv2, and SSPLv1. In the same release, Redis folded its formerly separate Stack modules — Search (RediSearch), JSON, TimeSeries, Bloom, and the new Vector Sets type — directly into core Redis Open Source under that same tri-license.

The net result: Redis is genuinely open source again under AGPLv3, and it now ships batteries-included. But it lost the trust of the vendors who had already built Valkey — and they are not coming back.

Does the License Actually Affect You?#

This is the part most comparison pieces get wrong by burying it. For a self-hosting founder, here is how each license behaves in practice.

The through-line is that all three restrictions are about reselling the datastore, not using it. The one founder profile that must read the license carefully is the one building a product where the KV store is the product — a hosted queue, a managed cache, a Redis-compatible API you charge for. If that is you, Valkey is the only fully unrestricted option. For everyone else, this section is permission to stop worrying.

The Performance Model (Not the Benchmarks)#

Ignore the QPS leaderboards for a second and understand the architecture, because that is what actually determines your scaling story.

Redis executes commands on a single thread. This is a feature, not a bug — it gives you simple, predictable, lock-free semantics. Redis 8 and modern versions add I/O threads to offload network work, but command execution stays serialized. You scale Redis by adding more instances (clustering/sharding), not bigger ones.

Valkey inherits that single-threaded core but has invested heavily in asynchronous I/O threading, contributed largely by AWS. Valkey's team claims meaningful throughput gains from this work, and Valkey 9 (September 2025) adds memory prefetching and SIMD optimizations that the project says push per-node throughput up to 40 percent over Valkey 8.1. Treat these as vendor figures, but the direction is real: Valkey squeezes more out of a single node than classic Redis while keeping the same mental model.

Dragonfly is the architectural outlier. It uses a multi-threaded, shared-nothing design: the dataset is split into shards, one per CPU core, each owned by exactly one thread, with threads communicating only by message-passing — no locks. This is why Dragonfly's pitch is vertical scaling: give it a 32-core box and it uses all 32 cores, where Redis would leave 31 idle for command execution. Dragonfly's headline benchmark claims 25x the throughput of a single Redis process, reaching ~3.8M QPS on a large AWS instance. That is a vendor benchmark on network-optimized hardware — impressive, but validate it on your own workload before betting on it.

The practical takeaway: if your bottleneck is one hot node and you would rather resize a server than operate a cluster, Dragonfly's model is genuinely different. If you are nowhere near a single node's limits — which describes most solo founders — the threading model is a tie-breaker, not a decider.

Managed Offerings and Migration#

For a solopreneur, "who runs it for me" often matters more than the engine.

AWS made Valkey its default path. ElastiCache and MemoryDB added Valkey in October 2024, and AWS prices node-based Valkey roughly 20 percent below Redis, and serverless Valkey about 33 percent below. Google Memorystore and Azure Cache also offer Valkey. If you deploy on AWS and want managed-and-cheap, Valkey is the obvious choice — same protocol, lower bill.

Redis Cloud remains the first-party managed Redis, and it is where the in-core Search, JSON, and vector features shine without you assembling modules yourself.

Dragonfly Cloud is the managed option for Dragonfly. It is a single-vendor service, which is fine, but a smaller ecosystem than the hyperscaler-backed Valkey.

Migration is mostly painless because all three speak the Redis wire protocol. Valkey is a straight fork — for most apps it is a version bump. Dragonfly advertises drop-in compatibility; the swap is often just a connection string:

# Point your existing Redis client at Dragonfly — same protocol, same commands
redis-cli -h dragonfly.internal -p 6379 PING

The gotchas live at the edges: Redis-specific modules, some Lua and cluster internals, and exotic commands. Test your actual command set, not a hello-world.

The Recommendation#

For the default solo founder — caching, session storage, a job queue, rate limiting — choose Valkey. It is BSD-licensed with no strings, neutrally governed so you will never face another surprise relicense, wire-identical to the Redis you already know, and it is the cheapest managed engine on AWS. There is almost no downside for the common case.

Choose Redis 8 if you specifically want the built-in Search, JSON, TimeSeries, or vector features and would rather have them in one supported package than assemble modules yourself. AGPLv3 will not touch you as a self-hoster, and the ecosystem is still the largest in the category.

Choose Dragonfly if your problem is genuinely a single hot node that you would rather scale by resizing hardware than by operating a cluster — and you have confirmed your command set is covered. Just remember the BSL means you cannot turn around and sell it as a hosted datastore.

The one honest warning: the license only becomes your problem if your product is the datastore. If you are just storing keys and reading them back fast, stop reading license comparisons and go build. Pick Valkey and move on.