Dragonfly DB Over Redis:The Future of In-Memory Datastores
Dragonfly DB Over Redis:The Future of In-Memory Datastores
Redis changed its license twice in a year. Valkey took over every major cloud. DragonflyDB now hits 3.8 million QPS on a single node. Here is everything your team needs to know.
01What is Redis and why does it still matter?
Redis (Remote Dictionary Server) is an open-source, in-memory data structure store created by Salvatore Sanfilippo in 2009. For over a decade it has been the de-facto standard for caching, session management, pub/sub messaging, and real-time leaderboards. Its API is simple, its community is vast, and its ecosystem spans virtually every programming language.
Redis's atomic, single-threaded event loop means every command executes fully before the next begins — no locks, no contention, and highly predictable latency. It uses I/O multiplexing to handle thousands of concurrent connections without multi-threading.
Strings, Hashes, Lists
Core primitives for counters, objects, and ordered data.
Sets & Sorted Sets
Tag indexes, leaderboards, and range queries.
Pub/Sub & Streams
Event pipelines and real-time messaging at scale.
Geo-spatial Indexes
Radius queries and proximity-based lookups.
Bitmaps & HyperLogLog
Compact cardinality estimation and bit operations.
Vector Sets
Native vector similarity search for AI and ML workloads.
Persistence options include RDB snapshots, Append-Only File (AOF) logging, or no persistence at all. TTL-based expiry, LRU eviction, Lua scripting, and transactions via MULTI/EXEC complete a feature set that has kept Redis relevant for fifteen years.
02The 2025 Redis ecosystem: license drama, Valkey & Redis 8
Understanding the current landscape requires knowing what happened to Redis over the past eighteen months — arguably the most disruptive period in its history.
The Redis ecosystem shifted dramatically between March 2024 and May 2025.
What this means for your teamRedis 7.2 and below remain BSD-licensed and can be used indefinitely. Redis 8 AGPLv3 is OSI-approved but its network copyleft clause means SaaS services exposing Redis 8 to external users may need to open-source their application code. For internal caching, it is usually fine.
03What is DragonflyDB?
Founded in March 2022 by Oded Poncz and Roman Gershman — former Google engineers — DragonflyDB was built from scratch to solve the scaling limits they experienced firsthand. Written in C++ and designed around a fundamentally different concurrency model, it is not a Redis fork.
Dragonfly is fully compatible with both the Redis protocol and Memcached protocol. In pipeline mode it reaches 10 million QPS for SET and 15 million QPS for GET on the same hardware. At peak throughput, P99 latency stays below 1ms.
"A single DragonflyDB instance can replace an entire Redis cluster for many production workloads — with zero application code changes."
04Architecture: single-thread vs. multi-thread
Redis routes all commands through one thread. Dragonfly assigns each shard its own dedicated CPU core.
Redis: single-threaded event loop
Redis processes all commands in a single thread using I/O multiplexing. This guarantees command atomicity without locks and is efficient at low concurrency — but the single thread becomes a CPU bottleneck as traffic scales. Redis scales horizontally via clustering, which adds network round-trips, rebalancing overhead, and data-loss risk during mismanaged failovers.
DragonflyDB: shared-nothing multi-threaded sharding
Dragonfly splits its keyspace into independent shards, each owned by a dedicated thread on a separate CPU core. No shard shares memory with another — no mutexes, no lock contention. Threads run fully in parallel, allowing Dragonfly to scale vertically as you add CPU cores without a cluster.
For disk I/O, Dragonfly uses io_uring — Linux's modern async I/O interface — so snapshots never block the event loop. During BGSAVE, Redis memory can spike to nearly 3× normal usage via copy-on-write. Dragonfly's memory during the same event is flat.
| Property | Redis 7 / 8 | DragonflyDB | Valkey |
|---|---|---|---|
| Threading model | Single-threaded + I/O threads | Multi-threaded, shared-nothing | Single-threaded (Redis-style) |
| Max QPS (single node) | ~150–200K | 3.8M+ (25× Redis) | ~200K |
| Memory efficiency | Baseline | 30–80% lower | Similar to Redis |
| Snapshot memory spike | Up to 3× during BGSAVE | Negligible — io_uring async | Similar to Redis |
| Redis API compatibility | 100% (it is Redis) | Very high, growing | 100% (Redis fork) |
| License | AGPLv3/SSPL/RSAL (v8), BSD (v7) | BSL 1.1 | BSD |
| Horizontal clustering | Mature Redis Cluster | In development | Mature, Redis-compatible |
05Benchmark results: throughput, latency & memory
All benchmarks use memtier_benchmark on AWS Graviton2/3 instances with 10 million pre-populated keys, run on c6gn.16xlarge network-optimised instances. Always test with your own workload mix before migrating.
Throughput — SET operations (QPS)
Note: Redis 8 claims up to 2× throughput over Redis 7 in its own benchmarks on different hardware. On identical hardware Dragonfly still leads by approximately 15–20×.
Throughput, P99 tail latency, and memory efficiency during snapshotting — DragonflyDB vs Redis benchmark results.
P99 tail latency at peak throughput
Despite operating at 25× the QPS of Redis, Dragonfly maintains P99 latency below 1ms across SET, GET, and SETEX. Independent 2025 benchmarks show Redis 8 leads on p95 latency for simple GET patterns at low concurrency, while Dragonfly leads on throughput and memory efficiency. Valkey leads on batched pipeline workloads.
Memory during snapshotting
Redis's BGSAVE triggers copy-on-write mechanics that can nearly triple memory usage during the snapshot window — a serious risk on memory-constrained instances. Dragonfly is 30% more memory-efficient at idle and shows no visible spike during snapshotting. At peak, Redis memory during BGSAVE reached almost 3× Dragonfly's usage in controlled tests.
064-way comparison: Redis 8, Dragonfly, Valkey, KeyDB
| Use case | Winner | Reason |
|---|---|---|
| Raw write throughput | DragonflyDB | Multi-threaded sharding, best single-node QPS |
| Read throughput (cache hits) | DragonflyDB | Scales with cores; Redis single thread saturates early |
| Batched / pipeline requests | Valkey | Leads pipeline benchmarks clearly |
| P95 read latency (simple GET) | Redis 8 | Consistently lowest p95; Dragonfly slightly higher |
| Memory efficiency | DragonflyDB | 30–80% lower vs Redis; no spike during snapshots |
| Ecosystem & modules | Redis 8 | JSON, Search, TimeSeries in core; biggest community |
| Cloud-managed service | Valkey | Default on AWS, GCP, Azure; no AGPL concern |
| Vertical scale without cluster | DragonflyDB | Single instance replaces multi-node cluster for many workloads |
07Decision guide: which should you choose?
Choose DragonflyDB when
- You need >200K QPS on a single node without cluster complexity
- Memory footprint is a cost concern — saves 30–80%
- You are migrating off Redis with zero code changes
- Snapshotting memory spikes are hitting production
- You are building AI inference caching or LLM pipelines
- You want vertical scaling simplicity over cluster ops
Stick with Redis or Valkey when
- You rely on RedisGraph, RedisTimeSeries, or deep module integrations
- You need mature Redis Cluster semantics
- You are on a managed cloud — use Valkey, it is the default
- Your workload is heavily pipeline-batched — Valkey leads there
- P95 read latency on simple patterns is your primary metric
- Existing Redis 7.2 BSD deployments are running fine
The pragmatic 2025 verdictSelf-hosted high-throughput workloads: DragonflyDB wins. Cloud-managed: use Valkey — AWS, Google, and Azure have standardised on it. AI workloads needing Vector Sets or bundled Search/JSON: Redis 8, subject to AGPLv3 compliance review.
08Migration guide: Redis to DragonflyDB in 5 steps
Migrating from Redis to DragonflyDB requires zero code changes to your application. The two paths are live replication (zero downtime) and RDB file import.
Option A — Live replication (recommended, zero downtime)
Map it to an alternative port during testing.
docker run -p 6380:6379 docker.dragonflydb.io/dragonflydb/dragonflyDragonfly syncs all data from your live Redis instance.
redis-cli -p 6380 REPLICAOF 6379 redis-cli -p 6380 INFO replication
# Look for: master_link_status:up
# And: master_sync_in_progress:0Stop writes to Redis, promote Dragonfly, then update your app connection string.
redis-cli -p 6380 REPLICAOF NO ONEcurl http://localhost:6380/metricsOption B — RDB snapshot import
# 1. Dump Redis to file
redis-cli BGSAVE
# 2. Copy snapshot to Dragonfly data directory
cp /var/lib/redis/dump.rdb /var/lib/dragonfly/
# 3. Start Dragonfly pointing at that directory
dragonfly --dbfilename dump.rdb --dir /var/lib/dragonfly/09Frequently asked questions
Is DragonflyDB faster than Redis?
Can I use DragonflyDB as a drop-in replacement for Redis?
What is Valkey and how does it differ from DragonflyDB?
What happened to the Redis open-source license?
Does DragonflyDB support persistence?
When should I choose Redis 8 over DragonflyDB?
Need help choosing the right in-memory datastore for your stack?
Auriga IT helps engineering teams evaluate, migrate, and optimise backend infrastructure — from Redis and DragonflyDB to full-stack application development. If your datastore is becoming a bottleneck, let's talk.
Related content
Auriga: Leveling Up for Enterprise Growth!
Auriga’s journey began in 2010 crafting products for India’s [...]
