DEV Community: Sunny Sahijwani

memdb-oracle: an agent that answers Redis-vs-Dragonfly questions only from measured data.

Sunny Sahijwani — Tue, 22 Sep 2026 17:31:52 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

Choosing between Redis, Valkey, Dragonfly, KeyDB and Garnet is a decision you cannot afford to get wrong, and the loudest sources are vendor pages. Earlier this month I published an independent benchmark of these engines on 48 bare-metal cores, with the harness, pinned versions and raw data public. memdb-oracle is an agent that answers questions from that data. When a vendor's page says one thing and the measurement says another, it shows both, with sources, and tells you which one was measured.

Why structured content is the whole point: "at 16 cores, read-heavy, pipeline 16, which engine has the lower p99?" is not a search. It is a query over 478 run documents, each with every knob that moved the number as a field: engine, mode, cores, read/write ratio, value size, pipeline depth, repetition, throughput, p50/p99/p99.9, hit rate, session. A keyword search over my blog posts returns a paragraph. GROQ returns two medians and the run ids behind them.

Three things it does that I could not get from a search box:

Numbers come only from GROQ, prose only from the Knowledge Base. Every answer ends with the exact GROQ it ran and the _ids of the runs it used, so anyone can verify it against the public dataset.
Vendor claim and measurement side by side. Ask "Is Dragonfly 25x faster than Redis?" and it reads Dragonfly's own claim from the Knowledge Base, runs the queries, and answers: not on this hardware, 3.4× over a realistic Redis cluster and 38% of the fully driven ceiling, and here is why the vendor's single-process comparison is a different test.
It refuses to invent. Ask for a combination that was never measured and it says so and lists the nearest real rows. Ask about Postgres and it declines in one paragraph.

It also explains terms for people new to benchmarking, from the benchmark glossary in the Knowledge Base, and marks anything it explains from general knowledge as exactly that.

Demo

Live: https://memdb.two-techies.com — no login. Example questions are pre-loaded as chips. Each answer shows the Sanity tool calls it made and ends with the GROQ it ran. A turn takes 30 to 60 seconds because it is five to ten sequential Context MCP calls plus model reasoning; the page streams tool activity while it runs. Limit: 30 questions per IP per day.

Three curated answers from the session log (full versions with every tool call in docs/TRANSCRIPTS.md):

"Is Dragonfly 25x faster than Redis?" — 7 GROQ queries and 1 Knowledge Base read.

Short answer: not on this hardware, in this benchmark. Measured, the gap is about 3.4× — and it flips the other way against a fully-driven Redis cluster.

Vendor statement (context, not measurement): Dragonfly's own marketing claims "25× higher throughput than Redis", backed by their AWS c6gn.16xlarge figures of ~3.97M QPS versus ~130k QPS on GET (KB entry Dragonfly Self-Reported Performance Claims). That ~130k/s figure is a single Redis process, one core doing the data work, versus a Dragonfly process using the whole machine.

Measured, this dataset (ground truth here). Session 1, AWS c7i.metal-24xl, 48 cores, read-heavy SET:GET 1:10, 100 B values, pipeline 16, hit rate 1.0, median across reps:

Configuration	Throughput (median)	vs Dragonfly
Dragonfly, 1 process (`single`)	15.5 M ops/s	—
Redis Cluster, 48 shards, `cluster` (realistic: one normal client)	4.6 M ops/s	Dragonfly 3.4× faster
Redis Cluster, 48 shards, `cluster-sat` (driven ceiling, one client per shard)	40.6 M ops/s	Redis 2.6× faster

Why the claim and the measurement differ: the 25× comparison is one Dragonfly process against one Redis process. The KB entry Common Benchmark Pitfalls calls this "not a fair fight": Redis executes commands on one thread, so the like-for-like peer is a Redis Cluster with one shard per physical core. This dataset contains no single-process Redis runs, so the vendor's exact comparison cannot be reproduced here.

Plain words: on the test machine here, Dragonfly served about three and a half times as many requests per second as a normal Redis cluster, and about a third as many as a Redis cluster pushed as hard as the hardware allows — nowhere near twenty-five times either way.

"Give me the Redis single-process result at 8 cores with pipeline 64." — never measured.

No matching run exists. Two parts of the request are not in the dataset: pipeline 64 was never measured (the only depths are 1 and 16), and Redis has no single-mode runs; it appears only as cluster and cluster-sat, because one Redis process cannot use more than one core for command execution. Nearest measured combinations, Redis at 8 cores, pipeline 16, 100 B: cluster (realistic) 5.0 M ops/s with p99 35.2 ms; cluster-sat (driven ceiling) 9.2 M ops/s with p99 0.78 ms.

"Which is better for my Postgres workload, MySQL or Postgres?" — out of scope, zero tool calls.

That question is outside what I can answer. This dataset only covers in-memory data stores (Redis, Valkey, Dragonfly, KeyDB, Garnet) and their benchmark runs, not relational databases. What it can help with instead: throughput, p50/p99/p99.9 latency, hit rate, memory per key, and scaling behaviour across cores, value sizes, pipeline depths and read/write ratios for those five engines, plus the vendor claims and glossary definitions behind them.

Code

https://github.com/sunnysahijwani/memdb-oracle (MIT)

The whole agent is one file plus a system prompt. It uses the Claude API's MCP connector, so Sanity's Context MCP is called server-side and there is no MCP client code at all: one API call per turn, streamed to the page over server-sent events. The repo also holds the schema, the CSV importer, the golden-number script and 13 tests (6 offline, 7 live against the real endpoints).

How I Used Sanity

Schema. Four document types in sanity/schemaTypes/:

benchmarkRun — one document per measured run, 30 fields in four fieldsets: identity and provenance (session, runId, the source CSV and line number, so every number is traceable), server configuration (mode, shards, coresUsed, cpuset), workload (ratio, dataBytes, pipeline, client threads and connections) and results (opsPerSec, p50/p99/p99.9, hitRate). Deterministic _ids, so re-import is idempotent; I ran it twice and the count stayed at 497.
engine — version pinned in the harness, threading model, configuration notes the agent must repeat, and the vendor page whose claims the Knowledge Base compares against.
finding — a headline number with its caveat, its metrics, and the verbatim vendor claim it is usually compared to.
benchmarkSession — because two capture sessions on different dates must never be compared silently.

Import. CSV → NDJSON → sanity dataset import --replace. The importer keeps only the bare-metal capture rows (350 from the Dragonfly/Redis/Valkey session, 128 from the KeyDB/Garnet session), validates every field, and drops 147 smoke, laptop and diagnostic rows that were never measurements. A grep-based leak test makes sure a private client experiment I have not published never enters the dataset or the Knowledge Base.

Knowledge Base. Sources: the nine write-up pages (Website), the benchmark glossary, measurement playbook and findings (Files), the finding/engine/benchmarkSession documents (Dataset — deliberately not the 478 runs, those are for GROQ), and the vendor pages: Dragonfly's homepage and comparison pages, the Redis benchmarks page, KeyDB's docs landing page and Garnet's published results.

The first build raised eight Issues. Four were thin entries it offered to merge; I kept them standalone. The other four were Conflicts, marked Critical, that I had not told it to look for:

Dragonfly's "25× more QPS than Redis" vs the measured 3.4× over a realistic cluster.
Dragonfly's "30–60% better memory" vs the measured 12–13% (146 vs 165 bytes/key).
Garnet "higher throughput than Dragonfly" vs my note that Garnet's 21.4M is a client-limited floor from a different session and a different load generator.
Dragonfly's "sub-1 ms p99" vs the measured 2.42 ms at pipeline 16 and 0.55 ms without pipelining.

Each resolution became an Instruction, a standing rule tied to the sources. When I then clicked Update entries, the build re-read the vendor pages against those rules, flagged four of them as contradicting a rule, and rewrote them as "Quality fix" issues. Two of the four rules now show as Archived, because the entries they governed were rewritten and carry the decision themselves; I checked afterwards and the agent still answers the memory question with the measured figure as ground truth and the vendor figure as context. The re-read also raised four issues I dismissed: one about Dragonfly Cloud pricing, which is out of scope, and three where the build read two vendors' claims about different Dragonfly versions, or Dragonfly's 15.5M next to Garnet's 21.4M, as contradictions. They are different engines and different setups, and both numbers are true. Conflict detection is good at finding real disagreements; it still needs a human to say when two statements are simply about different things.

That is the mechanism the agent leans on when it says "measured is ground truth here, the vendor figure describes their own setup".

Context MCP. Two endpoints, same organisation token: memdb serves the dataset (tools initial_context, schema_explorer, groq_query, array_field_reader) and memdb-kb serves the Knowledge Base (initial_context, knowledge_base_read). The system prompt forbids numbers from anywhere but groq_query and prose from anywhere but knowledge_base_read. Both endpoints carry the same custom instructions: cite the entry or run ids, measured data is ground truth, Garnet is client-limited, sessions are not comparable without saying so.

What went wrong, honestly.

My first Dragonfly crawl pulled 492 pages and blew straight through the plan's 150-indexed-document cap (634 of 150). The fix was better than the original: I re-added only the homepage bucket and the five comparison pages, because the claims I contradict live on exactly those pages.
I wanted one endpoint with both sources, which the docs suggest is the common setup. In the editor, only the last saved source survived a refresh: attach the Knowledge Base and the dataset dropped off, and GROQ mode then failed with a misleading "deploy a Studio v5.1.0+" error while the Studio was deployed and the schema listed. Two endpoints, one source each, fixed it in ten minutes.
The model narrated "I'll start by loading both sources" before its first tool call and that leaked into the chat. Fix: the final answer is the text after the last tool call, plus a one-line rule in the prompt.
After deploying, the Ask button reloaded the page with /? instead of asking. A patch to the chat page had spliced the script at the wrong </script> and duplicated it, so the browser threw "Identifier 'examples' has already been declared" before the submit handler was attached. Headless Chrome and an on-page error banner found it in minutes; the lesson is that curl-testing the API is not testing the page.
Turns are slow, 30 to 60 seconds, because each is a chain of sequential MCP round trips through the API plus reasoning. Streaming the tool activity to the page made that acceptable; it did not make it fast.

Sanity Project Details

Project ID: ynsa3nyp, dataset production (public). Try it without a token: https://ynsa3nyp.api.sanity.io/v2025-08-15/data/query/production?query=count(*%5B_type%3D%3D%22benchmarkRun%22%5D)
Browse the dataset, no login: https://memdb.two-techies.com/dataset (reads the public API live; raw overview query: https://ynsa3nyp.api.sanity.io/v2025-08-15/data/query/production?query=%7B%22runs%22%3Acount%28%2A%5B_type%3D%3D%22benchmarkRun%22%5D%29%2C%22runsPerEngine%22%3A%2A%5B_type%3D%3D%22engine%22%5D%7Bname%2CversionTested%2C%22runs%22%3Acount%28%2A%5B_type%3D%3D%22benchmarkRun%22%26%26references%28%5E._id%29%5D%29%7D%2C%22findings%22%3A%2A%5B_type%3D%3D%22finding%22%5D%7Corder%28slug%20asc%29%7Btitle%7D%7D)
Studio (members only, as any Studio): https://memdb-oracle.sanity.studio/
Knowledge Base: memdb-kb, served by endpoint memdb-kb; dataset served by endpoint memdb.

Agent Session

I built this with Claude Code, but I am not embedding the raw session: the transcript carries private working context from my machine that no redaction layer would catch. Instead, the agent's own sessions are public in the repo: docs/TRANSCRIPTS.md holds seven verbatim answers with every Sanity Context tool call and the GROQ each one ran, straight from the agent's session log. The build itself is reproducible from the repo: npm run import:build rebuilds the 497 documents from the public CSVs, npm run golden recomputes the numbers the tests check against, and npm test runs the 13 tests, 7 of them live against the endpoints.

How long does a Redis Sentinel failover actually take? I measured it

Sunny Sahijwani — Wed, 16 Sep 2026 11:38:32 +0000

I killed an in-memory database primary on purpose — fifteen times, across three down-after-milliseconds settings and three engines (Redis 8, Valkey 8, Dragonfly) — and timed how long writes actually fail before a replica takes over. Short answer: **your failover window is roughly down-after plus about two seconds of election and promotion — and it's the same no matter which engine is dying.* Here's the runnable lab, the numbers, and the traps that bite in production.*

The answer up front

On a 1-primary / 2-replica / 3-sentinel setup (Redis 8, Docker), measured as the gap between killing the primary and the first successful write on the promoted replica:

`down-after-milliseconds`	write outage (mean of 3 runs)	individual runs
1000 (1s)	2.5s	2.52 / 2.54 / 2.56
5000 (5s, a common default)	7.3s	7.30 / 7.37 / 7.31
10000 (10s)	12.1s	12.09 / 12.12 / 12.09

The relationship is almost boringly linear: outage ≈ down-after + ~2s of quorum vote, leader election, and replica promotion. That overhead is the fixed cost; down-after is the dial you control. Nobody tunes it, and it's the single biggest factor in how long your app stares at a dead Redis.

And before you ask whether a different engine would fail over faster: I reran the same kill against Valkey 8 and Dragonfly under identical sentinels — at down-after=5s all three came back in 7.3–7.4s. The outage belongs to Sentinel, not to the engine — full table further down.

Everything below is reproducible — the lab, the kill script, and the sweep that produced this table are on GitHub: github.com/sunnysahijwani/redis-sentinel-failover-lab. docker compose up and kill the primary yourself.

The problem nobody notices until 3am

Here's a setup I see constantly. A Laravel app scaled across several web servers — three, five, ten app instances behind a load balancer. Feels highly available. But every one of those app servers talks to one Redis: cache, sessions, and the Horizon queue all live there.

That single Redis is a single point of failure hiding in plain sight. When it dies — OOM, a kernel panic, someone reboots the wrong box — it doesn't take down one app server. It takes down the shared state behind all of them at once:

Cache goes cold. Every request that used to hit Redis now hammers the database — a cache stampede right when you can least afford it.
Sessions vanish. Everyone's logged out.
The queue stops. Horizon can't read or write jobs; background work stalls.

Adding more app servers does nothing for this. The fix isn't more app servers — it's making Redis itself survive the loss of a node. That's what Redis Sentinel does, and this article is a working lab that proves it — with a stopwatch on it.

The options, briefly

There are three honest ways to get Redis high availability:

Redis Sentinel — you keep one primary and one or more replicas. A small quorum of "sentinel" processes watches the primary, and when it dies, they vote, pick the healthiest replica, and promote it to primary automatically. Your clients get pointed at the new primary. This is the standard answer for an app that fits on one node's worth of RAM (i.e. most apps).
Redis Cluster — shards your keyspace across multiple primaries, each with its own replica, with failover built in. You reach for this when your data or write throughput is too big for a single node. More moving parts — I've written about what cluster mode actually costs you operationally.
Managed (AWS ElastiCache, managed Valkey, etc.) — someone else runs the failover for you. Great, until you want to understand what you're paying for — which is exactly why building it once yourself is worth an afternoon.

We're centering on Sentinel, because it's the right tool for the non-sharded, multi-instance Laravel case, and because it's the one you can genuinely understand end to end.

How Sentinel works, in plain language

Four ideas and you've got it:

Monitoring. Each sentinel pings the primary continuously. If the primary doesn't answer for down-after-milliseconds, that sentinel subjectively marks it down.
Quorum. One sentinel's opinion isn't enough — that's how you'd get false alarms from a brief network blip. A configured number of sentinels (the quorum) must agree the primary is down before anything happens. This is why you run an odd number of them, typically 3 or 5.
Election & promotion. Once quorum agrees, the sentinels elect a leader among themselves, the leader picks the most up-to-date replica, and promotes it with REPLICAOF NO ONE. The other replicas are repointed at the new primary.
Client redirection. Your app doesn't hardcode the primary's address. It asks a sentinel "who is the master right now?" and connects to whatever it's told — so after a failover, it simply reconnects to the new one.

That last point is the one people miss: if your client points at a fixed IP, none of this helps you. The client has to be Sentinel-aware.

The lab: 1 primary + 2 replicas + 3 sentinels

Everything below is self-contained Docker. It touches nothing else on your machine, exposes no host ports, and cleans up completely.

`docker-compose.yml`

services:
  redis-primary:
    image: redis:8
    container_name: redis-primary
    command: redis-server --save "" --appendonly no --maxmemory-policy noeviction
    networks:
      redisnet:
        ipv4_address: 172.28.0.10

  redis-replica-1:
    image: redis:8
    container_name: redis-replica-1
    command: redis-server --save "" --appendonly no --maxmemory-policy noeviction
             --replicaof 172.28.0.10 6379 --replica-announce-ip 172.28.0.11
    depends_on: [redis-primary]
    networks:
      redisnet:
        ipv4_address: 172.28.0.11

  redis-replica-2:
    image: redis:8
    container_name: redis-replica-2
    command: redis-server --save "" --appendonly no --maxmemory-policy noeviction
             --replicaof 172.28.0.10 6379 --replica-announce-ip 172.28.0.12
    depends_on: [redis-primary]
    networks:
      redisnet:
        ipv4_address: 172.28.0.12

  redis-sentinel-1: &sentinel
    image: redis:8
    container_name: redis-sentinel-1
    command:
      - sh
      - -c
      - |
        printf 'port 26379\nsentinel monitor mymaster 172.28.0.10 6379 2\nsentinel down-after-milliseconds mymaster ${DOWN_AFTER:-5000}\nsentinel failover-timeout mymaster 10000\nsentinel parallel-syncs mymaster 1\n' > /etc/sentinel.conf
        exec redis-sentinel /etc/sentinel.conf
    depends_on: [redis-primary]
    networks:
      redisnet:
        ipv4_address: 172.28.0.21

  redis-sentinel-2:
    <<: *sentinel
    container_name: redis-sentinel-2
    networks: { redisnet: { ipv4_address: 172.28.0.22 } }

  redis-sentinel-3:
    <<: *sentinel
    container_name: redis-sentinel-3
    networks: { redisnet: { ipv4_address: 172.28.0.23 } }

networks:
  redisnet:
    driver: bridge
    ipam:
      config:
        - subnet: 172.28.0.0/16

A few deliberate choices worth calling out:

Static IPs. Sentinel identifies nodes by address. Fixed IPs make the demo deterministic and sidestep container-DNS quirks during a failover.
sentinel monitor mymaster 172.28.0.10 6379 2 — watch the primary; the trailing 2 is the quorum (2 of 3 sentinels must agree).
down-after-milliseconds is parameterised (DOWN_AFTER, default 5000) — that's the dial we're about to sweep.
Each sentinel writes its own config at boot. Sentinel rewrites its config file at runtime (to record replicas, epochs, etc.), so a shared read-only file breaks it — generating one per container in /etc is the robust pattern.

Kill the primary and watch

The repo's failover-demo.sh starts the cluster, writes one key per second through whatever Sentinel currently calls the master, then kills the primary. This is real output, not a mock-up:

==> 💥 KILLING THE PRIMARY:  docker kill redis-primary

==> The write log across the whole event (watch the master IP change):
   [001] wrote to master 172.28.0.10  OK
   [002] wrote to master 172.28.0.10  OK
   [003] wrote to master 172.28.0.10  OK
   [004] wrote to master 172.28.0.10  OK
   [005] write FAILED  (no reachable master yet)
   [006] write FAILED  (no reachable master yet)
   [007] write FAILED  (no reachable master yet)
   [008] wrote to master 172.28.0.11  OK
   [009] wrote to master 172.28.0.11  OK
   ...
==> New master = 172.28.0.11 ; confirm it now reports role:master
role:master
connected_slaves:1
demo:counter survived = 20

Read it top to bottom and you can see the entire incident: writes flowing to the original primary, a window of failures while the primary is dead and the sentinels are voting, then writes resuming against the promoted replica with no human involved — and the data survived.

Measuring the dial nobody tunes

The demo shows failover works. The next question is the one that matters at 3am: how long is that window, and what controls it?

The controlling config is down-after-milliseconds — how long a sentinel waits for silence before declaring the primary dead. Almost every tutorial copies a value (usually 5000 or 30000) without saying what it costs. So I measured it: for each of 1s / 5s / 10s, I ran the kill three times and timed the outage a client actually observes — writes attempted roughly every 350ms through Sentinel discovery, outage = kill → first successful write on the promoted node.

Result: the outage tracks the dial almost perfectly — ~2.5s at down-after=1s, ~7.3s at 5s, ~12.1s at 10s. Your window is down-after plus a 1.5–2.3 second promotion tax.

Three things worth reading off that chart:

The floor isn't zero. Even at down-after=1s, you eat ~2.5s of outage. Detection is only part of the window — quorum agreement, leader election among the sentinels, and the replica's promotion are a tax of roughly 1.5–2.3s in my runs that you pay regardless.
The relationship is linear, so the trade-off is legible. Every second you add to down-after is a second added to every real outage — and every second you remove increases the odds a GC pause, a fork() for persistence, or a brief network blip triggers a false failover. That false-positive risk is why you shouldn't just set it to 500ms and declare victory.
The variance is small. Three runs per setting landed within a tenth of a second of each other (max spread 0.07s). This is a deterministic machine, not a dice roll — which means you can actually plan around your configured window.

Method honesty, so you can attack it: this is Docker on a Mac, timed from the client side with ~0.1s of docker exec overhead per write, and failed attempts time out at 2s — so treat sub-second digits as approximate. The shape — fixed promotion overhead plus your down-after — is the durable finding, and the sweep script is in the repo so you can produce this table on your own hardware in about ten minutes.

Does the engine matter? Redis vs Valkey vs Dragonfly

There's a tempting thought hiding in that fixed ~2s tax: maybe a faster engine fails over faster. Valkey ships multithreaded I/O; Dragonfly is a from-scratch multithreaded rewrite that can be dramatically faster under load — I've benchmarked exactly that. Would either shave the outage window?

So I ran the identical experiment against all three. Same topology, same kill, and — deliberately — the same three redis:8 sentinels every time, so the only variable is the engine under them. (Valkey is a drop-in; Dragonfly officially supports Redis Sentinel as its HA mechanism.) Three runs each at down-after=5s:

engine	write outage (3 runs)	mean
Redis 8	7.30 / 7.37 / 7.31	7.33s
Valkey 8	7.37 / 7.38 / 7.36	7.37s
Dragonfly	7.33 / 7.36 / 7.43	7.37s

Fifteen kills across three engines, all within a tenth of a second of each other. Failover time is a property of Sentinel, not of the engine. Which makes sense once you've watched it happen: the window is detection silence (down-after) plus sentinel politics (quorum, leader election) plus one REPLICAOF NO ONE — the data engine is just the thing being pointed at. Switching to a faster engine won't buy back those seconds; tuning down-after will.

Two field notes from the non-Redis runs:

Dragonfly's Sentinel compatibility is real. Unmodified Redis sentinels discovered the Dragonfly primary and replicas and ran the promotion with zero special configuration. The only friction: Dragonfly refuses to start with less than 256MiB of maxmemory per thread, so tiny lab configs need --maxmemory raised accordingly.
Why Garnet isn't in this table: Microsoft's Garnet doesn't speak Sentinel — its HA story is its own cluster-mode replication. Timing that would be a different (interesting) experiment, not this one, and I'd rather leave a gap than publish an apples-to-oranges number. (Garnet's raw throughput, though, surprised me here.)

Wiring it to Laravel

The lab proves the infrastructure. The other half is making Laravel Sentinel-aware so it re-discovers the master after a failover instead of clinging to a dead IP. The Predis client supports this directly. In config/database.php:

'redis' => [
    'client' => 'predis',

    'default' => [
        // Point at the SENTINELS, not at a Redis master.
        'sentinel' => [
            'tcp://172.28.0.21:26379',
            'tcp://172.28.0.22:26379',
            'tcp://172.28.0.23:26379',
        ],
        'options' => [
            'replication' => 'sentinel',
            'service'     => 'mymaster',      // must match `sentinel monitor <name>`
            'parameters'  => [
                'password' => env('REDIS_PASSWORD'),
                'database' => 0,
            ],
        ],
    ],
],

Now Predis asks the sentinels who the master is and reconnects automatically when it changes. Point it at a fixed master IP instead and you've built all this machinery for nothing.

On phpredis: the C extension is faster and great for a plain single-node Redis, but it has no built-in Sentinel discovery — you'd implement the "ask a sentinel, then connect" dance yourself. If you want painless Sentinel support, Predis is the path of least resistance; if you're committed to phpredis, packages like Goopil/laravel-redis-sentinel wrap that dance for Laravel (including Horizon probes). Benchmark before assuming the client speed difference matters for your workload — for most apps it doesn't.

The traps nobody puts in the README

The demo is the easy 80%. These are the things that bite in production:

Failover is not zero data loss. Replication is asynchronous. A write acknowledged by the old primary but not yet copied to the replica is gone when that replica is promoted. Sentinel picks the most up-to-date replica to minimise it, but the window is real. For a cache, fine. For anything you truly cannot lose, understand this before you rely on it.
Tune down-after for your reality — now with numbers. Your total outage is down-after + ~2s. Pick the largest value your SLO tolerates, because the price of going lower is false failovers: a stop-the-world GC pause or a 2-second network blip at down-after=1s triggers a needless promotion, and needless promotions are how you discover the data-loss window above.
Your queue and your cache should not share a failover group. Your cache wants an eviction policy (allkeys-lru); your Horizon queue must use noeviction or it will silently drop jobs when memory fills. Different criticality, different data-loss tolerance — run them as separate Redis instances, each with its own sentinels.
In-flight jobs during the window. Whatever a worker was mid-processing when Redis vanished may be retried after recovery. Make your jobs idempotent and set sensible retry/backoff. This is a feature (nothing is lost) only if your jobs can safely run twice.
Quorum and placement. An odd number of sentinels (3 or 5), spread across separate failure domains — not all on the same host as the Redis nodes they watch. Two sentinels on the same box that dies is a quorum you can lose in one stroke.
Enable persistence in production. I disabled it in the lab for clarity. In production, run AOF on at least the replicas so a promoted node comes up with data, not empty.

When Sentinel isn't enough

Sentinel gives you availability for a dataset that fits on one node. You've outgrown it when:

Your data or write throughput is bigger than a single node can hold → Redis Cluster (sharding) — see what that costs operationally and what it does to your realistic throughput.
You don't want to run, patch, and monitor sentinels yourself → managed (ElastiCache / managed Valkey) does exactly this failover for you. Now that you've built it by hand, you know precisely what that bill is buying: the on-call rotation for the bullet points above.
You need multi-region survivability → that's a bigger conversation than Sentinel alone.

The takeaway

Adding app servers makes you feel highly available. Surviving the loss of your Redis node is what makes you highly available — and now you know exactly what it costs: down-after-milliseconds + ~2 seconds of write outage, measured, not guessed — and identical whether the node runs Redis, Valkey, or Dragonfly. Kill the primary yourself once — the lab is right here and takes five minutes. Seeing writes resume on a promoted replica, untouched by human hands, is worth more than any diagram.

Lab: Redis 8 / Valkey 8 / Dragonfly data nodes under redis:8 sentinels, Docker on macOS, 1 primary + 2 replicas + 3 sentinels, quorum 2, failover-timeout 10000. Outage = kill → first successful client write on the promoted node, via Sentinel discovery, 3 runs per setting and engine. Failover window and data-loss characteristics vary with replication lag and hardware — run it yourself and tune to your workload.

If you found this useful, the same measure-don't-guess approach applied to engine choice lives in my Dragonfly vs Redis vs Valkey benchmark series, with an interactive explorer for the raw data.

About the author — I'm Sunny Sahijwani, a senior backend & DevOps engineer. 👉 Connect with me on LinkedIn — I'm always happy to talk in-memory databases, performance, and systems architecture.

The full lab — docker-compose, kill scripts, the sweep, and raw CSVs — is public on GitHub — rerun it and tell me where I'm wrong.

Originally published on two-techies.com.

When to use which: Dragonfly vs Redis vs Valkey

Sunny Sahijwani — Mon, 14 Sep 2026 05:50:28 +0000

Part 7 of 7 · ← Operational simplicity · Series index

Part 7, the finale. Six posts of measurements come down to this: there is no universal winner, and the right choice depends on which corner of a three-way trade-off you care about. Here's the decision guide I'd actually give a team.

The one-screen summary

Dimension	Dragonfly	Redis / Valkey Cluster
Throughput, normal client	~3.4× the cluster (15.5M vs 4.6M @48c)	plateaus early; more shards don't help a naive client
Throughput, perfectly driven	15.5M (that is driven — one endpoint)	raw ceiling wins: ~40M — but needs per-shard routing + a client as big as the server
Effort to reach its throughput	trivial (one-line client)	serious client-side engineering + client hardware
Latency under load	sub-ms, predictable	sub-ms if driven well; hundreds of ms with a naive client
Multi-key / transactions / Lua	works across the whole keyspace on one node	same-slot only (hash-tag tax)
Memory / key	~13% leaner	baseline
Failure domain / HA	bigger blast radius per node; has replicas + cluster	smaller shards = smaller blast radius, mature, elastic
Governance / licensing	source-available (BSL)	Redis 8 tri-licensed (incl. AGPL); Valkey = BSD, Linux Foundation

The three-way trade-off

Every "which is best" argument is really about which of these three you're optimizing — you rarely get all three:

Throughput-per-node — most work out of one box.
Operational simplicity — fewest moving parts, no cross-slot data modeling, a dumb client.
Failure domain / elasticity — small blast radius, easy incremental scale-out, mature HA.

Dragonfly wins 1 and 2 decisively for the single-big-node case. Redis/Valkey Cluster wins 3, and wins 1 only if you'll invest to drive it. That's the whole map.

Pick by scenario

Reach for Dragonfly when…

you want a lot of throughput from one node with a normal client and minimal ops — the common case, where it's ~3.4× a realistic cluster;
you need multi-key ops / transactions / Lua across arbitrary keys while using all your cores;
you'd rather scale up than operate a cluster, and pair one big node with a replica for HA;
you're memory-sensitive on many-small-keys workloads.

Reach for Redis / Valkey Cluster when…

you need maximum raw throughput and can invest in flawless client-side routing + a large client fleet (the 40M ceiling is real if you'll pay for it);
you want small failure domains and elastic horizontal scale — many modest shards + replicas, so losing one shard blips 1/N of the keyspace;
you've outgrown a single big machine (at which point Dragonfly would shard too, and hit the same cross-slot wall);
you want the most mature, battle-tested clustering, or a specific license (Valkey's BSD / Linux Foundation governance is a real reason on its own).

Valkey vs Redis specifically: performance is a wash (Valkey is the Redis 7.2 fork; both are multi-threaded-I/O now). Choose on governance and licensing, not benchmarks.

The honest one-liner

Redis Cluster has the higher raw ceiling; Dragonfly gives you most of the throughput for almost none of the operational cost. If you can engineer for the ceiling, take it. If you'd rather not, Dragonfly is the better default — and for a single big node with a normal client, it isn't close.

What I'd do

For a new service that fits comfortably on one large node — which is most services — I'd start with Dragonfly: near-top throughput, sub-ms latency, full multi-key semantics, less memory, and a client I don't have to think about. I'd move to a cluster (Dragonfly's or Redis/Valkey's) when I genuinely outgrow one machine or need small failure domains for HA — and I'd go in knowing the cross-slot tax and the client-side engineering that "using the cluster's throughput" actually requires.

That's the series. Everything — the harness, pinned versions, raw runs.csv, and the analysis scripts — is public at github.com/sunnysahijwani/dragonfly-redis-valkey-benchmark so you can rerun and challenge all of it. Verified against the DragonflyDB team's benchmarking notes before publishing; the fairness methodology (and the bias I caught in my own setup) is in Part 1. You can also explore every number interactively in the Benchmark Explorer.

Benchmarked on AWS c7i.metal-24xl (48 physical Sapphire Rapids cores) + c7i.24xlarge client, us-east-1, same placement group. Redis 8.2.8 · Valkey 8.1.9 · Dragonfly v1.40.1 · memtier 2.5.1 · io_uring · client-side latency.

Operational simplicity: the cross-key tax, quantified

Sunny Sahijwani — Sun, 13 Sep 2026 08:45:00 +0000

Part 6 of 7 · ← Memory efficiency · Next: When to use which →

Part 6. Throughput and latency are what benchmarks measure. This is the thing they usually miss — and it's where Dragonfly's real structural advantage lives. It's also where I have to be most careful to stay honest, because it's easy to overclaim here.

The demo (run it yourself)

Take three plain keys and ask each engine to fetch them in one command. On a single Dragonfly process and on a single Redis, this just works. On a Redis Cluster it doesn't:

Redis Cluster (slots: alpha=865  bravo=8623  charlie=1769)
  MGET alpha bravo charlie      → CROSSSLOT Keys in request don't hash to the same slot
  EVAL over alpha bravo charlie → CROSSSLOT Keys in request don't hash to the same slot
  MGET {u1}:name {u1}:email     → OK   (same hash-tag → same slot)

Dragonfly (single process)
  MGET alpha bravo charlie      → OK
  EVAL over alpha bravo charlie → OK

This isn't a bug — it's how Redis Cluster is designed. Each shard is an independent process that only holds its slice of the 16,384 hash slots, and it refuses any multi-key command whose keys don't all live in the same slot, rather than doing a slow cross-shard scatter-gather.

Why it matters: multi-key isn't a convenience, it's atomicity

MGET being rejected is mildly annoying — you can do three separate GETs. But the same rule hits MULTI/EXEC transactions and Lua scripts, and those are how you do atomic multi-key logic:

deduct from wallet:A, credit wallet:B, all-or-nothing;
check stock:item, decrement it, write reserved:user — atomically, so two buyers can't grab the last unit.

On a single Dragonfly (or single Redis) you write one Lua script over whatever keys you need and it runs atomically. On a Redis Cluster, that script can only touch same-slot keys — so you must force the related keys onto one slot with a hash-tag ({group}:...). That works, but it:

concentrates those keys on one shard — you lose the load-spreading you sharded for, and
forces you to decide, at data-model time, which entities will ever need to be touched together — often impossible to predict.

That's the tax. It's not "Redis is worse" — it's the unavoidable cost of splitting one logical keyspace across independent processes.

Quantified: multi-key throughput

Because Dragonfly handles cross-key ops natively, I could benchmark them — MGET/MSET of 10 keys, scaling with cores:

MGET(10), pipeline 16: 4c → 0.3M, 8c → 0.5M, 16c → 0.9M, 24c → 1.3M, 48c → 2.4M commands/sec (= ~24M keys/sec).
MSET(10), pipeline 16: scales similarly to ~1.3M commands/sec at 48 cores.

The Redis/Valkey clusters get no bar on this chart — cross-slot multi-key is rejected outright. To make it work you'd hash-tag everything onto shared slots, which changes the workload (and the point).

The honesty guard — this is important

It would be easy, and wrong, to say "Dragonfly has no sharding limits." It does. Dragonfly Cluster, once you scale it across machines, uses the same 16,384-slot model and returns the same CROSSSLOT error. Dragonfly's advantage is narrower and more honest:

A single Dragonfly node uses all your cores without sharding — so it keeps single-instance semantics (any multi-key op, atomic Lua, transactions) while scaling up. You postpone clustering — and its cross-key tax — until you genuinely outgrow one big machine. With Redis you pay that tax the moment you need more than one core's worth of throughput.

Not "never." Later. For a lot of workloads, "later" means "never in practice," because one big Dragonfly node goes a very long way. But if you truly outgrow a single machine, both engines shard and both hit the same wall.

The takeaway

The cross-key tax is the clearest structural difference between the two designs. Redis makes you choose, quite early, between using all your cores and keeping multi-key atomicity across arbitrary keys. Dragonfly lets you have both on one node. That — not raw ops/sec — is the strongest case for it.

Next: Part 7 — when to use which, where all of this becomes a decision table. You can also explore every number in this series interactively — filter by workload, cores, and pipelining — in the Benchmark Explorer.

Memory efficiency: bytes per key

Sunny Sahijwani — Sat, 12 Sep 2026 07:51:33 +0000

Part 5 of 7 · ← Latency under load · Next: Operational simplicity →

Part 5. The shortest post in the series, and the least arguable number in it — because memory footprint is about data-structure design, not how hard you drive the client. It's the same on a laptop and on 48 bare-metal cores.

The measurement

I loaded 1,000,000 keys × 100-byte values into each engine, subtracted the empty-server baseline, and divided by key count:

Engine	bytes / key	vs Dragonfly
Dragonfly	146.1	—
Redis 8.2	165.3	+13%
Valkey 8.1	168.7	+15%

Dragonfly stores the same data in ~12–13% less memory than Redis, and a bit less than Valkey.

Why this one is trustworthy

Two reasons I trust this number more than any throughput number:

It's hardware-independent. I got 146.1 / 165.3 / 168.7 on my laptop and 146.1 / 165.3 / 168.7 on the c7i.metal box — to the decimal. Memory layout doesn't care about cores, io_uring, or how big your client is. There's nothing to "drive" and nothing to get wrong.
It's methodology-proof. No pipelining, no cluster routing, no client bottleneck — just "store a million keys, read the memory counter." The only care needed is subtracting the empty baseline and loading exactly N distinct keys (an easy thing to get wrong — load them in parallel with overlapping ranges and you'll silently store far fewer).

What it means (and doesn't)

Dragonfly's edge comes from more compact internal data structures. For a 100-byte value, ~46–69 bytes of per-key overhead sits on top of the payload, and Dragonfly carries less of it.

Two honest qualifiers:

The percentage shrinks as values grow. At 100 B, overhead is a big fraction of each key; at 10 KB values it's noise. Memory efficiency matters most for many-small-keys workloads (sessions, counters, feature flags, rate-limit buckets) — exactly where you also have the most keys.
13% is real money at scale but not a headline-grabber. On a 256 GB dataset it's ~33 GB — a meaningful instance-size difference. It won't decide an architecture on its own, but it's a steady, dependable point in Dragonfly's favor that no amount of benchmarking dispute can erode.

Next: Part 6 — operational simplicity, where the cluster's cross-key limitations get quantified — and where Dragonfly's real structural advantage lives. You can also explore every number in this series interactively — filter by workload, cores, and pipelining — in the Benchmark Explorer.

Latency under load: the same story as throughput, from the other side

Sunny Sahijwani — Fri, 11 Sep 2026 09:27:46 +0000

Part 4 of 7 · ← The cluster-saturation problem · Next: Memory efficiency →

Part 4. Throughput (Part 2) tells you how much work gets done; latency tells you how it feels. On this benchmark they turn out to be the same story — and the "realistic cluster" numbers need careful, honest reading.

All numbers below are client-side latency from memtier (never the engine's self-reported info — Dragonfly counts network+queue time there and Redis doesn't, so those aren't comparable). Read-heavy, 100 B, 48 cores.

Without pipelining (depth 1) — concurrency only

series	p50	p99	p99.9
Dragonfly	0.34 ms	0.55 ms	0.71 ms
Redis cluster (realistic)	10.4 ms	19.2 ms	30.1 ms
Valkey cluster (realistic)	10.4 ms	18.5 ms	29.1 ms

With pipelining (depth 16) — throughput regime

series	p50	p99	p99.9
Dragonfly	0.88 ms	2.42 ms	3.33 ms
Redis cluster — fully driven	0.56 ms	1.51 ms	4.64 ms
Valkey cluster — fully driven	0.57 ms	1.32 ms	3.50 ms
Redis cluster — realistic	84 ms	138 ms	151 ms
Valkey cluster — realistic	86 ms	141 ms	158 ms

Reading this honestly

Three things, and the third is the one people will (fairly) push on:

Dragonfly is consistently sub-millisecond — 0.34 ms unpipelined, 0.88 ms under a heavy pipelined load. One endpoint, no client-side routing, predictable tail.
A well-driven cluster has excellent latency too — the fully-driven shards actually beat Dragonfly at the median (0.56 ms), because each shard gets a clean, dedicated, fully-pipelined stream. So the shards themselves are fast. When Redis Cluster is driven right, its latency is great.
The "realistic cluster" latency explodes — 84 ms p50 — and that's a client-side effect, not the shards. This is the same bottleneck from Part 3: a single cluster-mode client can't route to 48 shards fast enough, so requests queue up on the client waiting to be sent. That queuing shows up as latency. It is not the cluster's servers being slow — driven well, the same shards do 0.56 ms.

So I won't claim "Redis Cluster has 84 ms latency" — that would be dishonest. What I will claim, because it's what the data shows: a normal single-process cluster client, under load heavy enough to matter, degrades in both throughput and tail latency at the same time — and you feel it as multi-hundred-millisecond p99s. Fixing it means the client-side engineering from Part 3.

The takeaway

Latency here isn't a separate axis — it's throughput viewed from the other side. Where the client can keep up (Dragonfly always; a cluster only with per-shard routing + enough client capacity), latency is sub-millisecond and tight. Where the client is the bottleneck (a naive cluster client), latency and throughput fail together. Dragonfly's value is that "the client keeps up" is the default, not something you engineer.

Next: Part 5 — memory efficiency, the least-disputable number in the whole series. And you can now explore every chart in this series interactively — filter by workload, cores, and pipelining — in the Benchmark Explorer.

Why a normal client gets 4.6M ops/s out of a Redis cluster that can do 40M

Sunny Sahijwani — Thu, 10 Sep 2026 09:24:42 +0000

Part 3 of 7 · ← Throughput & scaling · Next: Latency under load →

Part 3. This is the post I didn't expect to write. It started as a bug in my benchmark and turned into the most interesting finding of the whole project — about how hard it actually is to use a Redis Cluster's throughput, and why most cluster benchmarks (mine included, at first) quietly under-report it.

In Part 2 I showed two very different numbers for the same 48-shard Redis cluster on the same hardware: 4.6M ops/s with a normal client, 40.6M driven perfectly. This post is how I found that gap, and what it means. It's a debugging story, because that's what it was.

The smell: a 4-shard cluster tied a 48-shard cluster

My first cluster numbers looked wrong. I ran a quick check — does throughput improve as I add shards? — and got this (read-heavy, pipeline 16):

24 shards: 2.65M ops/s
48 shards: 2.66M ops/s

Identical. Doubling the shards did nothing. That's not how a cluster is supposed to behave — 48 single-threaded shards should crush 24. Something was capping throughput before the shards even got busy.

The tell: the shards were idle

So I measured CPU on both boxes during the run. The server, running all 48 shards, was at 779% of 4800% — about 16% busy. The shards were mostly asleep. Meanwhile the client's load-generator threads were pinned at ~100%.

That's the signature of a client-side bottleneck: the cluster had tons of spare capacity, but the client couldn't feed it. And counter-intuitively, adding more client threads made it worse (4.3M → 3.0M) — the classic sign of lock contention inside a single process.

The proof: one shard can do 474K/sec on its own

To find out how much the cluster should be able to do, I measured one standalone Redis shard, pinned to one core, driven directly:

474,000 ops/s at 100% CPU — one core, fully saturated.

So the math on a 48-core box is brutal: 48 × 474K ≈ 22.8M ops/s of raw capacity (and in practice, driven well, each shard did even more — the cluster topped out near 40M). I was extracting ~4.3M. I was using less than a fifth of what the cluster could do, and no amount of tuning the single client fixed it.

The cause: cluster-mode routing, in one process, doesn't pipeline

Here's the mechanism, and it's worth understanding because it affects real applications, not just benchmarks.

A Redis Cluster client has to route every key to the shard that owns its hash slot (slot = CRC16(key) mod 16384). A single-process cluster client (like memtier's --cluster-mode) does this routing on the client side, and two things go wrong under load:

Pipelining fragments. Pipelining is fast because you batch many requests down one connection before waiting for replies. But in a cluster, consecutive random keys go to different shards — so a batch of 16 gets split across 16 connections, one request each. The single most important throughput lever (deep pipelines) collapses to depth ~1.
One process, one routing bottleneck. All that per-key CRC16 + connection-selection happens in one process's threads, which contend. Adding threads adds contention, not throughput.

The result: the client saturates itself doing routing bookkeeping while the shards sit idle. 4.3M, and the cluster barely breaks a sweat.

The fix: one client per shard, pinned by hash-tag

If the problem is "one client can't route to 48 shards efficiently," the fix is to stop routing. I gave each shard its own dedicated memtier process, connected directly to that shard's port (no cluster-mode), using keys with a hash-tag ({tag}:...) chosen so every key hashes to that shard's slots. Now each shard gets a single, dedicated, fully-pipelined stream — exactly like the standalone-shard test that hit 474K.

The result, 48 shards, summed:

39.8M ops/s, server at 91% CPU — near-saturated.

From 4.3M to 39.8M by changing only the client, not the cluster. The cluster was never the bottleneck. The client's ability to route was.

(For the curious: mapping tags to shards is deterministic — I query CLUSTER NODES for each shard's slot range, then pick a hash-tag whose CRC16 mod 16384 lands in it. The tool that does this is in the repo.)

Why this matters beyond benchmarking

This isn't a benchmark artifact — it's a real property of Redis Cluster, and it cuts two ways:

For benchmarks: any Redis Cluster number produced by a single cluster-mode client is probably under-reported — often massively. If you see a cluster benchmark and the shards weren't near 100% CPU, treat the number as a lower bound. (This is exactly why I report two cluster numbers.)

For production — this is the important part: reaching a cluster's throughput ceiling requires client-side routing that actually pipelines per-shard, plus enough client capacity to drive every shard. Good cluster client libraries do route client-side — but:

your client fleet has to be large enough to keep 48 shards busy (in my test, saturating the cluster took a client as powerful as the server), and
pipelining/batching only helps if your keys co-locate per shard — random-key workloads fragment it.

So the cluster's 40M ceiling is real, but it comes with a bill: serious client-side engineering and client hardware. Dragonfly's 15.5M comes with a one-line client and no routing to think about. That's the trade — and now it's not hand-waving, it's a factor of ~9 between "cluster, naively driven" and "cluster, perfectly driven," with the truth for most teams sitting closer to the naive end.

The honest caveat

The "realistic" number (4.6M) reflects one specific normal client (memtier cluster-mode) under a heavy pipelined load. A production app with a good client library and a modest request rate won't hit memtier's exact contention — but it also won't reach the 40M ceiling without real effort. The shape is what's robust: a cluster's usable throughput depends enormously on client-side routing quality and client capacity, in a way a single process like Dragonfly simply sidesteps.

Part 4: latency under load — where this same client-bottleneck effect shows up dramatically in the tail (a naive cluster client sat at p99 ≈ 138ms while Dragonfly held 2.4ms), and how to read that honestly.

Full harness, the per-shard saturation tool, and raw data are public at github.com/sunnysahijwani/dragonfly-redis-valkey-benchmark so you can rerun it. Verified against the DragonflyDB team's benchmarking notes before publishing; the fairness choices are in Part 1.

Dragonfly vs Redis vs Valkey: throughput and scaling on 48 real cores

Sunny Sahijwani — Tue, 08 Sep 2026 07:09:11 +0000

Part 2 of 7 · ← Methodology · Next: The cluster-saturation problem →

Part 2 of the series. Part 1 covered how I kept this fair. This post is the numbers — with the complete setup, every configuration, and every tweak I had to make, so you can reproduce or challenge all of it.

If you only remember one thing: there is no single "winner," and the shape of the answer is more useful than any single number. Same hardware, read-heavy pipelined load, 48 cores:

🐉 Dragonfly, one process: 15.5M ops/s
🔴 Redis Cluster, driven by a normal client: 4.6M ops/s
🔴 Redis Cluster, driven perfectly: 40.6M ops/s

All three are real, measured numbers. The rest of this post explains the setup that produced them and what they mean.

The exact setup (so you can reproduce it)

Hardware (AWS, us-east-1, single Availability Zone, cluster placement group, private network):

Server (engine under test): c7i.metal-24xl — bare metal, Intel Xeon Platinum 8488C (Sapphire Rapids), 48 physical cores / 96 threads, single NUMA node, 192 GB RAM. Bare metal specifically so CPU pinning is real and there's no hypervisor jitter.
Client (load generator): c7i.24xlarge — 96 vCPU, on its own instance so it can never steal the server's CPU. I verified the client was never the bottleneck (more on that below).

Software (pinned by image digest for reproducibility):

Redis 8.2.8, Valkey 8.1.9, Dragonfly v1.40.1, memtier_benchmark 2.5.1.
OS: Amazon Linux 2023, kernel 6.18. Transparent huge pages disabled.

What I measured — three configurations, not two. This is the key methodological choice:

Dragonfly — a single multi-threaded process (--proactor_threads = N).
Redis/Valkey Cluster, "realistic" — an N-shard cluster driven by a normal client (memtier in cluster-mode): what a typical application actually experiences.
Redis/Valkey Cluster, "fully-driven ceiling" — the same cluster, but with one dedicated memtier process per shard, each pinned to its shard via a hash-tag, so every shard is saturated: the cluster's raw hardware capacity if you route perfectly and throw unlimited client resources at it.

Why single-DF vs cluster (and not vs single Redis)? Because Redis executes commands on one thread. To use all 48 cores you must shard it into a cluster — so a single Dragonfly process (uses the whole box) vs an N-shard Redis cluster (uses the whole box) is the apples-to-apples comparison. Single-node Redis appears only as a labelled baseline.

Engine configuration (identical treatment, parity made explicit):

Persistence off (save "", appendonly no), maxmemory well above the dataset, noeviction — set explicitly on all three (Dragonfly's --cache_mode=false --snapshot_cron='', verified from its docs, matches Redis noeviction + persistence-off).
memlock unbounded on all engines (not just Dragonfly).
Cluster = one shard per physical core (I verified with a sweep that more shards didn't help — see Part 3).

Workload (memtier, client-side latency — never the engine's self-reported info):

GET/SET ratios 10:1 (read-heavy) and 1:1 (mixed); value sizes 100 B and 1 KB; pipeline depth 1 and 16.
1M-key keyspace, pre-populated so every read hits real data (I checked — hit rate was 1.0 on every run; an un-populated benchmark measures the cheap "key not found" path).
2 repetitions per cell, median reported.

The tweaks I had to make (and why they matter)

Being honest about these is the whole point — each one changes the numbers, and skipping any of them would have produced a misleading result:

Dragonfly needs io_uring — and Docker blocks it by default. On a fresh AL2023 box, Dragonfly silently fell back to epoll (its slower path) because Docker's default seccomp profile blocks the io_uring syscalls. Running Dragonfly on epoll would have unfairly handicapped it. Fix: --security-opt seccomp=unconfined so it uses io_uring — its native I/O. Redis/Valkey use epoll natively, so each engine runs on its own best path.
Dragonfly needs maxmemory ≥ ~256 MB × threads (12 GB at 48 threads). I gave it 32 GB.
The client has to be big. My first cluster runs were quietly limited by too few client threads. It took 48 client threads to saturate the server — and I confirmed at peak load the server sat at ~100% CPU while the client had ~78% headroom. If the client is the bottleneck, every engine flatlines at the client's limit and the benchmark is worthless.
Driving a cluster to its real throughput is genuinely hard — hard enough that it's its own post. It's why there are two cluster numbers, not one.

Scaling: throughput vs cores (read-heavy, 100 B, pipeline 16)

This is the chart that tells the story. Throughput in millions of ops/sec, as the server's core count grows 4 → 48:

cores	Dragonfly	Redis realistic	Redis ceiling	Valkey realistic	Valkey ceiling
4	2.0	3.2	5.2	3.1	5.0
8	3.7	5.0	9.2	4.9	8.8
16	6.5	5.0	15.8	4.9	15.2
24	9.0	4.8	22.5	4.8	21.7
48	15.5	4.6	40.6	4.5	40.2

Three completely different shapes:

Dragonfly scales smoothly, 2M → 15.5M. One process, one connection endpoint, a dumb client — and it just keeps climbing with cores.
The realistic cluster plateaus at ~5M around 8 shards and then goes flat — even slightly down. Adding shards past 8 doesn't help a normal client at all, because the client spends more and more effort routing keys across more and more shards. This surprised me, and it's the single most important practical finding: throwing more shards at a normal cluster client does not buy you throughput.
The ceiling scales hard, 5M → 40.6M — because the underlying hardware (48 single-threaded shards, each doing ~850K ops/s) genuinely can do that much. You just have to route perfectly to reach it.

Dragonfly overtakes the realistic cluster at ~16 cores and finishes 3.4× ahead at 48 (15.5M vs 4.6M). It reaches 38% of the raw ceiling — with a one-line client. Redis/Valkey are near-identical throughout (Valkey is the Redis fork; no surprise).

What each number is for

If you deploy a cluster and use a normal client (the overwhelmingly common case): you get ~4.6M, and Dragonfly gives you 3.4× that for a fraction of the operational effort.
If you can invest in flawless client-side routing and a client as powerful as your server: the cluster's ceiling (40.6M) beats Dragonfly (15.5M) by 2.6×. That's real — but it's a lot of "if."
Dragonfly's pitch, quantified: most of the cluster's throughput, for almost none of the cluster's operational cost.

Two honest wrinkles

Big values are network-bound. At 1 KB values (read-heavy, pipeline 16, 48 cores), everything compresses: Dragonfly 4.8M, realistic cluster 3.7M, ceiling 7.7M. Once each op moves ~1 KB, you're bandwidth-limited, not engine-limited, and the gaps shrink. Pick the value size that matches your workload.

Without pipelining, nobody is fast (it's a round-trip-bound world): read-heavy, pipeline 1, 48 cores — Dragonfly 2.8M, realistic cluster 1.4M. Dragonfly still leads, but this is the regime where your network RTT dominates, not the engine.

Part 3 is the one I find most interesting: why a normal client only gets 4.6M out of a cluster that can do 40M — and what that says about benchmarking (and operating) Redis Cluster at scale. Then latency, memory, and the operational-simplicity tax.

Everything here — scripts, pinned versions, raw runs.csv, the analysis — is public at github.com/sunnysahijwani/dragonfly-redis-valkey-benchmark so you can rerun it. Verified against the DragonflyDB team's benchmarking notes before publishing; the fairness choices (and the bias I caught in my own setup) are in Part 1.

I benchmarked Dragonfly vs Redis vs Valkey. First, let me show you how I kept it honest.

Sunny Sahijwani — Mon, 07 Sep 2026 10:22:27 +0000

Part 1 of 7 · Series index · Next: Throughput & scaling →

Part 1 of a series. This post has no throughput charts — on purpose. Before I show you a single number, I want to show you the traps that make most in-memory benchmarks lie, and exactly how I disarmed each one. If the method isn't fair, the numbers aren't worth reading.

The uncomfortable truth about database benchmarks

Almost every "X is 25× faster than Y" benchmark you've seen is rigged — usually not maliciously, just carelessly. The author picks a setup that happens to flatter one engine, runs it once, and publishes the number. The most common way it goes wrong is subtle: the benchmark measures the client, or the virtual machine, or a cache-miss path — anything except the database it claims to measure.

So when the DragonflyDB team reached out with notes on how to benchmark Dragonfly fairly, I took it as a challenge to do this properly — and to publish my methodology before my results, so you can attack the method first.

Here's the question I'm actually answering:

On one server, using all its CPU cores, how much load can each engine sustain — and what does each one cost you in operational complexity to get there?

That "one server, all cores" framing matters, and it's where the first trap hides.

Trap 1: "single process vs single process" is not the fair fight

Redis executes commands on one thread. Since Redis 6 it can use extra threads for network I/O, but the actual data work — the part that matters — still runs on a single core. Valkey is the same shape. Dragonfly, by contrast, is multi-threaded by design: one process that uses every core you give it.

So if I put one Dragonfly process (48 cores) next to one Redis process (1 core of real work) and shout "Dragonfly wins!", I've told you nothing except that 48 > 1. That's the rigged benchmark I refuse to publish.

To use all the cores of one box, Redis has to be sharded into a cluster — many redis-server processes on the same machine, each owning a slice of the keyspace. So the fair fight is:

one Dragonfly process (uses the whole box), versus
a Redis/Valkey cluster of N shards (also uses the whole box).

Same machine. Same cores. Same goal: saturate the node. That's apples to apples. Single-process Redis stays in my tests only as a labelled baseline, never as the comparison.

Trap 2: how many shards? (the small version of the big trap)

Once you agree the fair peer is a Redis cluster, a new question appears: how many shards? Too few and Redis can't use the cores; too many and they thrash. Rather than guess, I swept shard counts — and one shard per physical core turned out to be about right on this hardware.

That was the easy version. The nasty one was realising I couldn't even drive the cluster hard enough to measure it. To read any database's true speed, you have to push enough load that the database is the bottleneck — not your test tool. But a cluster is many independent shards, and to see its real ceiling you have to keep every shard busy at once. A normal load tool routes every request from a single process, and that routing work pins the tool's own CPU long before the shards are busy — so my first cluster runs measured my load generator, not the cluster, with the shards sitting ~16% idle. That's the trap that nearly wrecked the whole benchmark, and it gets its own post.

Trap 3: the client was the real bottleneck

This is the big one, and it's why so many benchmarks are worthless.

A benchmark has two machines doing work: the database (server) and the load generator (client). Throughput is capped by whichever runs out of CPU first. If the client maxes out before the server does, then every engine flatlines at the client's ceiling — and they all look identical, even if one is twice as fast. You've benchmarked your load generator.

The fix: make the client more powerful than the server, put it on a separate machine, and then prove it wasn't the limit. My harness ramps the load up step by step and records both server and client CPU. At the throughput plateau I check who's saturated:

server maxed, client has headroom → server-bound → the number is real.
client maxed, server has headroom → client-bound → throw it out, get a bigger client.

If I can't show you which side was the ceiling, I won't show you the number.

And here's where it got genuinely surprising. Even with a big, separate client, a single cluster-mode client couldn't saturate a 48-shard cluster — the shards sat ~16% busy while the client thrashed on routing. I was about to report ~4.6M ops/s as "the cluster's throughput" when the same cluster, driven correctly (one dedicated client per shard), does ~40M. Reporting either number alone is a lie: 4.6M sandbags Redis; 40M pretends everyone routes perfectly with unlimited client hardware.

So I report the cluster two ways — what a normal client actually gets, and the fully-driven ceiling — and let you see the gap. That gap turned out to be the most interesting finding in the whole study, and it gets its own post.

Trap 4: I was benchmarking cache misses

When I first ran it, ~72% of my reads were misses — I was reading random keys from a database that was mostly empty, so I was measuring the "key not found" path, which is cheaper and meaningless. Fixed by pre-loading the full keyspace before every read-heavy run. Now every run reports its hit rate, and I only trust runs where reads actually hit real data.

Keeping the engines truly identical

Small asymmetries add up, so every engine gets the exact same treatment: persistence off, identical memory limit, no eviction, same value sizes, same request mix, same pipeline depths. Where one engine needed a special flag, I applied the equivalent to all three rather than to one. And I made each engine's "no persistence, no eviction" settings explicit — verified from the docs, not assumed from defaults. Every knob a run used is recorded in the results row, so any number is fully reproducible.

A concrete example of that care, because it changed the numbers: on a fresh cloud box, Docker's default security profile silently blocked Dragonfly's io_uring and dropped it to a slower I/O path — which would have quietly handicapped Dragonfly. I gave it back its native io_uring (Redis and Valkey use their native epoll), so each engine runs on its own best path rather than one being crippled by an environment quirk. That's the difference between a fair test and an accidental hit piece.

The honesty guard I'll hold all series long

It would be easy — and wrong — to claim "Dragonfly has no sharding limitations." It does. Dragonfly Cluster, once you scale it across machines, uses the same 16,384-hash-slot model as Redis and hits the same limits. Dragonfly's real advantage is narrower and more honest:

To make Redis use your whole server you must cluster it, and clustering costs you cross-key freedom. Dragonfly gives you the cores without that cost — so you postpone clustering until you truly outgrow one big machine.

Not "never." Later. That's the claim, and I'll keep it precise even when a punchier overstatement would get more clicks.

What one laptop can and can't tell you

I built and validated the whole harness on a laptop — but I won't publish speed numbers from it, and you should distrust anyone who does. Under a virtual machine, CPU pinning isn't real, cores aren't uniform, and the hypervisor injects timing noise. My own ramp test proved it: at the throughput plateau, neither the server nor the client was CPU-saturated — the ceiling was the virtualization layer itself.

So the split is:

Hardware-independent results (how the engines behave — cross-slot rules, memory-per-key) I can and will show from anywhere.
Performance results (throughput, latency, scaling) come only from bare metal: an AWS c7i.metal-24xl server (48 physical Sapphire Rapids cores, no hypervisor), a separate over-provisioned c7i.24xlarge client, same availability zone and placement group — real cores, real pinning, a network I control. That's the setup the next posts run on.

What's coming

Throughput per node — the fair fight, across read/write mixes and pipeline depths.
Core scaling — what happens from 4 to 48 cores.
Latency under load — the tail (p99, p99.9), not just averages.
Memory efficiency — bytes per key.
Operational simplicity — cross-slot, hash tags, Lua and transactions: the real cost of a cluster.
When to use which — a decision guide, because (spoiler) there is no universal winner.

The full harness — scripts, pinned versions, raw results — is public at github.com/sunnysahijwani/dragonfly-redis-valkey-benchmark, so you can rerun everything and check my work. That's the whole point.

Next: the throughput numbers, on real hardware, with the receipts.