Dragonfly vs Valkey vs Redis: 2026 In-Memory Cache Performance Benchmark & Systems Guide

# Dragonfly vs Valkey vs Redis: 2026 In-Memory Cache Performance Benchmark & Systems Guide

Summary: In this dragonfly vs valkey and Redis performance benchmark, Dragonfly achieves up to 3.8M QPS via shared-nothing thread-per-core fibers without cluster sharding, while Valkey 8.0 achieves over 1.2M QPS on a single node through asynchronous multi-threaded I/O while preserving open-source Redis compatibility. This guide compares throughput, p99 tail latency, Dash-Table memory density, forkless snapshotting, and production migration patterns across 64-core cloud instances.

Architectural Evolution: Single-Thread Event Loops to Shared-Nothing Fibers

The in-memory data store landscape underwent a structural transformation following Redis Ltd's March 2024 licensing change, which shifted Redis from the three-clause BSD license to dual proprietary source-available licenses (RSALv2 and SSPLv1). This license modification prompted widespread industry realignment and the establishment of Valkey under the Linux Foundation as an open-source, BSD-3-Clause licensed fork of Redis 7.2.4. Simultaneously, Dragonfly established itself as a ground-up redesign of in-memory caching principles, questioning whether the single-threaded event loop model pioneered in 2009 remains optimal for modern cloud hardware equipped with 64, 128, or 256 execution threads and multi-channel DDR5 memory.

Modern engineering teams evaluating the dragonfly vs valkey architectural divide must distinguish between conservative protocol-preserving evolution and clean-slate concurrency redesign. Where Valkey focuses on drop-in compatibility and incremental multi-threading, Dragonfly eliminates the architectural assumptions of legacy Redis, introducing fiber-based thread-per-core execution and custom hash table layouts.

Redis Architecture: The Single-Threaded Core and I/O Thread Limits

Redis built its reputation on single-threaded simplicity. At its foundation lies an event loop implemented in ae.c that multiplexes network socket events using system-specific primitives: epoll on Linux, kqueue on BSD/macOS, and select as a portable fallback. Because a single thread handles command parsing, dictionary lookups, and memory writes, Redis completely avoids mutex contention, race conditions, and lock overhead within its data structures.

However, modern cloud nodes regularly provide 32 to 64 physical cores on a single socket. A single-threaded process utilizes only 1.5% to 3.1% of such a host's compute capacity. To alleviate network bottlenecks, Redis 6.0 introduced threaded I/O (io-threads). Under this configuration, background worker threads offload socket read/write operations and protocol framing (readQueryFromClient and writeToClient).

Despite this optimization, the execution of commands remains strictly pinned to thread 0. The main thread processes commands sequentially against the central dict hash table. Once payload sizes shrink to typical cache dimensions (32 to 256 bytes), network framing ceases to be the bottleneck. For unpipelined workloads (pipeline depth of 1) executing standard single-key commands (GET/SET), the single execution thread in Redis 7.2 typically saturates at approximately 180,000 to 230,000 operations per second on modern 3 GHz+ x86 or ARM64 cores, even with threaded I/O enabled. While client-side pipelining can increase batched throughput to over 400,000 ops/sec by amortizing network syscalls, strict request-response workflows remain bounded by execution core serialization.

Scaling Redis beyond this limit requires Redis Cluster. Redis Cluster partitions the keyspace into 16,384 logical hash slots, distributing slots across independent Redis instances. While functional, clustering introduces operational complexity:

1. Network Indirection: Clients must maintain cluster slot maps, handle MOVED and ASK redirects, and execute pipelining per node.

2. Multi-Key Constraints: Multi-key operations (such as MGET, transactions, and Lua scripts) fail with CROSSSLOT errors unless all targeted keys contain identical hash tags (e.g., {user:1001}.profile and {user:1001}.settings).

3. Cluster Bus Noise: Nodes continuously exchange heartbeat packets over a dedicated cluster bus port (port + 10,000), increasing CPU overhead and network noise as node counts expand.

Valkey 8.0: Open-Source Stewardship and Asynchronous Engine Modernization

Announced under the Linux Foundation with broad industry backing from AWS, Google Cloud, Oracle, Ericsson, and Snap, Valkey maintains protocol, RDB file format, and client SDK compatibility with the Redis 7.2 open-source ecosystem. For infrastructure teams prioritizing permissive, OSI-approved open-source governance, Valkey serves as a direct BSD-3-Clause drop-in replacement.

In standardized valkey vs redis benchmark evaluations, Valkey 8.0 demonstrates substantial throughput improvements by overhauling the threaded I/O engine into an asynchronous multi-threading architecture. Key modernizations in Valkey 8.0 include:

• Concurrent Command Parsing: Background I/O threads parse incoming RESP protocol buffers into command objects concurrently, removing byte-parsing overhead from the primary execution thread.
• Asynchronous Pipelined Execution: Batch queries queued in client buffers are dispatched concurrently across I/O threads, grouping network writes via writev to significantly reduce Linux kernel syscall frequency.
• Enhanced Cluster Migration: Slot migration and shard rebalancing protocols utilize non-blocking socket conduits, minimizing p99 tail-latency degradation during live node re-allocations.

Through these asynchronous multi-threading enhancements, standalone Valkey 8.0 exceeds 1.2 million operations per second on high-core AWS Graviton3/Graviton4 instances under pipelined workloads—more than double the throughput of Redis 7.2 under identical conditions. However, Valkey 8.0 preserves the classic single-dictionary memory model: core command mutations and transactional blocks execute sequentially against a unified keyspace. While read-heavy and pipelined workloads scale across I/O threads, highly concurrent write mutations and multi-key transactions still encounter core execution serialization on a single node, necessitating horizontal clustering (Valkey Cluster) when scaling write throughput across distributed shards.

Dragonfly: Thread-Per-Core Concurrency and User-Space Fibers

Dragonfly approaches in-memory caching from a greenfield systems perspective, authored in C++20. Instead of multiplexing multiple threads against a single data dictionary or relying on OS-level mutexes, Dragonfly deploys a shared-nothing, thread-per-core architecture inspired by frameworks like Seastar.

When Dragonfly boots, it creates a dedicated proactor thread pinned to each CPU core via hardware affinity masks (pthread_setaffinity_np). Each proactor thread manages:

1. An independent event loop communicating directly with kernel rings via io_uring or epoll.

2. An isolated slice (shard) of the total keyspace, complete with its own hash tables and expiration wheels.

3. A user-space cooperative fiber scheduler implemented via Dragonfly's Helio concurrency library. Fibers function as ultra-lightweight execution contexts (allocating approximately 8 KB to 32 KB of stack space compared to the 2 MB to 8 MB default stack allocation for standard OS POSIX threads). When a fiber awaits network I/O or a multi-shard memory access, it yields cooperatively without triggering a kernel context switch.

To handle operations spanning multiple keys mapped to different core shards, Dragonfly employs Very Light Locking (VLL). Rather than locking an entire hash table or relying on distributed consensus, Dragonfly schedules micro-transactions across the relevant thread shards using lock-free message queues. This architectural foundation enables Dragonfly to scale linearly across 64 or 128 hardware threads on a single symmetric multiprocessing (SMP) server, processing millions of operations per second within a single process.

64-Core Cloud Benchmark: Throughput, Scalability, and Latency Profiles

Benchmark Infrastructure and Testing Methodology

To evaluate objective in-memory cache performance across Redis, Valkey, and Dragonfly, this systems analysis synthesizes reproducible benchmarking methodologies using standard enterprise cloud hardware profiles. The comparative matrix reflects standardized test executions using the open-source memtier_benchmark harness, cross-referenced with published architectural benchmarks from the Linux Foundation Valkey Project and DragonflyDB.

Server Hardware Profile:

• Compute Instance: AWS EC2 c7g.16xlarge (64 physical vCPUs, AWS Graviton3 ARM64 architecture, 128 GiB DDR5 memory, 25 Gbps dedicated Elastic Network Adapter bandwidth).
• Secondary Reference Architecture: AWS EC2 c6i.16xlarge (64 vCPUs, Intel Xeon Ice Lake 8375C, 128 GiB DDR4 memory) to verify cross-architecture behavioral consistency.
• Linux Kernel Sysctl Tuning (`/etc/sysctl.conf`):

  sysctl -w net.core.somaxconn=65535
  sysctl -w net.ipv4.tcp_max_syn_backlog=65535
  sysctl -w vm.overcommit_memory=1
  sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
  sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
  echo never > /sys/kernel/mm/transparent_hugepage/enabled

Load Generation Harness & Client Profile:

• Client Instances: Two dedicated AWS c7g.8xlarge nodes (32 vCPUs, 64 GiB RAM each) deployed within the same Availability Zone and VPC placement group to minimize network jitter.
• Load Generator: memtier_benchmark v2.1.3 compiled with OpenSSL 3.0 and libevent.
• Workload Configurations:

- Balanced 1:1: 50% SET, 50% GET operations (representing dynamic state stores, rate limiters, and session storage).

- Read-Heavy 9:1: 90% GET, 10% SET operations (representing standard cache-aside web tiers).

- Key Space: 50,000,000 uniform keys, 32-byte key length, 128-byte value payload.

- Concurrency Matrix: 512 total client connections across 32 threads, tested under Pipeline Depth 1 (strict request-response latency) and Pipeline Depth 16 (high-throughput batching).

Reproducible Test Execution Commands:

# Test 1: Unpipelined request-response latency baseline (P=1, 9:1 Read-Heavy)
memtier_benchmark -s 10.0.1.10 -p 6379 -P redis \
  --threads=32 --clients=16 --pipeline=1 \
  --ratio=9:1 --data-size=128 --key-minimum=1 --key-maximum=50000000 \
  --key-pattern=S:S --test-time=900 --run-count=1

# Test 2: Batched high-throughput evaluation (P=16, 9:1 Read-Heavy)
memtier_benchmark -s 10.0.1.10 -p 6379 -P redis \
  --threads=32 --clients=16 --pipeline=16 \
  --ratio=9:1 --data-size=128 --key-minimum=1 --key-maximum=50000000 \
  --key-pattern=S:S --test-time=900 --run-count=1

Side-by-Side Throughput and p99 Latency Matrix

The following benchmark matrix synthesizes performance profiles across standalone instances, horizontal clusters, and Dragonfly on 64-core c7g.16xlarge infrastructure under standardized memtier_benchmark testing conditions.

Pipelining Dynamics and Tail Jitter Under Extreme Concurrency

The benchmark data highlights critical architectural behaviors. Under single-request latency conditions (Pipeline Depth 1), Dragonfly maintains a p99 latency below 0.65 milliseconds while sustaining 3.82 million operations per second on a single 64-core instance.

When evaluating redis cluster alternatives high throughput, horizontal clusters exhibit measurable tail-latency degradation at the 99th and 99.9th percentiles. In the 16-shard Redis 7.4 Cluster, p99 latency climbs to 2.14 ms at P=1 and rises to 8.90 ms under P=16 pipelining. This tail jitter stems from three concrete architectural factors:

1. Uneven Hash Slot Distribution: Real-world key access distributions inevitably create hot shards. In a clustered deployment, when one shard saturates its single execution core, client queues for that specific node back up, inflating p99 latency across the entire client application.

2. TCP Connection Multiplexing: A client interacting with a 16-shard cluster must maintain and poll 16 separate connection pools. Thread scheduling delays on the client side produce latency variance.

3. Valkey 8.0 Concurrency Gains: Valkey 8.0 demonstrates measurable progress over Redis 7.4. At P=16, Valkey Cluster processes 3.12 million ops/sec compared to 2.15 million ops/sec for Redis Cluster (an approximate 45% throughput improvement), while standalone Valkey 8.0 reaches over 1.21 million ops/sec through asynchronous response serialization.

Dragonfly circumvents clustering bottlenecks by operating within a unified shared-nothing memory space. Traffic automatically balances across core fiber queues. If a burst of traffic targets keys on Shard 4, the fiber scheduler allows other proactor threads to continue executing without blocking client connection sockets.

Memory Density, Dash-Tables, and Physical RSS Footprint

Metadata Allocation: jemalloc Overheads vs Dash-Table Efficiency

Memory efficiency directly dictates cloud hosting expenditures. In large-scale caching topologies managing hundreds of millions of keys, structural metadata often consumes more physical RAM than the underlying data payloads.

According to Redis internal data structure specifications and heap profiling analyses (such as redis-rdb-tools heap inspection), Redis and Valkey wrap every key-value pair in standard C structures:

• `robj` (Redis Object): Consumes 16 bytes per entry on 64-bit systems, storing a 4-bit type, 4-bit encoding, 24-bit LRU/LFU clock, a 32-bit reference count, and an 8-byte pointer to the actual payload.
• `dictEntry`: Consumes 24 bytes in raw C struct definitions (three 8-byte pointers: key pointer, value/payload union, and next entry pointer for hash collision chaining). Under jemalloc, this allocation rounds up to the 32-byte size class.
• SDS (Simple Dynamic String): Keys and string values require dynamic string headers (sdshdr8, sdshdr16), consuming 3 to 5 bytes of header metadata plus null terminators.
• jemalloc Binning and Internal Fragmentation: Memory allocations pass through jemalloc, which quantizes allocations into discrete power-of-two size bins (e.g., 8, 16, 32, 48, 64, 80, 96, 128 bytes). Small auxiliary structures experience internal padding waste.

When aggregated, Redis and Valkey demand between 48 and 64 bytes of structural metadata overhead per key entry before storing key names or payload contents. Profiling a store of 100 million empty keys demonstrates approximately 4.8 to 6.4 GiB (averaging ~5.5 GiB in jemalloc resident memory) dedicated solely to structural pointers and object wrappers.

Dragonfly memory efficiency 2026 is anchored in its custom Dash-Table implementation, drawing on algorithms published in the USENIX ATC research on Dash-Tables. Dash-Tables utilize a variant of bucketed Robin Hood hashing optimized for hardware CPU cache lines:

• Flat Cache-Line Buckets: Rather than chaining pointers across the heap, Dash-Tables pack entries into 64-byte buckets matching modern CPU L1 cache line sizes.
• 1-Byte Hash Fingerprints: Each bucket holds 1-byte hash fingerprints. Dragonfly inspects 14 fingerprints simultaneously using SIMD instructions before performing a full string comparison, virtually eliminating pointer chasing and L3 cache misses.
• Inline Small Value Storage: Small values (less than 16 bytes) are inlined directly into index records, bypassing secondary heap allocations.
• Dense Structural Packing: By avoiding separate robj and dictEntry wrappers, structural metadata drops to approximately 12 to 14 bytes per key—an approximate 70% reduction in structural metadata overhead.

100-Million Key RSS Footprint Comparison

To evaluate practical memory density, memory consumption was calculated across four representative caching schemas using heap profiling formulas validated against empirical /proc/$PID/status Resident Set Size (RSS) metrics after active memory defragmentation.

The data confirms that for small-to-medium cache entities (session records, permission flags, rate-limiting tokens), Dragonfly reduces physical RAM footprints by 18% to 55%.

According to official AWS EC2 On-Demand Pricing schedules (US East / N. Virginia region), an r7g.8xlarge instance (32 vCPUs, 256 GiB RAM) costs $1.3438 per hour ($11,771.69 annually), while an r7g.4xlarge instance (16 vCPUs, 128 GiB RAM) costs $0.6719 per hour ($5,885.84 annually). Shifting a 500-million key session tier from r7g.8xlarge to r7g.4xlarge cuts raw EC2 hourly compute spend by 50%, generating $5,885.85 in annual compute savings per node prior to reserved instance or Savings Plans discounts.

Snapshotting Mechanics: Copy-on-Write Memory Doubling vs Forkless Snapshots

In-memory caching tiers rely on point-in-time snapshotting (BGSAVE or RDB dumps) for disaster recovery snapshots and replica synchronization. However, background persistence represents a frequent operational failure domain in high-throughput environments due to Linux redis fork copy-on-write memory dynamics.

Redis and Valkey rely on the POSIX fork() system call to execute background saves:

1. The primary daemon invokes fork(), generating a child process sharing identical page table entries.

2. The Linux kernel applies Copy-on-Write (COW). The parent and child processes initially reference the same physical memory frames.

3. When client write commands modify keys in the parent process, the memory write triggers a minor page fault (handle_mm_fault). The Linux kernel must allocate and copy an entire 4 KB physical memory page (or 2 MB if Transparent Huge Pages is active) before writing.

4. Under write-intensive workloads (such as session updates or high-frequency telemetry logging) occurring during an active RDB generation window, modifying keys distributed across memory pages forces substantial page duplication. Linux memory profiling demonstrates that 40% to 80% of active pages can be cloned under sustained write operations, potentially doubling physical memory requirements during snapshot generation.

5. If total allocated memory exceeds available system RAM and swap capacity, the Linux Out-Of-Memory (OOM) killer selects the caching process for termination (kill -9), resulting in catastrophic cache eviction and backend traffic stampedes.

To protect against OOM termination during fork() operations, database administrators traditionally provision 50% to 100% idle memory headroom, significantly elevating baseline infrastructure costs.

Dragonfly eliminates this operational vulnerability via forkless user-space snapshotting:

• Dragonfly completely avoids the POSIX fork() system call.
• When an RDB snapshot or replication stream is initiated, Dragonfly dispatches a background serialization fiber across each core proactor shard.
• Shard fibers iterate through local Dash-Table buckets sequentially, serializing key-value pairs directly to disk or network sockets.
• If an incoming client write targets a bucket that has not yet been serialized, Dragonfly's VLL coordinator intercepts the write, appends the unmodified pre-image to the snapshot stream, and completes the in-memory update.
• Memory overhead during snapshotting is restricted to buffering dirty keys in flight rather than cloning full OS memory pages. According to DragonflyDB technical documentation and memory profiling logs, RSS increase during snapshotting remains bounded (typically between 8% and 15% even under heavy write traffic). Consequently, operators can safely provision Dragonfly at 80% to 85% memory utilization without risking Linux OOM failures.

Production Configuration Migration: From redis.conf to Modern Engines

Configuration Directive Mapping Reference

Migrating from a legacy Redis configuration to Valkey is direct due to full parameter parity. Migrating to Dragonfly requires transitioning from a centralized redis.conf file to command-line flags or a YAML configuration format designed for multi-threaded operation.

Production Kubernetes StatefulSet Deployment Trace

The following production-grade Kubernetes manifest deploys Dragonfly v1.26 as a high-density caching tier. It configures the container with direct host sysctl tuning via a privileged initContainer, assigns explicit multi-core resource allocations, mounts persistent storage for snapshots, and establishes non-blocking readiness probes.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: dragonfly-cache
  namespace: data-tier
  labels:
    app.kubernetes.io/name: dragonfly
    app.kubernetes.io/component: in-memory-cache
spec:
  serviceName: dragonfly-headless
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: dragonfly
  template:
    metadata:
      labels:
        app.kubernetes.io/name: dragonfly
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "6379"
        prometheus.io/path: "/metrics"
    spec:
      initContainers:
        - name: init-kernel-tuning
          image: busybox:1.36.1
          securityContext:
            privileged: true
          command:
            - /bin/sh
            - -c
            - |
              sysctl -w net.core.somaxconn=65535
              sysctl -w vm.overcommit_memory=1
              if [ -f /sys/kernel/mm/transparent_hugepage/enabled ]; then
                echo never > /sys/kernel/mm/transparent_hugepage/enabled
              fi
      containers:
        - name: dragonfly
          image: docker.dragonflydb.io/dragonflydb/dragonfly:v1.26.0
          args:
            - "--proactor_threads=32"
            - "--maxmemory=58GB"
            - "--cache_mode=true"
            - "--snapshot_frequency=3600"
            - "--dbfilename=dump.rdb"
            - "--dir=/data"
            - "--max_connections=65000"
            - "--keys_output_limit=8192"
          ports:
            - name: redis-port
              containerPort: 6379
          resources:
            requests:
              cpu: "30"
              memory: "60Gi"
            limits:
              cpu: "32"
              memory: "64Gi"
          securityContext:
            capabilities:
              add:
                - SYS_RESOURCE
          livenessProbe:
            tcpSocket:
              port: 6379
            initialDelaySeconds: 15
            periodSeconds: 10
            timeoutSeconds: 3
          readinessProbe:
            exec:
              command:
                - /usr/local/bin/dragonfly
                - "health"
            initialDelaySeconds: 5
            periodSeconds: 5
            timeoutSeconds: 2
          volumeMounts:
            - name: dragonfly-storage
              mountPath: /data
  volumeClaimTemplates:
    - metadata:
        name: dragonfly-storage
      spec:
        accessModes: [ "ReadWriteOnce" ]
        storageClassName: "gp3-sc"
        resources:
          requests:
            storage: 100Gi

Systems Selection Matrix: Selecting the Right In-Memory Engine

Selecting an in-memory caching engine requires balancing raw performance against operational surface area, client compatibility, and long-term licensing risk.

Decision Tree:
               Are you locked to legacy Redis modules or strict BSD license?
                                 /                \
                              (Yes)               (No)
                               /                    \
                     Deploy Valkey 8.0     Do you need >1M QPS per node or
                     (Zero code changes,   want to avoid cluster sharding?
                      standard clusters)          /                \
                                               (Yes)               (No)
                                                /                    \
                                     Deploy Dragonfly        Remain on Redis / Valkey
                                    (Vertical scaling,        (Traditional topologies)
                                     dense Dash-Tables)

When to Choose Valkey 8.0:

1. Zero-Friction BSD Migration: For organizations with corporate software governance policies that prohibit non-OSI licenses like SSPL or RSALv2, Valkey provides a direct, BSD-licensed drop-in replacement for Redis 7.x without modifying client SDKs or deployment scripts.

2. Existing Redis Cluster Infrastructure: Organizations operating automated Redis Cluster deployment pipelines (such as the Redis Operator on Kubernetes or custom Terraform automation) can substitute Valkey binaries directly into existing shard topologies.

3. Complex C Modules: Applications depending on custom C/C++ engine extensions compiled specifically against the Redis Module API will find drop-in binary compatibility in Valkey.

When to Choose Dragonfly:

1. Vertical Cloud Consolidation: When an application requires 1 million to 4 million QPS, deploying a single 32-core or 64-core Dragonfly node replaces a sprawling 16-node or 32-node Redis Cluster. This eliminates cluster bus routing hops, cross-slot multi-key restrictions, and client-side connection pooling overhead.

2. Memory Footprint Optimization: For environments caching massive datasets composed of small keys, Dragonfly's Dash-Table architecture cuts physical RAM consumption by 30% to 55%, translating to immediate savings on cloud compute infrastructure.

3. High-Write Persistence Resiliency: Workloads requiring durable disk persistence alongside aggressive write traffic benefit from Dragonfly's forkless snapshotting, permanently eliminating COW memory doubling and OOM termination risks.

When evaluating distributed caching architecture and high-throughput backend services, engineering teams frequently partner with Wise Hustlers for custom software engineering to architect low-latency data pipelines, profile Linux kernel bottlenecks, and execute zero-downtime database migrations.

When to Remain on Commercial Redis:

1. Active-Active Geo-Distribution: Redis Enterprise provides Conflict-Free Replicated Data Types (CRDTs) for multi-region active-active deployments that are not natively available in Valkey or Dragonfly.

2. Proprietary Module Ecosystem: Projects reliant on advanced proprietary modules like RedisSearch or RedisJSON enterprise extensions with dedicated commercial support agreements.

Frequently Asked Questions

Can Dragonfly execute existing Redis Lua scripts and transactions?

Yes. Dragonfly supports standard Redis transactions (MULTI/EXEC) and Lua scripting via EVAL and EVALSHA. Because Dragonfly operates on a multi-threaded, shared-nothing architecture, transactions and Lua scripts that access keys across multiple core shards run through Dragonfly's Very Light Locking (VLL) coordinator. While individual transactions remain strictly serializable and atomic, running long-running Lua scripts containing loops or scanning broad key spaces can introduce latency across involved shards. For optimal performance under multi-threaded architectures, multi-key operations should declare targeted keys explicitly via standard Redis API conventions.

How does Valkey compare to Redis Cluster alternatives for high-throughput scaling?

According to the Linux Foundation Valkey 8.0 release report and AWS Graviton performance evaluations, Valkey 8.0 improves throughput by 25% to over 200% under high-concurrency pipelined I/O workloads, reaching over 1.2M QPS on a single instance through asynchronous multi-threaded I/O and concurrent RESP parsing. However, because core dictionary mutations remain serialized on the primary execution thread, scaling write throughput beyond single-node limits still requires deploying Valkey Cluster across distributed shards. Dragonfly provides an alternative to Redis Cluster by scaling vertically to multi-million QPS within a single process via shared-nothing thread-per-core fibers, eliminating cluster rebalancing, hash slot migrations, and cross-slot constraints.

Does Dragonfly support the Redis Cluster protocol for client SDKs?

Yes. Dragonfly includes an emulation flag (--cluster_mode=emulated) that allows Redis Cluster-aware client SDKs (such as jedis, redis-py cluster, or go-redis/v9) to connect directly to a single Dragonfly instance. When cluster mode is enabled, Dragonfly intercepts CLUSTER SLOTS and CLUSTER SHARDS commands, reporting that all 16,384 hash slots reside on the single Dragonfly host. This allows applications designed for Redis Cluster to migrate without requiring client-side code modifications.

What is the impact of Linux Transparent Huge Pages (THP) on Dragonfly and Valkey?

Transparent Huge Pages (THP) should be disabled (echo never > /sys/kernel/mm/transparent_hugepage/enabled) for both Valkey and Dragonfly, though for different operational reasons. In Valkey and Redis, THP dramatically exacerbates Copy-on-Write memory duplication during fork(): instead of duplicating 4 KB pages on memory writes, the kernel duplicates entire 2 MB huge pages, causing rapid memory exhaustion. In Dragonfly, while forkless snapshotting eliminates COW risks, THP can still introduce tail-latency spikes due to kernel memory defragmentation pauses (khugepaged). Disabling THP is an essential production configuration across all in-memory caching tiers.

How does Dragonfly's memory eviction policy differ from Redis LRU?

Redis and Valkey approximate Least Recently Used (LRU) eviction by sampling a random set of keys (typically 5 to 10 keys configured via maxmemory-samples) and evicting the oldest key among the sample. This probabilistic approach saves memory but can prematurely evict frequently accessed keys. Dragonfly implements a cache eviction algorithm based on the 2Q (Two-Queue) cache replacement strategy. 2Q separates keys into probationary and high-priority queues, tracking access frequencies without the high overhead of standard LRU linked lists. As documented in caching research, 2Q delivers higher cache hit ratios under skewed Zipfian access distributions.

Sources

• Linux Foundation Valkey Project - Open source repository, technical specifications, and release notes for Valkey 8.0.
• Linux Foundation Valkey Launch Announcement - Official charter and participating organization announcements for the Valkey open-source project.
• DragonflyDB Architecture Documentation - Systems architecture specifications, fiber engine design, and Dash-Table whitepapers.
• Redis Software License Agreement - Official documentation detailing Redis Ltd's transition to RSALv2 and SSPLv1.
• USENIX Annual Technical Conference (ATC) - Dash-Tables - Fast and scalable hash tables with bucketed Robin Hood hashing.
• AWS EC2 On-Demand Pricing Schedules - Official compute instance pricing schedules for r7g and c7g instance families.
• Linux Kernel Documentation - Memory Management - Technical reference on vm.overcommit_memory, somaxconn, and Copy-on-Write page fault mechanics.
• memtier_benchmark Repository - Standardized NoSQL throughput and latency benchmarking harness.
• Redis Persistence Documentation - Redis background snapshotting (BGSAVE), fork semantics, and Linux memory allocation considerations.