Memcached, Redis, and Dragonfly are all in-memory data stores used for caching, but they diverge sharply on threading model, feature set, and licensing. The real question isn't which is fastest. It's when Memcached's simplicity is the right call, versus when you need Redis's data structures or Dragonfly's throughput. Most comparisons bury a fact that should shape your decision early, which is that none of the three tools share a license category. Memcached is BSD, Redis 8 lets you choose between three licenses including AGPLv3, and Dragonfly runs on the Business Source License.
Quick comparison: memcached vs Redis vs Dragonfly
Licensing: the sharpest three-way split
None of the three tools land in the same licensing category. Memcached's license hasn't changed since Danga Interactive released it in 2003. Its LICENSE file grants redistribution "in source and binary forms, with or without modification," under standard BSD-3-Clause terms. It's fully permissive and OSI-approved, with no restrictions on running it as a managed service.
Redis is more complicated. Redis Community Edition versions 7.4 through 7.8 ship under a choice of RSALv2 or SSPLv1. Per Redis's own licensing page, RSALv2 is "a permissive, non-copyleft license created by Redis Ltd." that lets you "use, copy, distribute, make available, and prepare derivative works of the software," but you may not "commercialize the software or provide it to others as a managed service." SSPLv1, created by MongoDB, allows "free and unrestricted use, modification, and redistribution," but if you offer the product as a service you must publicly release your management-layer source code under SSPL too. Redis states plainly that neither license is open source.
Starting with Redis Open Source 8.0, Redis added a third option. Its licensing page states that Redis 8 versions "are available under our tri-license, allowing us to be both source-available and open source software. Our tri-license includes RSALv2, SSPLv1, and AGPLv3." AGPLv3 is the OSI-approved option of the three. Redis is explicit that adding it didn't reverse the 2024 move to source-available licensing. All three options still coexist, and you pick one.
Dragonfly sits in a third position. Its LICENSE.md states plainly that it runs under Business Source License 1.1. The Additional Use Grant clause blocks you from offering Dragonfly "as a Service" if that service would compete with Dragonfly's own commercial offerings, a definition broad enough to cover SaaS, PaaS, and IaaS products. Like other BSL projects, the restriction is temporary and rolls off per version. Dragonfly's license converts to Apache 2.0 "on the Change Date, or the fourth anniversary of the first publicly available distribution of a specific version," whichever comes first. The current LICENSE.md lists a Change Date of July 1, 2030 for the version in question.
Does Redis 8's AGPLv3 license affect self-hosted use?
For most teams, no. Redis's own FAQ answers this directly: "If you are switching from Redis Community Edition (version 7.4.x or later) or from Redis Stack to Redis 8 the answer is simple: No." You pick RSALv2, SSPLv1, or AGPLv3 for your use of Redis 8, and internal self-hosted use isn't affected by which one you choose. AGPLv3's obligations mainly trigger if you redistribute modified Redis code or offer it as a network server to third parties. In that case, "the operators of those servers are required to provide the source code of the modified version running there to the users of that server." Redis Inc. announced the AGPLv3 option on May 1, 2025, tying it explicitly to the Redis 8.0 GA release. Some organizations still avoid AGPLv3 on policy grounds regardless of the legal detail. AWS notes that "many organizations strictly forbid the adoption of software licensed under AGPLv3 due to its legal and commercial risks."
Is Dragonfly's BSL license the same as source-available Redis?
No, though it's a similar posture. Dragonfly's LICENSE.md grants you "the right to copy, modify, create derivative works, redistribute, and make non-production use of the Licensed Work," with production use permitted only under the Additional Use Grant's SaaS-competition carve-out. Dragonfly isn't BSD-permissive like Memcached, and it isn't OSI-open like Redis 8's AGPLv3 option. It's source-available with a commercial restriction closer in spirit to Redis's pre-AGPLv3 RSALv2/SSPLv1 stance than to either of the other two positions.
Architecture and performance
Memcached and Dragonfly are both natively multi-threaded. Redis is single-threaded for command execution, with I/O threading added in version 6.0 to handle socket I/O only. Dragonfly is effectively Memcached's threading model paired with Redis's feature set, keeping Memcached's multi-core design while supporting Redis's command surface.
Why is Redis single-threaded while Memcached and Dragonfly are not?
AWS describes Memcached's design plainly: "Since Memcached is multithreaded, it can make use of multiple processing cores. This means that you can handle more operations by scaling up compute capacity." Redis runs a single-threaded event loop for command execution, adding I/O threads in 6.0 purely for socket handling, not for the commands themselves. This gives Redis atomicity without locking, at the cost of not scaling command throughput across cores on a single instance.
Dragonfly took a different route to get multi-core scaling without giving up Redis-style atomicity. Its README explains that it uses "shared-nothing architecture, which allows us to partition the keyspace of the memory store between threads so that each thread can manage its own slice of dictionary data." These slices are called shards. The underlying hashtable is based on the academic paper "Dash: Scalable Hashing on Persistent Memory," and Dragonfly credits a second paper, on VLL lock management, for letting it "compose atomic multi-key operations without using mutexes or spinlocks."
How much faster is Dragonfly than Redis in benchmarks?
There's no single agreed-upon multiplier here. The numbers depend heavily on hardware and workload. The OneUptime engineering blog, an independent source with disclosed hardware, ran Redis and DragonflyDB on an AWS c6g.16xlarge instance with 64 vCPUs.
Dragonfly's README states the comparison directly: on "the most network-capable instance c6gn.16xlarge, Dragonfly showed a 25X increase in throughput compared to Redis single process, crossing 3.8M QPS." Its vendor comparison page separately publishes a YCSB-based table on the same instance type showing 17x to 25x improvements depending on workload mix. Those two vendor-reported methodologies converge on a similar 17x-25x range, while OneUptime's independent test on different hardware lands closer to 5x. Dragonfly's throughput advantage over single-process Redis has been measured anywhere from roughly 5x to 25x depending on instance type, workload, and who ran the test. Redis can close some of that gap by scaling out across more instances rather than one bigger box.
How does Memcached compare to Dragonfly on raw throughput?
Dragonfly's own README publishes a direct SET/GET comparison against Memcached on a c6gn.16xlarge instance.
Dragonfly wins on throughput in both directions, but the GET latency result is worth keeping rather than flattening into a simple "Dragonfly wins everything" story. The README says it directly, noting that "Memcached exhibited lower latency for the read benchmark, but also lower throughput." Memcached's write-path contention is offered as the explanation for its slower SET latency, with Dragonfly showing "better latency in write workloads due to contention on the write path in Memcached."
Benchmark methodology in this space is inconsistent. Different sources cite different throughput multipliers for Dragonfly versus Redis, with no shared hardware, workload, or test harness disclosed between them, and write-up quality varies widely. Treat any single benchmark number, including the ones above, as a data point tied to a specific instance type and workload rather than a general truth about either system.
Feature and data-model comparison
Dragonfly's README describes a memory-efficiency test where it and Redis were both filled with roughly 5GB of data, sent update traffic, and snapshotted with bgsave. Dragonfly reported being "30% more memory efficient than Redis in the idle state," with Redis memory use rising "to almost 3X that of Dragonfly" at peak. That's a Dragonfly-reported number from Dragonfly's own documentation, worth treating the same way as the vendor benchmarks above.
Don't read Dragonfly's Redis-compatible REPLICAOF command as full parity with Redis's own replication internals. Dragonfly's README places native replication on its roadmap, describing plans to design "a distributed log format that will support order-of-magnitude higher speeds." That's a forward-looking statement about what Dragonfly is still building, not a description of a shipped, mature replication system.
Command coverage also has a wrinkle. Dragonfly's README gives two slightly different figures in different places: "~185 Redis commands and all Memcached commands besides cas," and separately "roughly equivalent to Redis 5.0 API." Take the vendor's own self-reported figure as authoritative rather than any third-party recount, since command-coverage claims vary between sources.
Is Dragonfly a drop-in replacement for Redis?
Yes, for the core command set. Dragonfly's README states it directly, noting it's "fully compatible with Redis and Memcached APIs" and "requires no code changes to adopt." That covers strings, hashes, lists, sorted sets, and pub/sub, but it's less of a drop-in at the edges. OneUptime's list of Dragonfly's limitations includes being "less mature than Redis (launched 2022 vs Redis 2009)," having "fewer modules compared to Redis Stack," and noting "some Redis Cluster-specific commands differ." Dragonfly's README doesn't mention support for Redis Stack modules like RediSearch or RedisJSON anywhere in its command-coverage description, which lines up with the module gap OneUptime flags. If your application depends on those modules or on exact Redis Cluster hash-slot behavior, verify compatibility directly rather than assuming parity.
Migrating off Memcached without a hard cutover
Dragonfly has a documented feature that no competing Memcached-vs-Redis comparison covers, a genuine, gradual migration path off Memcached built into the product itself. Enable it with the memcached_port flag, which is disabled by default.
./dragonfly --logtostderr --memcached_port 11211
Once running, Dragonfly listens on both ports at once, serving the Memcached protocol and the Redis protocol simultaneously. The key detail that makes this useful for migration is keyspace sharing. Dragonfly's docs state that "the Memcached API shares the same keyspace with the Redis API logical database 0. This is a designed behavior, which allows your backend services using different APIs to operate on the same set of data." That means you can gradually migrate individual services away from the Memcached API rather than doing a hard cutover.
There's a real limitation to watch for. Dragonfly's docs warn that "Memcached doesn't support complex data types (lists, sets, sorted sets, hashes, etc.), and it's not recommended to mix up operations from both APIs other than on the string data type." The official docs walk through exactly what happens across databases.
# === Redis API === #
# Set a key in database '0', which is the default database.
dragonfly$> SET my_key_db_ZERO 1000
OK
# Switch to database '1'.
dragonfly$> SELECT 1
OK
# Set a key in database '1'.
dragonfly$> SET my_key_db_ONE 1000
OK
# === Memcached API === #
# This works since the key exists in database '0'.
dragonfly-memcached$> get my_key_db_ZERO
VALUE my_key_db_ZERO 0 4
1000
END
# The key is not found since it only exists in database '1'.
dragonfly-memcached$> get my_key_db_ONE
END
The Memcached API can only ever see keys living in Redis logical database 0. Anything set in database 1 or higher via the Redis API is invisible to Memcached clients. If your migration plan involves multiple Redis logical databases, keep that boundary in mind.
When simple caching is enough: a decision framework
Choose Memcached if you only need simple key-value caching
- Your workload is pure GET/SET with no need for data structures beyond strings
- You want the simplest possible caching layer with the fewest things to configure
- You need to maximize throughput per CPU core on a single server
- You don't need data to survive a restart, since Memcached has no persistence
- You want a BSD-licensed tool with zero licensing questions
- You want a dead-simple protocol that's easy to implement and debug, and battle-tested at extreme scale
Choose Redis if you need data structures, persistence, or an ecosystem
- You need data structures like sorted sets, lists, or hashes in your cache
- You need cached data to survive server restarts, via RDB snapshots, AOF logging, or both
- You need pub/sub messaging, event streaming, or server-side scripting for atomic multi-step operations
- You need built-in high availability with automatic failover, via Sentinel or Cluster
- You want the largest managed-service ecosystem: AWS ElastiCache and MemoryDB, Azure Cache, GCP Memorystore, Redis Cloud, and Upstash all offer it
- You can accept, or actively want, the AGPLv3 option among Redis's tri-license choices, and you value 15+ years of production use
Choose Dragonfly if you need Redis's features with more throughput per box
- You're running on large multi-core servers, 16 or more cores, and want to reduce instance count or simplify a Redis Cluster
- Your workload is command-compatible with Dragonfly's subset and doesn't lean on Redis Stack modules or Cluster-specific commands that differ
- Memory cost reduction is a priority for your caching layer
- You want a documented, gradual path to migrate off Memcached via memcached-compatible mode, rather than a hard cutover
- You're comfortable with a project that's less mature than Redis, launched in 2022 versus Redis's 2009, and runs under a source-available BSL license rather than a fully open one
Frequently asked questions
Is Memcached still relevant in 2026?
Yes, for specific use cases. Memcached "is still the better choice when you need a pure cache with the lowest possible memory overhead per key and maximum throughput on multi-core machines," and Meta "still runs one of the largest Memcached deployments in the world." If your use case is strictly caching, without persistence, data structures, or pub/sub, Memcached does less but does it efficiently.
Do I need Redis or is Memcached enough?
If you only ever call GET and SET, Memcached is enough. The moment you need anything beyond opaque string values, such as sorted sets, lists, or hashes, or you need data to survive a restart, you need Redis or Dragonfly. One summary puts it plainly, "Choose Redis when you need more than a simple cache - session storage, rate limiting, leaderboards, queues, or pub/sub. Choose Memcached when you need a lightweight, efficient caching layer and want the simplest possible operational footprint."
Does Redis's AGPLv3 license affect me if I just self-host it?
No. Self-hosting internally is unaffected by which of the three license options applies to your Redis installation. Redis's own FAQ confirms that teams upgrading from Redis Community Edition 7.4.x or later, or from Redis Stack, to Redis 8 are not impacted. AGPLv3's obligations mainly trigger if you redistribute modified code or run it as a network service that others use directly.
Can Dragonfly fully replace Redis Cluster?
For many teams, yes, in the sense that a single DragonflyDB instance on a large EC2 box can replace a Redis Cluster of six nodes, collapsing a multi-node cluster into one large multi-core box. Be cautious about the replication story specifically. Dragonfly supports Redis-compatible replication commands like REPLICAOF, but its own README frames native replication internals as still being designed, describing plans to build "a distributed log format that will support order-of-magnitude higher speeds." Don't assume full parity with Redis's mature replication and failover tooling without testing your specific setup.
Which is faster, Memcached or Redis, for simple GET/SET?
Memcached, generally, due to its native multi-threading. "Memcached's multi-threaded architecture can deliver higher throughput on a single server for simple get/set workloads," and "if you do not need data structures or persistence, Memcached gives you more cache per dollar." Memcached also tends to use less memory per key for simple string values, thanks to its slab allocator. Redis narrows some of this gap through pipelining and its I/O-threaded architecture, but for plain, unpipelined single-command GET/SET traffic, Memcached's multi-core design gives it an edge.
The bottom line
Reach for Memcached when you want the simplest possible cache and nothing else, pure key-value GET/SET, no persistence, no licensing questions, and maximum throughput per core. Reach for Redis when you need data structures, persistence, pub/sub, scripting, or the maturity and managed-service ecosystem that 15+ years of production use has built up, and you're comfortable choosing a license from its tri-license set. Reach for Dragonfly when you want Redis's feature set with Memcached's threading model, particularly if you're trying to collapse a Redis Cluster into fewer, bigger multi-core nodes, and you're comfortable with a newer, source-available project instead of Redis's longer track record.