Why it's interesting

Redis's single-threaded design was deliberate — simpler model, lower latency per request, easier to reason about. The cost: scaling past one CPU's worth of throughput requires Redis Cluster, multiple replicas with sharding logic in the client, or hosted Redis Enterprise. Dragonfly does the multi-threading inside the process: each connection is owned by exactly one thread, each key is mapped (by hash) to a thread that owns it, and there's no shared mutable state between threads. The result is linear scaling up to many tens of cores with very low tail latency.

Install

# Linux binary (the simplest path)
curl -fsSL "https://github.com/dragonflydb/dragonfly/releases/latest/download/dragonfly-x86_64.tar.gz" \
    -o /tmp/dragonfly.tgz
tar -xzf /tmp/dragonfly.tgz -C /tmp
sudo mv /tmp/dragonfly-x86_64 /usr/local/bin/dragonfly

# Or container
docker run -d --rm --name dragonfly \
    -p 6379:6379 \
    --ulimit memlock=-1 \
    docker.dragonflydb.io/dragonflydb/dragonfly

Run it:

dragonfly --logtostderr \
    --port=6379 \
    --maxmemory=8gb \
    --proactor_threads=8       # default: as many as CPU cores

From any Redis client — redis-cli, ioredis, lettuce, go-redis, redis-py — just point at the host as if it were Redis:

redis-cli -h dragonfly.example.com PING
# PONG

redis-cli -h dragonfly.example.com SET foo bar
redis-cli -h dragonfly.example.com GET foo

What's compatible, what isn't

The vast majority of Redis commands work as expected:

  • Strings, hashes, lists, sets, sorted sets, streams
  • Pub/Sub (with cluster-aware delivery)
  • Lua scripting (EVAL / EVALSHA)
  • Pipelining and transactions (MULTI/EXEC)
  • Keyspace notifications
  • AOF-like and snapshot-style persistence

What's different or missing:

  • Redis Modules (RediSearch, RedisJSON, RedisTimeSeries) are not loadable — though Dragonfly has its own built-in JSON. commands and search.
  • Redis Cluster protocol is supported in 1.x but not all client libraries handle Dragonfly's cluster topology identically.
  • Some niche commands (e.g. OBJECT FREQ for LFU stats) behave differently due to the threading model.

For 95% of "I use Redis as a cache / queue / session store / pub-sub bus," Dragonfly is a drop-in. Test edge cases against your specific client.

systemd unit

# /etc/systemd/system/dragonfly.service
[Unit]
Description=DragonflyDB
After=network-online.target
Wants=network-online.target

[Service]
User=dragonfly
Group=dragonfly
ExecStart=/usr/local/bin/dragonfly \
    --bind 127.0.0.1 \
    --port 6379 \
    --maxmemory 8gb \
    --dbfilename dump \
    --dir /var/lib/dragonfly \
    --snapshot_cron "0 */6 * * *" \
    --requirepass "${DRAGONFLY_PASSWORD}"
EnvironmentFile=/etc/default/dragonfly
LimitMEMLOCK=infinity
LimitNOFILE=65536
Restart=always

[Install]
WantedBy=multi-user.target

The --snapshot_cron takes a standard cron expression and writes RDB-style snapshots to --dir on that schedule. Combined with AOF-style write logging (--journal=true), point-in-time recovery works the same way it does in Redis.

Persistence model

Dragonfly's persistence story differs subtly from Redis:

  • Snapshots — periodic full dumps to dump.dfs, similar to Redis RDB. Compressed by default. The on-disk format is Dragonfly-specific but the data is restoreable.
  • Journal (AOF-like) — append-only log of every write since the last snapshot.
  • Snapshots are non-blocking — the snapshot thread fork-clones in-memory state with copy-on-write and writes to disk while serving requests. Redis does this too, but Dragonfly's per-shard model keeps tail latency lower during snapshots.

Replication

Like Redis: a primary + N replicas. On each replica:

dragonfly --replicaof primary.lab:6379 ...

The replica connects, slurps a snapshot, then tails the primary's journal. Failover is manual (point clients at the new primary; future Sentinel-equivalent is on the roadmap but not yet shipped).

Memory footprint

Dragonfly's per-key overhead is materially lower than Redis's (different data-structure implementations: B+tree-based sorted sets and string-interning for small strings). For a workload of millions of small keys, expect 25–40% lower RAM usage at the same payload — one of the under-advertised wins.

When to stick with Redis

  • If you rely on Redis Modules (RediSearch, RedisJSON, RedisGraph, RedisTimeSeries, RedisAI).
  • If your client library has buggy Dragonfly support at scale — verify with a real load test before swapping production.
  • If the workload is sub-million-ops, single-node, and Redis's 100 MB binary already does it — the switch isn't worth the risk for "we're not yet bottlenecked."
  • For Redis OSS support, the licensing change (RSAL/SSPL) since 2024 also pushed projects to alternatives like Valkey or KeyDB — Dragonfly is one option in that landscape; pick the trade-off that matches your needs.

Monitoring

Dragonfly exposes Prometheus metrics at /metrics (default port 6379 on path /metrics) and a JSON status page at /. Scrape with Prometheus (see that tutorial) and use one of the community-maintained Grafana dashboards.