Valkey vs Dragonfly vs Redis: self-hosted cache for Next.js in 2026

Quick answer (2026)

If you are running a cache behind a Next.js SaaS and you want the least operational risk, run Valkey. It is genuine BSD 3-Clause, it is governed by the Linux Foundation rather than a single vendor, and it is the only one of the three that backports security fixes across every supported release line. If your app already leans on the Redis 8 data types, JSON, time series, vector sets or the query engine, stay on Redis, because Valkey does not have those and migrating away from them is a rewrite, not a config change. If you have a single large box and a workload that is genuinely throughput bound, Dragonfly will use that box far better than either, and you should accept in exchange that it ships one release line with no backports.

Two things we found that the first page of Google does not mention.

Not one of the top results is written by a neutral party. Of the nine organic results for this question, eight are published by a company selling one of the three answers. Redis ranks at position 2 and position 8 with its own assessment of the fork that was created in response to its licensing change, and that page closes with a "Try Redis free" button. Dragonfly ranks at position 6 with a comparison of its two competitors against each other. The only independent source on the page is a Reddit thread.

And the licensing argument, which is the entire framing of that first page, barely applies to the person asking the question. We read all three license files rather than summaries of them. If you are self-hosting a cache behind your own product, all three permit it. The differences that will actually cost you something are operational, and nobody is writing about them.

We run the ShipGarden gallery by self-hosting the components we recommend, so what follows is a read of the repositories, the security advisories, the npm registry and the license files themselves. Every version, count, date and license below was read from the source on August 21, 2026.

The three things are not the same kind of thing

• 

  Valkey is a fork of Redis 7.2.4, started March 22, 2024, days after the license change. Same codebase lineage, same protocol, BSD 3-Clause, Linux Foundation governance. 26,935 stars.

• 

  Redis is the original, now on the 8.x series, tri-licensed. It has moved aggressively into data types beyond caching. 76,078 stars.

• 

  Dragonfly is not a fork at all. It is an independent C++ reimplementation from 2021 that speaks the Redis protocol, built around a thread-per-core architecture. Business Source License. 31,019 stars.

That last distinction matters more than the star counts suggest. Valkey inherits Redis's codebase and therefore inherits Redis's bug classes. Dragonfly inherits the protocol and none of the code, so it does not receive Redis's vulnerabilities and it does not receive Redis's fixes. It has its own.

The honest comparison table

Stars, issue counts, branch lists, commit counts, release dates and advisory records read from each project's GitHub repository on August 21, 2026. Licenses read from each repository's own license file, not from third party summaries. Commit counts cover May 23 to August 21, 2026. All of these move. Re-check before you commit.

Licensing, stated accurately instead of dramatically

This is the part every other page leads with, so it is worth being precise, because the precise version is much less alarming than the dramatic one.

Valkey is BSD 3-Clause. The COPYING file carries two copyright lines, "2024-present, Valkey contributors" and "2006-2020, Redis Ltd.", which is the fork history in two lines of text. Permissive, OSI approved, no conditions beyond attribution. There is nothing to analyse here, which is the point.

Redis 8 is tri-licensed: you choose RSALv2, SSPLv1, or AGPLv3. AGPLv3 is OSI approved, so the common claim that "Redis is no longer open source" stopped being true with Redis 8. AGPL's network copyleft is the real question, and here is the notable part: on Redis's own comparison page, Redis states that using Redis unmodified as a backend database is "generally understood not to trigger AGPLv3's copyleft obligations, and most production deployments fall into this category." If you are running stock Redis as a cache, the vendor is telling you the copyleft does not reach you. Redis 7.2.4 was the last BSD release, and Redis Software 7.2 reached end of life on February 28, 2026.

Dragonfly is BUSL 1.1, with a Change Date of November 1, 2030, after which it becomes Apache 2.0. This is the only one of the three that is not open source by the OSI definition, and it is worth reading the Additional Use Grant rather than stopping at the license name. It permits use "only as part of your own product or service, provided it is not an in-memory data store product or service", and forbids offering it as a service to third parties. Read plainly: caching your own SaaS behind Dragonfly is explicitly allowed. Building a hosted cache product on it is not.

So for the reader we are actually writing for, someone self-hosting a cache behind their own application, all three licenses permit what you want to do. The licensing panic is aimed at cloud providers, and it was always aimed at cloud providers. If your legal team has a blanket policy against source-available licenses, that rules out Dragonfly and it is a real constraint. Otherwise this is not your deciding factor, and the first page of Google is directing your attention at the wrong thing.

The thing that actually differs: what happens when a CVE lands

This is the finding we did not expect and it is the reason this article exists.

On July 21, 2026, Valkey published five releases on the same day: 9.1.1, 9.0.5, 8.1.9, 8.0.10 and 7.2.14. All five carry the same two security fixes, CVE-2026-56684 (a use-after-free in TLS connection handling) and CVE-2026-63639 (a corrupt stream RDB file accepted during deserialisation). A team still on the 7.2 line, forked-era software that is over two years old, got a patch on the same day as a team on the current 9.1 line.

That is not an accident of scheduling. The Valkey repository carries explicit versioned maintenance branches for 7.2, 8.0, 8.1, 9.0 and 9.1, alongside branches literally named agent/backport/sweep/7.2, agent/backport/sweep/8.0 and so on through 9.1. The backport process is a named, mechanised part of the project.

Redis does the same thing at similar scale. On August 17, 2026 it published 8.10.1, 8.8.2, 8.6.6, 8.4.6, 8.2.9 and 7.4.11 together, a six-line coordinated security batch.

Dragonfly has no versioned maintenance branches at all. We listed 100 branches on the repository and every one is a feature or work-in-progress branch: AddMSetEx, BullMq, FixCpuAffinity, Prefetch, TryReproduce6114 and so on. There is no 1.38 branch, no 1.39 branch. Patch releases like v1.40.1 happen on the current line and then the line advances.

The practical consequence is simple. On Valkey or Redis, applying a security fix while staying on your pinned minor version is a patch bump. On Dragonfly, if a fix lands in v1.40 and you are pinned to v1.37, your upgrade path is three minor versions of behaviour change, taken under time pressure. That is a genuine operational cost and it is invisible in every feature table on the first page.

To be fair to Dragonfly on the other side of the ledger: it is also the most actively developed of the three by a wide margin, at 487 commits in the last 90 days against Valkey's 204 and Redis's 161. It has the smallest open issue count, 305 against Redis's 2,903. A single fast-moving line is a legitimate engineering strategy for a young project. It is just a different risk posture than most teams assume they are buying.

Security advisory hygiene, which nobody audits

While we were reading the advisory records we found something worth reporting carefully, because the careless version of this finding would be wrong.

Valkey has published 10 advisories, and every single one lists exact patched versions per branch. CVE-2026-63639 reads "9.1.1, 9.0.5, 8.1.9, 8.0.10, 7.2.14". You can hand that to a scanner or read it yourself in five seconds and know your answer.

Redis has published 47 advisories, and several of the recent high severity ones do not carry a patched version. CVE-2026-25243, a high severity invalid memory access in the RESTORE command that the advisory says "affects all Redis versions" and could lead to remote code execution, was published on May 5, 2026 with a vulnerable range of "All" and a patched version of "TBD". As of August 21, 2026, that record has not been updated once in three and a half months, and the August 17 release batch does not mention RESTORE.

We want to be careful about what that does and does not mean. It does not mean Redis is shipping a known unpatched remote code execution. The fix may well exist in the code with the advisory record simply never updated, and that is the likeliest explanation. What it does mean is narrower and still matters: the machine-readable metadata is stale. Dependabot, vulnerability scanners, SBOM tooling and compliance reviewers consume exactly that field. An advisory reading "vulnerable: All, patched: TBD" causes a scanner to flag every version of Redis you run, indefinitely, with no way for you to determine from the published record whether you are exposed. If you work somewhere that has to answer audit questions about CVE remediation, that is a recurring cost with no clean resolution.

Dragonfly publishes 3 advisories, including CVE-2026-62357, a heap out-of-bounds write reachable through CMS.INITBYDIM. None of the three list patched versions either. So Dragonfly is not CVE free, it simply has a shorter history and a smaller surface, and it gives you the least machine-readable remediation information of the three.

On this specific axis Valkey is cleanly ahead, and it is the only axis we found where one project is unambiguously better run than the other two.

Performance, and why the 25x number is not for you

Dragonfly's homepage claims 25x more queries per second than Redis, citing 3,970,000 QPS against 718,000, and 30% better memory efficiency at 275 GB against Redis's 500 GB, with Valkey shown at 400 GB. These are Dragonfly's own benchmarks.

The number is not dishonest, but it is measuring something specific that you should understand before you budget around it. Dragonfly is thread-per-core: give it a 64 core machine and it uses 64 cores. The comparison is against a Redis process, and Redis's core execution model is single threaded. So 25x is largely a measurement of vertical scaling on a large box, not of a faster hash table.

That matters because of what it implies about your own deployment. If you are running a cache in a container with two vCPUs, which describes most Next.js SaaS deployments, the architectural advantage Dragonfly is selling mostly does not engage. You would be adopting a source-available license and a single release line in exchange for headroom you are not using.

For their part, both incumbents publish their own numbers and they are also self-measured. Valkey 9.0, released October 21, 2025, reports over 1 billion requests per second on a 2,000 node cluster, along with up to 40% higher throughput from pipeline memory prefetch, 20% from zero-copy responses, and up to 200% from SIMD optimisations. Redis reports more than 5x throughput in 8.6 versus 7.2 on a single node, and up to 87% lower latency in 8.0 versus 7.2.5.

Every figure in this section was produced by the vendor that benefits from it. Treat all of them as directional. The only benchmark that decides anything is the one you run on your own workload on your own instance size.

Where Redis is genuinely, unarguably ahead

Valkey forked from Redis 7.2.4 and Redis has not stood still since. Redis 8 folds JSON, time series, five probabilistic structures, vector sets and the Redis Query Engine including hybrid search into the core distribution. Valkey covers JSON, Bloom filters and vector search through official BSD-licensed modules in the Valkey Bundle, and does not have time series, the additional probabilistic structures, vector sets, semantic caching or FT.HYBRID at all.

If your application uses those, this comparison is over and the answer is Redis. Not because of a licensing philosophy, but because the alternative is a rewrite. Redis maintains well over a hundred commands that Valkey does not have.

Worth stating plainly, since we spent most of this article on Valkey's operational strengths: Redis is shipping faster on features than Valkey is, and the gap is widening rather than closing. Four point releases in a year on the 8.x line is a real pace. If you are choosing a cache today for an application you expect to add vector search or semantic caching to within a year, choosing Valkey to avoid a license that its own vendor says probably does not apply to you would be a bad trade.

What this means in a Next.js app, concretely

Here is the part that surprised us most, and it collapses a lot of the anxiety in this decision.

The npm registry, for the month of July 21 to August 19, 2026:

Redis-branded clients out-download Valkey-branded clients by roughly 40 to 1. And that is fine, because it does not matter. All three servers speak RESP. ioredis connects to Valkey and to Dragonfly without changes. In practice your Next.js app imports ioredis, your REDIS_URL points at whichever server you chose, and the choice you agonised over is invisible above the connection string.

One live-registry detail we want to state correctly, because the lazy reading of it is wrong and we nearly wrote it. iovalkey, the Valkey-branded fork of ioredis, went 13 months without a feature release, from 0.3.3 on June 12, 2025 to 0.4.0 on July 27, 2026. That looks like an abandoned client ecosystem, and it is not. iovalkey is quiet because it is largely redundant: ioredis already speaks the protocol, so a fork of it has little reason to exist. The client Valkey actually funds is @valkey/valkey-glide, which is Apache-2.0, shipped 2.5.1 on August 11, 2026, runs a visible release-candidate cadence, and maintains a latest-2.2 LTS dist-tag alongside latest, which is the same multi-line support discipline the server project shows. Valkey's client story is healthy. It just is not the package the name would lead you to.

Also worth pinning if you are upgrading anything this quarter: ioredis shipped 6.0.0 on July 31, 2026, its first major in years, and node-redis is at 6.2.1 as of August 11, 2026. If you are moving cache servers and bumping a major client version in the same change, separate those into two deploys. Whichever one breaks, you will want to know which one it was.

If your cache is doing more than caching, the shape of the decision changes again. Queue workloads in particular are worth thinking about separately, since BullMQ runs directly on Redis and inherits whatever you choose here, and the same applies if you are using Redis as the counter store behind rate limiting, where the durability and failover behaviour of the server matters more than raw throughput.

How we would choose

Choose Valkey if you are running a cache and you want the boring answer. Real BSD license, multi-vendor governance so no single company can change the terms on you again, and the best backport and advisory discipline of the three by a clear margin. This is the default and it should be the default.

Choose Redis if you use the Redis 8 data types, or expect to within the year. The feature gap is real and widening, the AGPL option is OSI approved, and Redis itself says stock backend use does not trigger copyleft. The cost is the advisory metadata problem, which is an annoyance for most teams and a genuine compliance burden for a few.

Choose Dragonfly if you have a specific, measured, throughput-bound workload on a machine with real core count, and you have read the Additional Use Grant and confirmed you are not building a cache product. Accept the single release line as the price. Do not choose it for a two vCPU container because of a 25x number measured on hardware you are not running.

What should not decide this: the licensing argument as it is usually presented. For self-hosting a cache behind your own product, all three permit it, and the page that ranks second for this question is written by one of the three vendors and ends in a signup button.