Dragonfly 2.0 is out, with the major version bump explicitly meant to signal “maturity, performance, and production readiness.”

It is a drop-in replacement for Redis and Memcached, speaking their APIs, and it is genuinely fast. It is also not open source, which is the part that matters most if you are choosing infrastructure to build on.

What is new

Compatibility:

• Valkey 9 RDB loading support, plus broader Redis and Valkey compatibility

Performance:

• Reduced connection processing overhead
• Reduced memory accounting overhead
• Lower buffering and RDB serialization costs
• Configurable burst and cool-down limits for background defragmentation

The defragmentation controls are the most operationally useful item. Background defrag reclaims memory fragmented by long-running workloads, and it competes with the requests you actually care about. Being able to bound how hard it runs, and how long it rests, is the difference between a tunable and a surprise latency spike.

Valkey 9 RDB loading matters because it means you can take a snapshot from a Valkey deployment and load it into Dragonfly, which is what makes migration realistic rather than theoretical.

The licence

Dragonfly is distributed under the Business Source License 1.1.

BSL is a source-available licence, not an open-source one. You can read the code and generally use it, but there are restrictions on offering it as a competing service, and each release converts to a genuinely open licence only after a set period.

That matters here more than it usually would, because of how this whole corner of the ecosystem got where it is. Redis changed its licence away from BSD, the community response was Valkey, a fork under the Linux Foundation, and a large part of the industry moved there specifically to avoid depending on a licence a vendor can change.

Dragonfly offers Redis compatibility and better performance, under a licence with the same class of concern that started the argument. That is not a reason to avoid it. It is a reason to know what you are adopting.

For self-hosting in particular, which our self-hosting introduction treats as being about control rather than cost, the licence is part of the control question. If the terms change in a direction you dislike, your options are the version you already have and a migration.

Where it fits

Dragonfly’s pitch is vertical scaling. Redis is famously single-threaded for command execution, so the traditional answer to more load is more instances and a cluster to coordinate them. Dragonfly uses a multi-threaded, shared-nothing design to use a whole machine, so one large instance replaces a cluster of small ones.

That is a real operational simplification for anyone running a cache big enough to have outgrown one Redis process but not big enough to want to run a cluster.

# it speaks the redis protocol, so existing tools work
redis-cli -p 6379 info server
redis-cli -p 6379 --latency

# docker is the usual deployment
docker run -p 6379:6379 --ulimit memlock=-1 \
  docker.dragonflydb.io/dragonflydb/dragonfly

If you deploy it, apply the same discipline as any other data service: bound its memory with cgroup limits so a runaway cache cannot take the host down, and do not publish the port. Our container hardening guide covers why -p 6379:6379 is more exposed than people expect, and an unauthenticated Redis-protocol service reachable from the internet is one of the most reliably exploited misconfigurations there is.

Valkey remains the choice if licence terms are a hard requirement, and it is the one most distributions now package by default.