What is Dragonfly?What is Dragonfly?
Modern in-memory data store fully compatible with Redis and Memcached, delivering 25x more throughput
Dragonfly in 60 seconds
A multi-threaded in-memory data store that speaks the Redis and Memcached protocols and runs on a single node.
Teams pick it to replace a sharded Redis cluster with one machine that uses every CPU core.
- +Multi-threaded design uses every CPU core, not a single thread
- +Drop-in Redis and Memcached protocol support, no client changes
- +Forkless snapshots avoid the memory spikes Redis hits on BGSAVE
- −Source-available under BSL 1.1, not a fully open-source license
- −In-memory store, so the working set has to fit in the node's RAM
- −Younger project with a smaller ecosystem than Redis around it
At a glance
| Category | Key-value |
| First released | 2022 |
| Latest release | 1.40.1 (Aug 2026) |
| License | BSL-1.1 |
| Written in | C++ |
| Runs on | Linux |
| Deployment | Self-hosted, Managed |
| Wire protocol | redis, memcached |
| Query dialect | redis-commands |
| Consistency | strong |
| ACID support | no |
| JSON support | native |
| Full-text search | compatible |
| Vector support | native |
| HA model | primary-standby |
| Managed by | dragonfly-cloud, aiven |
What is Dragonfly?
Dragonfly is an in-memory data store that works as a drop-in replacement for Redis and Memcached. It speaks both wire protocols, so existing clients and libraries connect without changes, but the engine underneath is a rewrite. The goal is to serve the same commands from a single machine that uses all of its CPU cores, where Redis leans on one core per process and scales out by running many of them.
The project comes from DragonflyDB Ltd., founded in 2022 by Roman Gershman and Oded Poncz, former Google engineers who had spent years fighting the cost and operational drag of scaling Redis. They launched the source in May 2022, hit general availability in March 2023 alongside a $21M raise, and the code sits under the Business Source License 1.1. That license lets you read and self-host it but reserves the right to sell it as a managed service, and it converts to Apache 2.0 after four years.
Adoption skews toward teams already running Redis at scale who want fewer, bigger nodes. Instacart, ShareChat, Meesho, redBus, Akuity, and Abusix have all written up moves to Dragonfly, usually swapping a large sharded cluster for a couple of instances and reporting lower cost and less operational work. The headline claim is 25x the throughput of Redis on a single node, which is where most of the interest starts.
How Dragonfly works
Dragonfly runs a multi-threaded, shared-nothing engine. Each thread owns a slice of the keyspace and handles the commands for its own keys, so there are no global locks and no single-threaded bottleneck. A command that touches keys in one slice runs entirely on that thread, while a transaction spanning several slices coordinates across the threads that own them. On Linux, all I/O goes through io_uring to keep syscall overhead low.
Memory is where much of the design pays off. Instead of the Redis dictionary, Dragonfly stores keys in a Dashtable, a hash table based on the academic Dash design that keeps overhead low and cache locality high. Snapshots are forkless: Redis forks a child process for BGSAVE, which can double memory use under write load, while Dragonfly has each shard thread serialize its own data in place, so a point-in-time snapshot does not spike memory.
From the outside it looks like Redis. Clients connect over the RESP protocol on port 6379, or the Memcached text protocol, and run the usual commands against strings, hashes, lists, sets, sorted sets, and streams. It persists to disk with snapshots, supports primary-replica replication for high availability, and offers a cluster mode for when one node is not enough. Most Redis tooling, from redis-cli to BullMQ and Sidekiq, works against it unchanged.
Key concepts
Redis and Memcached compatibility
Dragonfly implements the Redis RESP protocol and the Memcached protocol, so existing clients, drivers, and tools connect without code changes. It covers the common data types and commands most apps use, which is what makes it a drop-in swap. A few less-common Redis commands and modules are still being filled in over time.
Multi-threaded shared-nothing engine
Instead of one thread per process, Dragonfly runs many threads on one node, and each owns a slice of the keyspace. Commands for a given key always run on the thread that owns it, so there are no global locks. That lets a single instance saturate every core of a large machine rather than scaling out to many single-threaded processes.
Dashtable memory layout
Keys live in a Dashtable, a hash table based on the academic Dash design rather than the Redis dictionary. It keeps per-key overhead low and cache locality high, so the same dataset fits in less RAM. Lower memory per key is a big part of how Dragonfly replaces several Redis nodes with one and cuts the cost of a cache tier.
Forkless snapshots
Redis forks a child process to write an RDB snapshot, which can nearly double memory under heavy writes. Dragonfly instead has each shard thread serialize its own slice in place, so a point-in-time snapshot never forks and never spikes memory. It makes persistence safer on nodes already near their memory ceiling.
Replication and high availability
Dragonfly supports primary-replica replication, where replicas stay current and can take over if the primary fails. It speaks the Redis replication commands, so it can even replicate from a Redis primary during a migration. For capacity beyond one big node, a cluster mode spreads the keyspace across instances.
Persistence and cache modes
By default Dragonfly keeps data in memory and can snapshot to disk for durability, so a restart reloads the last saved state. It can also run as a pure cache with an eviction policy that drops the least useful keys when memory fills. Picking a durable store or a throwaway cache is a config choice, not a separate product.
Dragonfly by the numbers
Live GitHub adoption, updated daily
Who uses Dragonfly
A handful of the companies running it in production
When to use Dragonfly
Best for
The core case: collapsing many single-threaded Redis nodes into one or two Dragonfly instances. Wire compatibility keeps clients working, and the multi-threaded engine absorbs the load on fewer machines.
When a cache tier needs millions of operations per second, one Dragonfly node using every core often beats a fleet of Redis processes. It scales up on modern hardware before you reach for sharding.
Sessions, leaderboards, rate limiters, queues, and pub/sub all map to Redis commands Dragonfly already speaks. It fits the real-time workloads Redis handles, with more headroom per node and simpler ops.
Lower memory per key and higher throughput per node tend to shrink the bill. Teams report swapping large clusters for a couple of instances, cutting both the machine count and the operational work.
Not ideal for
Dragonfly is an in-memory store with snapshotting, not a primary database. For data that must survive on disk with full durability guarantees, keep the source of truth in Postgres, MySQL, or similar.
There are no joins, no SQL, and no multi-table ACID transactions. Workloads built around relational modeling or complex multi-key correctness belong in a relational database, not a key-value store.
The working set has to fit in the node's RAM, plus room for snapshots and overhead. Corpora far larger than memory get costly fast, and a disk-based store or a real database will fit the job better.
Dragonfly ships under BSL 1.1, which restricts offering it as a managed service. Teams that require an OSI-approved license or a large, mature ecosystem may prefer Valkey or Redis for those guarantees.
Dragonfly vs alternatives
Head-to-head specs against the top 5 alternatives
| Spec | ||||||
|---|---|---|---|---|---|---|
| Identity | ||||||
| License | BSL-1.1 | RSALv2 / SSPLv1 / AGPLv3 (triple-licensed) | BSD-3-Clause | BSD-3-Clause | BSD-3-Clause | Apache-2.0 |
| First released | 2022 | 2009 | 2024 | 2019 | 2003 | 2019 |
| Capabilities | ||||||
| Consistency | Strong | Strong | Eventual | Eventual | Eventual | Eventual |
| HA model | Primary-standby | Primary-standby | Primary-standby | Multi-master | None | Primary-standby |
| Ecosystem | ||||||
| Managed providers | 2 | 6 | 3 | — | 3 | — |
| Integrations | 2 | 8 | 3 | 2 | 4 | 2 |
| Use cases | ||||||
| Best for | High-throughput caching, Redis/Memcached replacement with better memory efficiency and multi-threaded performance | High-performance caching, session management, real-time leaderboards, rate limiting, pub/sub messaging, and AI vector search | High-performance caching, session storage, real-time data, and as a Redis drop-in replacement with open-source license | High-throughput caching with multithreaded performance, active-active replication, and Redis-compatible drop-in replacement | Application-level caching, session storage, and reducing database read load in high-traffic web applications | Drop-in Redis replacement for large datasets that exceed available RAM, reducing memory costs with disk-backed storage |
| Not ideal for | Disk-based persistent storage, relational queries, complex transactions | Complex relational queries, large datasets exceeding available memory, or workloads requiring strong multi-key ACID transactions | Complex queries, relational data, large datasets exceeding RAM, or durable primary storage | Complex queries, relational data, or workloads requiring managed cloud service | Persistent data storage, complex data structures, or use cases requiring data durability and replication | Sub-millisecond latency requirements matching pure in-memory Redis, or workloads needing full Redis module ecosystem |
Quick start
Run Dragonfly with Docker, connect with the standard redis-cli, and run your first commands. Under a minute if you have Docker.
docker run --name dragonfly -p 6379:6379 \
--ulimit memlock=-1 \
docker.dragonflydb.io/dragonflydb/dragonflyredis-cli -h localhost -p 6379
# any Redis client works too, pointed at localhost:6379SET greeting "hello from dragonfly"
GET greeting
INCR page:views
INCR page:views
LPUSH queue job1 job2
LRANGE queue 0 -1Those are ordinary Redis commands, served by Dragonfly. Point any existing Redis client or GUI at the same port and it just works.
Resources
Official
Related database guides
PostgreSQL
The world's most advanced open-source relational database
MongoDB
The most popular document database for modern applications
Qdrant
High-performance open-source vector database for next-generation AI applications
DuckDB
Fast in-process analytical database with rich SQL support and zero dependencies
Turso
In-process SQL database compatible with SQLite, written in Rust with vector search and CDC support
Typesense
Fast, typo-tolerant open-source search engine with built-in vector and semantic search
Frequently asked questions
What is Dragonfly used for?
Is Dragonfly a drop-in replacement for Redis?
Is Dragonfly open source?
Who makes Dragonfly?
Is Dragonfly the same as Redis?
Skip the config files
Connect to Dragonfly in 30 seconds. Browse tables, run queries, and edit rows visually, on localhost, self-hosted, or cloud.
Open Dragonfly in 1bench