Are Many Companies Replacing Redis By Dragonfly?
- 60% of MD5 Password Hashes Can Be Cracked in Under an Hour with a Single GPU
- Dirty Frag: Root Access on Every Major Linux Distribution — No Patch, No Warning
- Ubuntu 26.04 LTS (Resolute Raccoon): The Most Ambitious Ubuntu LTS in a Decade
- Proton Mail: Data Transferred to FBI Again!
- How Close Are Quantum Computers to Breaking RSA-2048?
- How to Prevent Ransomware Infection Risks?
- What is the best alternative to Microsoft Office?
In-Depth Analysis
Are Many Companies Replacing
Redis by Dragonfly —
What’s Really Happening in 2025–2026
A wave of viral posts claims companies are “abandoning Redis for Dragonfly.” The real story is both more dramatic and more nuanced — involving a licensing crisis, a fork backed by Amazon and Google, and a genuine architectural challenger. Here’s a clear-eyed look at what has actually changed.
Redis: A Decade of Dominance
Since Salvatore Sanfilippo created Redis (Remote Dictionary Server) in 2009, it became the default answer for in-memory caching, session management, pub/sub messaging, and real-time leaderboards. E-commerce, fintech, gaming, AI platforms — virtually every backend stack that needed speed reached for Redis. For over a decade, it was genuinely irreplaceable.
Redis’s architecture is elegant: single-threaded event loop, simple data structures (strings, hashes, lists, sets, sorted sets), and a protocol so clean that thousands of client libraries exist across every language. That simplicity was also its ceiling. A single-threaded design means it cannot natively exploit multi-core CPUs. On a 64-core machine, Redis still uses one core.
The Licensing Crisis That Changed Everything
The ecosystem shift you’re hearing about today didn’t start with performance — it started with a licensing decision that fractured the Redis community.
-
Mar 2024
Redis changes license. Redis Ltd. announced the switch from the permissive BSD-3-Clause license to dual licensing under RSALv2 and SSPLv1 — “source available” terms designed to prevent cloud providers from offering Redis as a managed service without a commercial agreement. The move triggered immediate backlash: Redis was removed from major Linux distributions.
-
Apr 2024
Valkey is born. The Linux Foundation announced Valkey — a fork of Redis 7.2.4 under the original BSD license — backed by AWS, Google Cloud, Oracle, Ericsson, and Snap. Within weeks it attracted 150+ contributors. AWS ElastiCache, Google Memorystore, and Azure Cache all migrated to Valkey as their default Redis-compatible engine.
-
Nov 2024
Antirez returns. Salvatore Sanfilippo (antirez), the original creator of Redis, rejoined Redis Ltd. and began advocating internally for a course correction on licensing.
-
May 2025
Redis 8 launches under AGPLv3. Redis Ltd. partially reversed course, releasing Redis 8 under a tri-license model (RSALv2 / SSPLv1 / AGPLv3). The AGPLv3 option is OSI-approved and genuinely open source — but its network copyleft clause means SaaS providers may need to open-source their application code when exposing Redis to external users. Major cloud providers have continued to back Valkey’s simpler BSD terms.
So What Is Dragonfly, and Why Does It Matter?
Dragonfly is not a fork of Redis. It is a ground-up reimplementation, created in 2022 by former Google and Amazon engineers, written in C++ with a fundamentally different architecture. While Redis uses a single-threaded event loop, Dragonfly uses a multi-threaded, shared-nothing model that assigns a dedicated thread per CPU core, eliminating the coordination overhead that plagues typical multi-threaded designs.
It is fully Redis-compatible at the protocol level: your existing Redis clients, connection strings, and most commands work without any code changes.
The memory efficiency advantage is particularly notable during snapshotting. Redis’s BGSAVE triggers copy-on-write mechanics that can temporarily nearly triple memory usage. Dragonfly uses async I/O (io_uring) for snapshots, avoiding the memory spike entirely.
As of 2025, Dragonfly has raised over $100 million in venture capital and operates a commercial managed service (Dragonfly Cloud) alongside the open-source version.
The Full Landscape: It’s Not Just Dragonfly
The narrative of “companies switching from Redis to Dragonfly” oversimplifies what is actually a broader ecosystem fragmentation. As of 2026, engineering teams have four credible options:
| Dimension | Redis 8 | Dragonfly | Valkey |
|---|---|---|---|
| Architecture | Single-threaded | Multi-threaded (per-core) | Single-threaded (Redis fork) |
| License | RSALv2/SSPL/AGPL | BSL 1.1 | BSD-3 (OSS) |
| Cloud default | No longer default | Dragonfly Cloud | AWS, GCP, Azure |
| Multi-core scaling | Requires clustering | Native, single node | I/O threads only |
| Memory efficiency | Baseline | ~80% less at rest | Similar to Redis |
| Redis protocol compat. | Full | High (some gaps) | Full (fork) |
| Best suited for | Existing Redis workflows, modules ecosystem | High-QPS, memory-constrained, single-node | Open-source drop-in, cloud-managed |
Note: Microsoft Garnet and KeyDB (acquired by Snap) are also active alternatives worth considering, especially for specific use cases like disk-backed storage or Kubernetes-native deployments.
Dragonfly’s Real Limitations
Dragonfly’s technical strengths are real, but the comparison isn’t one-sided. A few things to keep in mind before switching:
Dragonfly itself is not open source. It uses the Business Source License (BSL 1.1), which restricts commercial use in competing products. It converts to Apache 2.0 after a set number of years, but for now it has its own licensing constraints — a fact often omitted in promotional comparisons.
Module ecosystem gaps. Redis has a rich extension ecosystem (RedisJSON, RediSearch, RedisTimeSeries, etc.) that Dragonfly does not fully replicate. Teams relying on these modules need to evaluate compatibility carefully.
Maturity and edge cases. Redis has been production-battle-tested for 15+ years across billions of operations. Dragonfly, created in 2022, is newer and may present edge cases in complex cluster or persistence configurations.
At low concurrency, Redis 8 may win. Independent 2025 benchmarks show Redis 8 — with its up to 87% faster commands — leads on p95 latency for simple GET patterns at low concurrency. Dragonfly’s advantage becomes decisive at high concurrency and parallelism.
How to Actually Choose
Choose Valkey if…
You want a true open-source drop-in replacement, are running on AWS/GCP/Azure managed services, or just want to escape licensing uncertainty with minimal migration cost.
Choose Dragonfly if…
You need >200K QPS on a single node without cluster complexity, your system is memory-constrained, or you want to consolidate multiple Redis instances into one. Best for high-parallelism, throughput-intensive workloads.
Stay on Redis 8 if…
Your team relies on Redis-specific modules (RediSearch, RedisJSON, TimeSeries), your workload is low-concurrency, or you want the broadest ecosystem and longest production track record. The AGPLv3 option makes it genuinely open source again — with caveats for SaaS providers.
Test before you commit
Dragonfly and Valkey are both available as Docker images. Benchmark your actual workload — not synthetic benchmarks — before making a production decision. Switching is low-risk at the connection-string level; the unknowns are in edge-case behavior at scale.
The Verdict
The viral framing — “companies are abandoning Redis for Dragonfly” — captures real momentum but misrepresents the full picture. The biggest winner of the Redis licensing crisis is Valkey, now the default engine on all three major clouds. Dragonfly is a genuine architectural advancement with impressive benchmarks and real traction among teams with high-throughput needs. Redis itself is fighting back with Redis 8’s performance improvements and partial licensing correction.
What’s undeniably true: Redis’s era of unquestioned dominance is over. The in-memory database space is now a legitimate multi-player market for the first time in a decade. That’s good for engineers — and worth understanding clearly rather than through the lens of any single alternative’s marketing.
