About 185 Redis commands do not mean identical Redis behavior
Dragonfly's README says it implements about 185 Redis commands and 13 Memcached commands. Existing clients can connect through the familiar protocols, while the server partitions its keyspace across threads to use more of one machine. That makes Dragonfly interesting when a Redis workload is limited by one process and adding another node creates unwanted operational work. The repository also includes cache mode, snapshotting, replication, metrics, and an HTTP console, so this is a database service rather than a small caching library.
Compatibility has specific edges. Strings stop at 256 MB, expiration ranges stop at 8 years, and millisecond deadlines beyond 2^28 ms are rounded to the nearest second. Dragonfly uses Lua 5.4.4, which differs from Redis scripting behavior in some cases. The README calls cluster mode emulated, and the differences file documents semantic gaps that a client library will not hide. Run the commands your application actually uses, including scripts, ACL rules, expiry, transactions, and recovery paths.
What happened when we ran it
Our sandbox installed 36 Python packages in 27 seconds, consuming 37 MB on disk. The build succeeded in 11 seconds. The test command then exited 1 after 10 seconds: pytest reported 0 passed, 0 failed, 24 skipped, and 3 collection or setup errors. Two errors were ModuleNotFoundError for pymemcache and pytest_asyncio. The supplied log tail also listed tools/defrag_mem_test.py as an error without showing its exception, so we cannot assign that third error a cause.
The checkout at commit 00693a0 contained 1,514 files, about 365,085 lines of source, and used 18.2 MB before installation. We found 20 CI workflow files and a tests directory, but no Dockerfile. Pip-audit reported 0 known vulnerabilities among the installed Python packages. These results cover repository setup in an unprivileged 3-CPU, 8 GB Debian container; they do not measure Dragonfly request throughput, latency, memory efficiency, Redis command coverage, or failover behavior.
Linux 5.11 is recommended, while the container needs memlock access
The native build guide says Dragonfly runs on Linux and recommends kernel 5.11 or later. Building from source requires Ninja, CMake, a C++ compiler, Boost context, OpenSSL, libunwind, and other listed system packages. The documented configure command uses the Helio build script, followed by Ninja. Despite the absence of a Dockerfile in our measured checkout, the quick start pulls a published Dragonfly image, which is the shorter evaluation path for someone who only wants to exercise the server.
The Linux container command uses host networking and requests memlock=-1; macOS and Windows use an explicit port mapping because host networking differs there. A note says privileged mode can resolve some initialization errors, which is a broad permission increase and deserves investigation before use in production. Source builders can toggle AWS, GCP, search, tiered storage, and extension support. Those options make reproducible build flags and an owned artifact more important than copying one generic command.
Port 6379 serves RESP and HTTP unless you turn HTTP off
Dragonfly listens for Redis traffic on port 6379 by default and can recognize HTTP on that same port. Its README says the HTTP console belongs on a safe network and tells operators to disable it when the TCP port is exposed. The default requirepass value is empty. A production configuration therefore needs an intentional bind address, authentication, a memory ceiling, snapshot storage, and a decision about whether the main port should answer HTTP at all.
BSL 1.1 restricts competing hosted use until the change date
The checked-in license is Business Source License 1.1, with a stated change date of November 1, 2030 and Apache 2.0 as the later license. Its additional-use grant permits Dragonfly inside products outside the in-memory data-store category. It restricts making the software available as a competing hosted or managed service. This is source-available software with production-use conditions, so a cloud cache vendor has a different adoption decision from a retailer running an internal session store.
Emulated cluster mode leaves failure domains to outside software
Open issue 8231 says WAIT 1 can be satisfied by a replica in the same rack because Dragonfly does not store availability-zone identity. The report says health checks, promotion, and fencing are delegated to an external cluster manager; during a partition, missing fencing can permit split brain or acknowledged-write loss. That is a direct warning for multi-datacenter designs. A successful Redis client connection says nothing about whether the surrounding operator provides the recovery guarantees the application expects.
Recent reports also show where compatibility testing bites. Issue 8247 says source keys in read-one-write-one commands can be denied unless the user has write permission, contrary to the expected Redis 7 ACL split. Issue 8217 describes about 40 GiB charged to a cgroup but not mapped into the Dragonfly process on a particular v1.39.0 workload. The reporter did not identify a cause, so it is evidence to monitor cgroup memory separately from process RSS, not a general memory benchmark.
v1.40.2 shipped with an upgrade advisory for journal correctness
Release v1.40.2 arrived on September 3, 2026. Its notes advise upgrading because of a journal correctness bug and list fixes across tiered storage, replication, protocol handling, and memory accounting. GitHub recorded the last push on September 6, three days after the release. That short release-to-push gap, together with issue updates on September 6, shows active maintenance rather than a repository coasting on an older tag.
GitHub listed 31,439 stars and 299 combined open issues and pull requests when fetched. Separate searches counted 251 open issues and 48 open pull requests. The queue includes fresh ACL, cluster, and memory reports, while recent closed work includes protocol and remote-allocation fixes. Dragonfly is mature enough to merit a workload trial, but replacing a stateful service should finish with command-level regression tests, restore drills, and a partition test under the operator that will own promotion and fencing.