Redis vs Dragonfly vs KeyDB — Which In-Memory Cache in 2026

The Redis ecosystem got complicated. In 2024, Redis changed its license from BSD to BUSL (Business Source License), preventing cloud providers from offering it as a managed service without licensing agreements. AWS, Google, and others forked it into Valkey. Meanwhile, Dragonfly and KeyDB have been building multi-threaded Redis alternatives for years.

In 2026, the choice isn't just "which is fastest" — it's also "which can I actually use in production without licensing concerns."

The Quick Picture

Redis

Redis (Remote Dictionary Server) is the original. 15+ years old, battle-tested, and the default choice when anyone says "add a cache."

What changed with BUSL

The BUSL license means:

• Free to self-host for most purposes
• Cannot be offered as a commercial managed service (affects AWS, Google, etc.)
• Converts to open source after a "change date" (4 years from release)
• For end-users running Redis internally: no impact

If you're running Redis yourself and not reselling it as a service — BUSL doesn't affect you.

Redis 8.x (2026)

• Improved memory efficiency
• Better multi-threading for I/O (command execution still single-threaded)
• Redis Stack bundles Search, JSON, TimeSeries, Bloom filters
• Redis 8 integrated some Redis Stack modules into the main binary

Managed options

• Redis Cloud (Redis's own managed service) — fully supported
• AWS ElastiCache for Redis — yes, AWS still offers it (separate licensing agreement)
• GCP Memorystore for Redis — same

When to use Redis

• You want maximum ecosystem support (clients, libraries, integrations)
• You use Redis-specific features: Streams, Lua scripting, Keyspace notifications
• You need Redis Stack: full-text search, vector search, JSON, time series
• Your team has deep Redis operational expertise

Valkey

Valkey is the community fork of Redis 7.2 (the last BSD-licensed version), maintained by the Linux Foundation. Major contributors: AWS, Google, Ericsson, Snap.

What it is

Valkey started as a drop-in replacement for Redis with BSD licensing. In 2026, Valkey 8.x has diverged from Redis in some areas, with performance improvements and new features.

Key features

• Full Redis 7.2 API compatibility
• Improving performance (cluster mode optimizations, better I/O threading)
• Official support from major cloud providers
• Valkey 8.0 added dual-channel replication (faster replication on high-throughput systems)

Managed options

• AWS ElastiCache (Valkey flavor — now the recommended option on AWS)
• GCP Memorystore for Valkey
• Azure Cache for Redis (still Redis branded but Valkey-backed in some tiers)

When to use Valkey

• You're on AWS and want the managed option with clean open-source licensing
• You're migrating from Redis and want the smoothest compatibility
• You don't need Redis Stack modules (Valkey doesn't include them)
• Your primary use case is caching, sessions, pub/sub

Migration from Redis to Valkey: Usually zero code changes. Same client libraries work (redis-py, ioredis, Jedis all support Valkey).

Dragonfly

Dragonfly is a ground-up rewrite of Redis designed to be multi-threaded from day one. Written in C++, it uses a share-nothing architecture where each thread owns its own shard of data.

Performance

On a single server with 16+ cores, Dragonfly claims:

• 25x more throughput than Redis on the same hardware
• 10-25x better memory efficiency for large datasets

Benchmarks (2024, single machine, 32 cores):

• Redis: ~1M ops/sec
• Dragonfly: ~8-10M ops/sec

The key insight: Redis is single-threaded for command execution. A 32-core machine mostly idles — you'd need Redis Cluster to use those cores. Dragonfly uses all cores with one process.

Architecture

Redis: Thread 1 handles all commands (other threads for I/O only)

Dragonfly: 
  Thread 1 → Shard 0 (keys A-D)
  Thread 2 → Shard 1 (keys E-H)
  Thread 3 → Shard 2 (keys I-M)
  ...each thread owns its shard, no locking between them

Compatibility

Dragonfly implements the Redis API but not 100%:

• All common commands: ✅
• Lua scripting: ✅ (Dragonfly 1.10+)
• Redis modules (.so files): ❌
• WAIT command: partial
• Some cluster-specific behaviors: differences

When to use Dragonfly

• You need very high throughput on a single node (saves cluster management overhead)
• Memory efficiency matters — Dragonfly stores data significantly more compactly
• You want to replace a small Redis Cluster with one Dragonfly node
• Your use case is primarily caching (not advanced pub/sub or scripting)

Managed option

Dragonfly Cloud — available, reasonably priced.

# Docker run
docker run --network=host --ulimit memlock=-1 \
  docker.dragonflydb.io/dragonflydb/dragonfly \
  --logtostderr --cache_mode

KeyDB

KeyDB was created by Snapchat's infrastructure team, then acquired by Snap, then open-sourced. It takes Redis and makes it multi-threaded by adding a worker thread model while maintaining full Redis compatibility.

What's different from Dragonfly

KeyDB takes the Redis codebase and makes it multi-threaded. Dragonfly is a ground-up rewrite. This means:

• KeyDB has better Redis compatibility (it literally is Redis with threading added)
• Dragonfly has better performance at scale (cleaner architecture)

Key features

FLASH storage: KeyDB can use SSDs as a memory overflow — store cold data on NVMe, hot data in RAM. Effectively infinite cache size for data that doesn't need microsecond access.

Active replication: KeyDB supports active-active replication where multiple nodes accept writes — unlike Redis where replica nodes are read-only.

Redis module compatibility: KeyDB can load Redis .so modules.

Managed option

KeyDB doesn't have a fully managed cloud service. It's primarily self-hosted. This is a consideration for teams that don't want to manage the infrastructure.

When to use KeyDB

• You need Redis module support AND multi-threading
• You want active-active replication without Redis Cluster complexity
• You're using FLASH/NVMe SSDs and want overflow storage

Performance Comparison

For typical cache workloads (GET/SET, strings, short keys):

Numbers are approximations — actual results depend heavily on workload, key sizes, and hardware.

For most applications doing hundreds of thousands of ops/sec or less: the difference doesn't matter. Redis/Valkey is fine.

Which One to Choose

Choose Redis if:

• You need Redis Stack (full-text search, vector search, JSON, time series in one system)
• You're using Redis Cloud managed service
• You rely on specific Redis modules
• Your team knows Redis deeply

Choose Valkey if:

• You're on AWS/GCP and want a managed option with open-source licensing
• You're replacing Redis and want the easiest migration path
• You don't need Redis Stack features

Choose Dragonfly if:

• High throughput on a single node is your bottleneck
• Memory costs are a concern (Dragonfly stores data more efficiently)
• You want to simplify from Redis Cluster to a single powerful node
• You're okay with ~95% Redis compatibility (most common commands work)

Choose KeyDB if:

• You need Redis module compatibility AND multi-threading
• Active-active replication (multi-master) is a requirement
• You want FLASH/NVMe overflow storage

Migration Notes

Redis → Valkey: Usually zero changes needed. Same clients, same commands.

Redis → Dragonfly:

# Dragonfly accepts Redis RESP protocol
# Just change your connection string
# Test with: redis-cli -h dragonfly-host ping
# Run your test suite — most things will just work

Redis → KeyDB:

# KeyDB can load a Redis RDB dump
# keydb-server --loadmodule /path/to/module.so  (Redis modules work)

Related: OpenSearch vs Elasticsearch | AWS CloudWatch Monitoring Guide

Affiliate note: Dragonfly Cloud offers a free tier with 500MB memory — good for testing high-throughput scenarios. AWS ElastiCache now supports Valkey as the open-source default option.