Redis, Valkey, Dragonfly, and Tellstone: One Thread vs. Many, Explained Simply

Four projects now answer to a "GET key" command the same way. Underneath, they store data in RAM using different engines, different licenses, and — in one case — a codebase that's only a few months old. Here's what actually separates them.

What "In-Memory" Really Means, and Why It All Starts With One Thread

Think of your computer's hard drive like a filing cabinet in the basement — reliable, but you have to walk down there every time you need a document. RAM is the desk in front of you. Whatever's on the desk, you can grab instantly. An in-memory database like Redis keeps its entire dataset on that desk instead of in the basement, which is why a lookup takes microseconds instead of milliseconds.

Redis was created by Salvatore Sanfilippo in 2009, and its defining decision was to process commands on a single thread. That sounds like a limitation, but it's closer to a shortcut: a single thread can't have two commands stepping on each other, so there's no need for locks, no risk of one operation corrupting another mid-write, and no surprise slowdowns from threads fighting over the same memory. Since Redis 6.0, it has been able to spread the network reading and writing across multiple I/O threads, but the actual command execution — the part that touches your data — still runs one operation at a time on the main thread. This is the same lesson covered in how Discord's gateway keeps millions of sockets alive on a small number of processes: you don't need a thread per connection to handle huge concurrency, you need an efficient way to multiplex many sockets onto few threads.

That single-threaded core is the baseline every other project in this piece either keeps, forks, or rejects.

March 2024: The License Change That Split Redis Into Two Projects

For fifteen years, Redis shipped under the permissive BSD-3-Clause license — free to use, modify, and resell with almost no restrictions. That ended on March 20, 2024, when Redis Ltd. announced Redis 7.4 and later would ship under a dual source-available license: SSPLv1 and RSALv2, neither of which the Open Source Initiative recognizes as open source. In practice, that meant any company reselling Redis as a managed service — think AWS, Google Cloud, Azure — now needed a commercial agreement with Redis Ltd. just to keep offering it.

The reaction was immediate. The Linux Foundation announced it would form Valkey, an open-source alternative built on the last BSD-licensed release, backed by contributors regrouping in response to the license change. The fork began with a dedicated group of contributors from AWS, Ericsson, Oracle, and Google, and it grew fast — within about a year the project counted nearly 50 contributing companies and a GitHub repository with tens of thousands of stars. Valkey maintainer Kyle Davis summarized where things stand now: "From this point forward, Redis and Valkey are two different pieces of software."

The two haven't stood still since. Valkey is governed by the Linux Foundation's neutral Technical Steering Committee rather than a single company, and its more recent releases have added their own independent features — multi-database support in cluster mode and official modules for JSON, Bloom filters, and vector search among them. Redis, meanwhile, kept building on its own roadmap and, with Redis 8.0 in May 2025, added AGPLv3 as a third licensing option — a genuinely open-source license, though one with a network-copyleft clause that can obligate SaaS providers exposing Redis to end users to open-source their own application code.

Dragonfly's Bet: One Process, Every Core, No Locks

Dragonfly took a different path entirely — it isn't a Redis fork at all. It was built from scratch with a multi-threaded architecture that splits the keyspace into independent shards, each owned by a dedicated thread pinned to its own CPU core, with no shared memory between shards and therefore no mutex locks or lock contention. Where Redis's command execution is deliberately single-threaded to avoid coordination overhead, Dragonfly is deliberately multi-threaded and avoids the usual cost of that (lock contention) by giving each thread its own private slice of data instead of sharing one big structure everyone has to take turns touching.

That architecture also changes how backups work. Redis's BGSAVE forks the entire process to take a consistent snapshot, which can spike memory usage as copy-on-write pages accumulate during the save. Dragonfly avoids the fork entirely — each shard serializes its own data independently during a snapshot, so memory stays flat instead of spiking. This is the same class of tradeoff explored in the tradeoffs of writing this kind of infrastructure in a memory-unsafe systems language: both Redis and Dragonfly are written in C/C++ for raw speed, and both projects have to hand-manage the exact kind of memory safety that a garbage-collected or borrow-checked language would otherwise guarantee for free.

On that same instance class, Dragonfly's own benchmark reported a 25x increase in throughput compared to a single Redis process, crossing 3.8 million operations per second — which is where the roughly 150,000 ops/sec baseline above comes from, arithmetically, since 3.8M divided by 25 lands there. It's worth repeating: this is one vendor's benchmark, on hardware and a workload shape that vendor chose. Redis Ltd. counters with its own numbers for Redis 8, and reports latency reductions between 5.4% and 87.4% across 90 commands from SIMD instructions and low-level code tuning — a different kind of improvement (faster per-core execution) rather than more cores doing the work. Dragonfly ships under BSL 1.1, a source-available license that's free for self-hosting but, like Redis's SSPL/RSALv2, restricts competing managed-service offerings.

Tellstone: A Very Young Experiment in How Far Go Can Go

Tellstone is the odd one out here, and the honest framing matters. It's a cloud-native in-memory key-value store written entirely in Go, speaking both a custom binary protocol and a Redis-compatible RESP2 protocol over a sharded, low-contention storage engine. Architecturally it resembles Dragonfly's philosophy in miniature: every shard runs its own goroutine with an independent lock-free map, keyed by FNV-1a hashing, so there's no cross-shard coordination and scaling adds roughly linearly with cores.

But scope matters as much as architecture. As of its current phase, Tellstone supports only GET, SET, DEL, and PING — a fraction of the hundreds of commands Redis, Valkey, and Dragonfly each support. Clustering and replication are listed as a future phase, not yet built. It began, by its own author's account, as a personal test of the language rather than a production pitch: a project built to see whether a zero-allocation Go engine could compete with C-based stores, benchmarked by its own creator against Redis and Valkey on a single personal system. In that self-run test, Tellstone reached roughly 2.4 million operations per second against roughly 2.0 million for Redis and Valkey — a real result, but one measured by the project's own author, on their own machine, not a neutral lab.

Picking One: Cost, Compatibility, and Where Each One Breaks

None of these four is objectively "the best" — they solve different problems, and the honest answer depends on what you're building.

Migrating an existing Redis deployment away from licensing risk. Valkey is the lowest-friction choice. It's a binary-compatible fork of Redis 7.2.4, meaning existing RDB files, client libraries, and the redis-cli-equivalent tooling work against it with minimal changes. It's also the option every major cloud provider (AWS ElastiCache, Google Cloud Memorystore) has already committed engineering resources to supporting, which matters for long-term maintenance.

Squeezing maximum throughput out of one large machine. Dragonfly's thread-per-core design is built for exactly this — vertically scaling a single instance to use every core, instead of running a Redis Cluster spread across many small nodes. The tradeoff is licensing (BSL 1.1, not fully open source) and a command-compatibility gap: Dragonfly supports roughly 240 Redis commands, but modules like Redis Search, Redis JSON, and some Lua scripting edge cases aren't fully covered, so compatibility should be checked command-by-command before migrating.

Staying on the vendor's own roadmap, with native JSON, vector search, and AI-adjacent features baked in. Redis 8.x is where that investment is happening natively, at the cost of the tri-license structure and the network-copyleft implications of AGPLv3 for SaaS providers.

Experimenting, learning, or contributing to something young. Tellstone is not a production replacement for any of the above today — it supports four commands and has no clustering yet. Where it's genuinely interesting is as a case study in Go's viability for latency-sensitive systems code, and as an open (Apache-2.0) project a contributor could actually help shape early.

If you want to see the differences yourself rather than take any vendor's word for it, all three mature engines run happily side by side in Docker:

services:
  redis:
    image: redis:8
    ports: ["6379:6379"]
  valkey:
    image: valkey/valkey:8
    ports: ["6380:6379"]
  dragonfly:
    image: docker.dragonflydb.io/dragonflydb/dragonfly
    ports: ["6381:6379"]

Tellstone doesn't yet publish an official container image, given its Phase 1 status — building it from its GitHub source is currently the way to try it.

The license fight decided who governs the software. The architecture decides how it performs. Which one belongs in your stack depends on which of those two questions actually keeps you up at night.