Dragonfly Is Not Redis: An Open Letter to the Community

On May 30, 2022, the Dragonfly project launched on GitHub, aiming to disrupt the landscape of in-memory data stores and build a better technology than the one that dominated the open-source market at the time—Redis OSS.

Just 30 days after our launch, Redis responded with a blog post titled “13 Years Later - Does Redis Need a New Architecture?” authored by their technical leadership. They dismissed Dragonfly and declared that their technology is great and does not necessitate any updates to the underlying architecture. We never responded or engaged with the post, as we believe it asks the wrong question. The proper question isn’t what does Redis need—it’s what does the software engineering community need.

We believe that engineers need data infrastructure that is easier to scale within modern cloud environments, much less expensive, and able to deliver the performance that modern users expect. This is what motivates us to build Dragonfly and what drives our users to adopt Dragonfly.

What does Redis believe?

Redis’s Legal Response

Ironically, nearly three years later, it was Redis’s legal team—not its engineers—who answered that question. Last week, they sent us a letter accusing Dragonfly of misleading users into thinking Dragonfly is Redis and threatening legal action.

First off, as clearly as possible, I want to state one thing: Dragonfly is not Redis. And perhaps now is the right moment to respond directly to the original blog post. Let’s address the technical and business realities directly with a simple comparison between Redis Cloud and Dragonfly Cloud.

On Redis Cloud, launching a 100GB data store capable of handling 1 million RPS in the Google Cloud us-central1 region costs $5,956/month. On Dragonfly Cloud, launching a Dragonfly Swarm data store with the same capacity and enhanced compute tier in the same region costs just $1,300/month.

And here’s the kicker—the Dragonfly Swarm data store can reach 6.5 million RPS^[1]. That’s 6.5x higher throughput for 4.5x less cost—or, put another way, 30x greater value per dollar.

Redis’s lawyers claim that Dragonfly misuses the Redis trademark to present itself as Redis. Nothing could be further from the truth. With a product that delivers far more value for much less money, Dragonfly adoption is growing at an exponential rate, precisely because Dragonfly is not Redis.

Unfortunately, Redis Inc. has a history of threatening project maintainers with legal action. See, for example, below, where the author of RedisDesktopManager explained that they had to rename their open-source project after being threatened by Redis (they ultimately succumbed, moved the project to the Redis org, and became a Redis employee). More recently, in a discussion from just a few months ago, a maintainer was given two choices: either move their project under Redis governance or rename it.

It’s sad to see the Redis project, which once stood for innovation and free thinking, degraded to be He-Who-Must-Not-Be-Named.

I believe the open-source community thrives on innovation and competition. I wish Redis all the best and encourage them to focus more on improving their technology and less on pursuing legal action against projects that mention the “Redis” name on their websites.

I would like to thank the Dragonfly community for using the project, for filing issues, and for fixing bugs. We can assure you that Dragonfly remains committed to building the best possible in-memory data store for tomorrow’s engineering challenges.

In the attached picture, I am tricking Harry Potter fans into buying Dragonfly Cloud by representing Dragonfly Cloud as a Harry Potter character.

• [1]: The Dragonfly Swarm data store (100GB, enhanced compute tier) was tested with the following command:

$> memtier_benchmark -t 16 --ratio 0:1 -d 32 --distinct-client-seed -c 10 --pipeline 10 --cluster-mode