[opensourcedex]

Dragonfly is a free, open source databases project written in C++ and released under a custom open-source licence. It has 31,573 GitHub stars, 1,263 forks and 308 open issues, and was last pushed 8 hours ago. On this registry it ranks #15 of 81 tracked projects in Databases, with 5 head-to-head comparisons available. It gained 80 stars over the last 6 tracked days.

Dragonfly — Blazing-fast in-memory data store for modern applications

What is Dragonfly?

Dragonfly is a C++ in-memory data store that speaks the Redis and Memcached APIs, built for teams that want more throughput and lower resource use from an existing cache or key-value workload without changing application code.

What it is

Dragonfly is an open-source, in-memory data store positioned by its maintainers as a modern replacement for Redis and Memcached. It is written in C++ and listed in this registry under Infrastructure & Operations / Databases. The project's topic list classifies it as an in-memory database, a key-value store, a cache, a message broker, and a NoSQL database, and the presence of the fibers and multi-threading topics reflects its design as a multi-threaded server rather than a single-threaded one. Its stated goal is full compatibility with the Redis and Memcached APIs so that adoption requires no code changes on the client side.

The concrete problem it addresses is the ceiling that a single-threaded in-memory store hits as instance size grows. The README argues that Redis is bottlenecked on CPU and reaches local maxima in performance, which means operators respond by adding instances and shards rather than by scaling up one. Dragonfly's benchmarks are presented to show throughput capacity continuing to grow with instance size: on m5.xlarge, running memtier_benchmark -c 20 --test-time 100 -t 6 -d 256 --distinct-client-seed, Dragonfly reports 279K QPS for SETs against Redis at 190K, and 305K QPS for GETs against Redis at 220K. On c6gn.16xlarge, the README claims a 25X throughput increase over a single Redis process. The project also claims up to 80% less resource consumption for the same sized workload, together with higher cache hit rates and lower tail latency.

Key capabilities

  • Full compatibility with the Redis and Memcached APIs, which the README states requires no code changes to adopt.
  • Vertical scaling: throughput capacity grows with instance size, benchmarked across m5.large, m5.xlarge, and c6gn.16xlarge with memtier_benchmark.
  • Reported 25X throughput increase over a single Redis process on c6gn.16xlarge.
  • Claimed resource savings of up to 80% for the same sized workload, with higher cache hit rates and lower tail latency.
  • Multi-threaded, fiber-based C++ architecture, as indicated by the fibers, multi-threading, and cpp topics.
  • Coverage of several data workloads named in the topic list: key-value store, cache, NoSQL database, and message broker.
  • Documentation set that includes a quick-start guide, a Configuration section, a Design decisions section, docs/build-from-source.md, an AGENTS.md guide for AI agents, and README translations into Simplified Chinese, Japanese, Korean, Portuguese (Brazil), and Thai.

Who uses it and how

  • Teams running Redis at CPU saturation on a single-threaded instance, who can substitute Dragonfly to raise queries per second without adding shards, based on the benchmark comparison in the README.
  • Applications that already use Redis or Memcached client libraries, where API compatibility means the backend can be swapped without touching application code.
  • Operators who prefer a self-hosted container deployment, using the ghcr.io/dragonflydb/dragonfly image whose total and monthly pulls the README tracks through badges.
  • Teams that do not want to operate the datastore themselves, addressed by the hosted Dragonfly Cloud option linked from the homepage and README.
  • Contributors and users who need community support channels, which include a Community Discord, GitHub Discussions, GitHub Issues, and the Dragonfly Ascent user conference.

Getting started

The README points to the Quick Start guide in the documentation for installation and first run, and the project ships as a container image at ghcr.io/dragonflydb/dragonfly. Building from source is documented in docs/build-from-source.md, and Dragonfly Cloud is offered as a hosted alternative.

How it compares

The facts name Redis and Memcached as the tools Dragonfly replaces, and KeyDB appears in the topic list as a related in-memory store. Against Redis, the project's own benchmarks contrast a single-threaded store that plateaus on CPU with a multi-threaded one whose throughput keeps rising with instance size, while Dragonfly keeps Redis API compatibility so that comparison does not force a rewrite. The registry records its licence as NOASSERTION, which means anyone evaluating it against Redis or Memcached on licence grounds must confirm terms directly rather than rely on this page.

When to use it — and when not to

A self-hoster must run the container or build the C++ source and manage the Configuration options themselves, and the quick-start material lives in external documentation rather than in the README, so the repository alone is not a complete operations guide. The recorded licence value of NOASSERTION is a real gap: teams with strict licence review should verify terms before committing. It is also not the obvious choice when an existing Redis or Memcached instance still has comfortable CPU headroom, since the main argument for switching is throughput and resource efficiency at scale.

project readme (upstream, from github) — read inline

ci-tests Total pulls Monthly pulls Twitter URL

Before moving on, please consider giving us a GitHub star ⭐️. Thank you!

Other languages: 简体中文 日本語 한국어 Português ภาษาไทย

Website • Docs • Quick Start • Community Discord • Dragonfly User Conference • Join the Dragonfly Community

GitHub Discussions • GitHub Issues • Contributing • AI Agents Guide • Dragonfly Cloud

The world's most efficient in-memory data store

Dragonfly is an in-memory data store built for modern application workloads.

Fully compatible with Redis and Memcached APIs, Dragonfly requires no code changes to adopt. Compared to legacy in-memory datastores, Dragonfly delivers 25X more throughput, higher cache hit rates with lower tail latency, and can run on up to 80% less resources for the same sized workload.

Contents

Benchmarks

We first compare Dragonfly with Redis on m5.large instance which is commonly used to run Redis due to its single-threaded architecture. The benchmark program runs from another load-test instance (c5n) in the same AZ using memtier_benchmark -c 20 --test-time 100 -t 4 -d 256 --distinct-client-seed

Dragonfly shows a comparable performance:

  1. SETs (--ratio 1:0):
Redis DF
QPS: 159K, P99.9: 1.16ms, P99: 0.82ms QPS:173K, P99.9: 1.26ms, P99: 0.9ms
  1. GETs (--ratio 0:1):
Redis DF
QPS: 194K, P99.9: 0.8ms, P99: 0.65ms QPS: 191K, P99.9: 0.95ms, P99: 0.8ms

The benchmark above shows that the algorithmic layer inside DF that allows it to scale vertically does not take a large toll when running single-threaded.

However, if we take a bit stronger instance (m5.xlarge), the gap between DF and Redis starts growing. (memtier_benchmark -c 20 --test-time 100 -t 6 -d 256 --distinct-client-seed):

  1. SETs (--ratio 1:0):
Redis DF
QPS: 190K, P99.9: 2.45ms, P99: 0.97ms QPS: 279K , P99.9: 1.95ms, P99: 1.48ms
  1. GETs (--ratio 0:1):
Redis DF
QPS: 220K, P99.9: 0.98ms , P99: 0.8ms QPS: 305K, P99.9: 1.03ms, P99: 0.87ms

Dragonfly throughput capacity continues to grow with instance size, while single-threaded Redis is bottlenecked on CPU and reaches local maxima in terms of performance.

If we compare Dragonfly and Redis on the most network-capable instance c6gn.16xlarge, Dragonfly showed a 25X increase in throughput compared to Redis single process, crossing 3.8M QPS.

Dragonfly's 99th percentile latency metrics at its peak throughput:

op r6g c6gn c7g
set 0.8ms 1ms 1ms
get 0.9ms 0.9ms 0.8ms
setex 0.9ms 1.1ms 1.3ms

All benchmarks were performed using memtier_benchmark (see below) with number of threads tuned per server and instance type. memtier was run on a separate c6gn.16xlarge machine. We set the expiry time to 500 for the SETEX benchmark to ensure it would survive the end of the test.

  memtier_benchmark --ratio ... -t <threads> -c 30 -n 200000 --distinct-client-seed -d 256 \
     --expiry-range=...

In pipeline mode --pipeline=30, Dragonfly reaches 10M QPS for SET and 15M QPS for GET operations.

Dragonfly vs. Memcached

We compared Dragonfly with Memcached on a c6gn.16xlarge instance on AWS.

With a comparable latency, Dragonfly throughput outperformed Memcached throughput in both write and read workloads. Dragonfly demonstrated better latency in write workloads due to contention on the write path in Memcached.

SET benchmark
Server QPS(thousands qps) latency 99% 99.9%
Dragonfly 🟩 3844 🟩 0.9ms 🟩 2.4ms
Memcached 806 1.6ms 3.2ms
GET benchmark
Server QPS(thousands qps) latency 99% 99.9%
Dragonfly 🟩 3717 1ms 2.4ms
Memcached 2100 🟩 0.34ms 🟩 0.6ms

Memcached exhibited lower latency for the read benchmark, but also lower throughput.

Memory efficiency

To test memory efficiency, we filled Dragonfly and Redis with ~5GB of data using the debug populate 5000000 key 1024 command, sent update traffic with memtier, and kicked off the snapshotting with the bgsave command.

This figure demonstrates how each server behaved in terms of memory efficiency.

Dragonfly was 30% more memory efficient than Redis in the idle state and did not show any visible increase in memory use during the snapshot phase. At peak, Redis memory use increased to almost 3X that of Dragonfly.

Dragonfly finished the snapshot faster, within a few seconds.

For more info about memory efficiency in Dragonfly, see our Dashtable doc.

Configuration

Dragonfly supports common Redis arguments where applicable. For example, you can run: dragonfly --requirepass=foo --bind localhost.

Dragonfly currently supports the following Redis-specific arguments:

  • port: Redis connection port (default: 6379).
  • bind: Use localhost to only allow localhost connections or a public IP address to allow connections to that IP address (i.e. from outside too). Use 0.0.0.0 to allow all IPv4.
  • requirepass: The password for AUTH authentication (default: "").
  • maxmemory: Limit on maximum memory (in human-readable bytes) used by the database (default: 0). A maxmemory value of 0 means the program will automatically determine its maximum memory usage.
  • dir: Dragonfly Docker uses the /data folder for snapshotting by default, the CLI uses "". You can use the -v Docker option to map it to your host folder.
  • dbfilename: The filename to save and load the database (default: dump).

There are also some Dragonfly-specific arguments:

readme truncated — read the full docs on github

Frequently asked questions

Is Dragonfly free to use?

Dragonfly is open source. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does Dragonfly do?

Blazing-fast in-memory data store for modern applications

What is Dragonfly written in?

Dragonfly is primarily written in C++. Its source is publicly available at https://github.com/dragonflydb/dragonfly, and it has 31,573 GitHub stars.