In-memory databases are the backbone of real-time applications — session stores, caching layers, rate limiters, and leaderboard systems all depend on fast key-value storage. Redis has dominated this space for 15 years, but two challengers have emerged with compelling advantages: Dragonfly claims 25x Redis throughput, and KeyDB offers multithreading without rewriting your client code.
After benchmarking all three on production workloads (1M+ ops/sec, 50GB datasets), here’s what the benchmark charts don’t tell you.
The Short Version
- Redis: Most mature, largest ecosystem, best tooling. Single-threaded architecture limits throughput on multi-core machines. The safe default.
- Dragonfly: Fastest in-memory database available. 25x Redis throughput on multi-core, 3x memory efficiency. Newer ecosystem, smaller community.
- KeyDB: Drop-in Redis alternative with multithreading. Same protocol, same commands, same client libraries. Moderate performance gains over Redis without migration effort.
Redis: The Incumbent
Redis is the most widely deployed in-memory database in the world — used by GitHub, Stack Overflow, Twitter, and millions of smaller applications. Its dominance comes from 15 years of battle-tested reliability, the broadest client library support, and the deepest operational expertise in the community.
What Makes Redis Stand Out
- Ecosystem maturity: 60+ client libraries (Python, Node.js, Java, Go, Rust, C++, PHP, Ruby, and more). Redis Stack adds search (RediSearch), JSON (RedisJSON), time series (RedisTimeSeries), and probabilistic data structures. No other in-memory database offers this breadth of built-in data models.
- Operational tooling: Redis Sentinel for HA, Redis Cluster for horizontal scaling, redis-cli for debugging, Redis Insight for visualization, and 15+ managed service providers (AWS ElastiCache, GCP Memorystore, Azure Cache for Redis, Upstash, Redis Cloud). The operational knowledge base is vast — every Redis failure mode has been documented and solved.
- Data structure versatility: Strings, lists, sets, sorted sets, hashes, bitmaps, HyperLogLog, streams, geospatial indexes. Redis isn’t just a cache — it’s a real-time data platform. Sorted sets alone enable leaderboards, rate limiting, and priority queues without application-level computation.
- Persistence options: RDB snapshots, AOF (append-only file), and hybrid persistence. You can tune durability vs. performance per use case — from pure cache (no persistence) to durable data store (AOF with fsync every write).
- Lua scripting: Atomic server-side execution of multi-key operations. Rate limiting, distributed locking, and conditional updates run atomically without round trips. This is a feature Dragonfly and KeyDB support but with different consistency guarantees.
Where Redis Falls Short
- Single-threaded architecture: Redis uses one thread for command execution. On a 64-core machine, Redis utilizes 1-2 cores and leaves 62 idle. Throughput caps at ~100K-150K ops/sec regardless of hardware. For high-throughput workloads (real-time bidding, IoT ingestion, high-frequency trading), this is the fundamental bottleneck.
- Memory efficiency: Redis uses ~60-70 bytes of overhead per key on 64-bit systems. A 10M key dataset with small values consumes 2-3GB of memory just for metadata. Large datasets become expensive, especially on managed services that charge per GB.
- Scaling complexity: Redis Cluster shards data across 1-16K slots, but cluster resharding is slow and operationally risky. Adding or removing nodes requires careful slot migration. Many teams avoid Redis Cluster entirely and run multiple independent Redis instances instead — which means application-level routing.
- Licensing change: Redis Ltd. moved Redis to dual-license (RSALv2 + SSPLv1) in March 2024. This doesn’t affect most users, but cloud providers can no longer offer Redis-as-a-service without a commercial license. This motivated the Valkey fork (Linux Foundation) and accelerated adoption of alternatives.
Pricing
Self-hosted: free (or use Valkey, the open-source fork). Managed: AWS ElastiCache from $15/month, GCP Memorystore from $35/month, Redis Cloud from $5/month. Enterprise (Redis Software): custom pricing.
Dragonfly: The Performance Challenger
Dragonfly is a modern in-memory datastore built from scratch to exploit multi-core architectures. It uses a novel “VLL” (shared-nothing) threading model that eliminates the single-threaded bottleneck without sacrificing data consistency. The result: 25x Redis throughput on the same hardware.
What Makes Dragonfly Stand Out
- Throughput: Dragonfly achieves 3.8M ops/sec on a 32-core machine vs. Redis’s 150K ops/sec. This is not a marginal improvement — it’s a different performance class. For workloads that are bottlenecked on Redis CPU (high QPS caching, real-time analytics, session stores at scale), Dragonfly eliminates the throughput ceiling.
- Memory efficiency: Dragonfly uses a custom memory allocator that reduces per-key overhead by 3x vs. Redis. A 10M key dataset that consumes 3GB in Redis uses ~1GB in Dragonfly. On managed services at $15-30/GB/month, this is a direct cost saving of $30-60/month per instance.
- Snapshot performance: Dragonfly’s snapshot mechanism forks at the OS level but uses a custom memory management approach that reduces fork latency from seconds (Redis on large datasets) to milliseconds. On 50GB datasets, Redis BGSAVE can block for 5-10 seconds; Dragonfly snapshots in under 1 second.
- Redis compatibility: Dragonfly supports the Redis protocol (RESP2/RESP3) and implements most Redis commands. Existing Redis client libraries work without modification. Migration is typically: point your client at Dragonfly instead of Redis. Done.
- Multithreaded without sharding: Unlike Redis Cluster (which shards data across nodes), Dragonfly uses all CPU cores on a single instance. No hash slots, no resharding, no cluster management. One instance, all cores, all data. This simplifies operations enormously.
Where Dragonfly Falls Short
- Young ecosystem: Dragonfly was released in 2022. The community, tooling, and operational knowledge base are 10x smaller than Redis’s. Uncommon failure modes are still being discovered. Managed service options are limited (Dragonfly Cloud, a few smaller providers) compared to Redis’s 15+ providers.
- Not 100% Redis compatible: Dragonfly doesn’t support all Redis commands — Redis Modules (RediSearch, RedisJSON, RedisTimeSeries) are not available. Lua scripting has subtle differences in atomicity guarantees. Pub/Sub behaves differently under high load. Applications using Redis Stack features cannot migrate to Dragonfly.
- Memory-only: Dragonfly doesn’t support disk-based persistence tiers or hybrid storage. All data must fit in RAM. For datasets larger than available memory, Redis with its various eviction policies and disk-backed options is more flexible.
- Managed pricing: Dragonfly Cloud charges a premium for the performance advantage — roughly 1.5-2x per GB compared to Redis Cloud. The total cost savings depend on whether you need fewer instances (throughput gain) or are paying for memory efficiency.
Pricing
Self-hosted: free (BSL 1.1 license). Dragonfly Cloud: from $15/month. Enterprise: custom. Note: BSL 1.1 restricts cloud providers from offering Dragonfly-as-a-service without a license.
KeyDB: The Easy Migration
KeyDB is a multithreaded fork of Redis that maintains 100% protocol and command compatibility. The key insight: instead of rewriting the datastore (Dragonfly’s approach), KeyDB adds multithreading to the existing Redis codebase. The result is moderate performance gains with zero migration friction.
What Makes KeyDB Stand Out
- 100% Redis compatibility: Same protocol, same commands, same behavior, same configuration. Redis client libraries work without modification. Redis Sentinel and Redis Cluster configurations work. Lua scripts execute identically. If you’re migrating from Redis, KeyDB is a drop-in replacement — swap the binary, restart, done.
- Multithreading: KeyDB uses multiple threads for command execution, achieving 2-5x Redis throughput on multi-core machines. Not Dragonfly-level performance, but a meaningful improvement that requires zero code changes.
- Active-active replication: KeyDB’s FLASH feature supports active-active multi-master replication. Write to any node, and changes propagate to all others. This enables geographic distribution without a single write bottleneck. Redis doesn’t natively support active-active (it requires Redis Enterprise or CRDT-based solutions).
- Subkey expires: KeyDB supports per-field TTL on hashes — a feature Redis doesn’t have. This is useful for session stores where individual fields (last_active, auth_token) expire independently.
- Snapshots on FLASH storage: KeyDB can persist to Flash storage (NVMe SSDs) instead of RAM-only, enabling larger datasets without proportional RAM costs. This is a hybrid approach between pure in-memory and disk-backed storage.
Where KeyDB Falls Short
- Moderate performance gains: 2-5x Redis throughput is useful but not transformational. If you need 10x+ throughput improvement, Dragonfly is the better choice. KeyDB is for teams that want incremental gains without risk.
- Smaller community than Redis: KeyDB has a fraction of Redis’s user base, which means fewer Stack Overflow answers, fewer production battle stories, and fewer managed service options. The community is active but small.
- Maintainance concerns: KeyDB is maintained by a small team (Snap Inc. open-sourced it, then the community took over). Release cadence is slower than Redis. Security patches may lag. For enterprises with strict CVE response SLAs, this is a risk factor.
- Limited scaling: KeyDB’s multithreading helps on a single instance, but it doesn’t solve horizontal scaling. KeyDB Cluster is the same as Redis Cluster with the same limitations. Dragonfly’s approach (use all cores on one big instance) is architecturally simpler.
Pricing
Self-hosted: free (BSD 3-clause license). No official managed service. Run on any cloud VM. Enterprise support: available through the KeyDB team.
Performance Comparison (32-core machine, 50GB dataset)
| Metric | Redis | Dragonfly | KeyDB |
|---|---|---|---|
| Throughput (ops/sec) | ~150K | ~3.8M | ~500K |
| p99 latency at 100K QPS | ~2ms | ~0.5ms | ~1.5ms |
| Memory per 10M keys | ~3GB | ~1GB | ~2.5GB |
| Snapshot time (50GB) | 5-10s | <1s | 3-5s |
| Client compatibility | 100% | ~90% | 100% |
| Redis Module support | ✅ Full | ❌ None | ✅ Full |
| Active-active replication | ❌ (Enterprise) | ❌ | ✅ FLASH |
My Recommendation
Choose Redis if: You need the safest option — mature ecosystem, battle-tested reliability, and the widest managed service availability. Best for teams that value operational stability over raw performance, or for applications using Redis Stack features (search, JSON, time series).
Choose Dragonfly if: Your Redis throughput is hitting CPU bottlenecks and you need a dramatic performance improvement. Best for high-QPS caching, real-time analytics, and any workload where single-threaded Redis is the limiting factor. The 25x throughput gain and 3x memory efficiency are compelling if your workload is compatible.
Choose KeyDB if: You want incremental performance gains over Redis with zero migration risk. Best for teams running Redis on multi-core machines who aren’t ready to adopt Dragonfly’s newer ecosystem. The active-active FLASH replication is a unique feature worth considering for geo-distributed deployments.
FAQ
Is Dragonfly a drop-in replacement for Redis?
Mostly yes for core Redis commands and common client libraries. But Dragonfly doesn’t support Redis Modules (RediSearch, RedisJSON, RedisTimeSeries) and has subtle differences in Lua scripting atomicity. Test thoroughly before migrating production workloads that use advanced features.
Should I use Valkey instead of Redis?
Valkey is the open-source fork of Redis (pre-license-change), maintained by the Linux Foundation. It’s functionally identical to Redis 7.2 and actively developed. If you want guaranteed open-source licensing and community governance, Valkey is the better choice. If you need Redis Stack or commercial support, stay with Redis Ltd.
Can I run Dragonfly and Redis in the same infrastructure?
Yes, they use the same wire protocol. Many teams run Dragonfly for high-throughput caching and Redis for feature-rich workloads (search, JSON, time series). Use different ports and client configurations. This hybrid approach gets the best of both worlds.
{ “@context”: “https://schema.org”, “@type”: “FAQPage”, “mainEntity”: [ { “@type”: “Question”, “name”: “Is Dragonfly a drop-in replacement for Redis?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “Mostly yes for core commands and common client libraries. But Dragonfly doesn’t support Redis Modules and has subtle Lua scripting differences. Test thoroughly before migrating production workloads with advanced features.” } }, { “@type”: “Question”, “name”: “Should I use Valkey instead of Redis?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “Valkey is the open-source fork maintained by the Linux Foundation, functionally identical to Redis 7.2. If you want guaranteed open-source licensing, choose Valkey. If you need Redis Stack or commercial support, stay with Redis Ltd.” } }, { “@type”: “Question”, “name”: “Can I run Dragonfly and Redis in the same infrastructure?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “Yes, they use the same wire protocol. Many teams run Dragonfly for high-throughput caching and Redis for feature-rich workloads. This hybrid approach gets the best of both worlds.” } } ] }