RESP is a great protocol - allowing us to support multiple products with no custom code

I've seen multiple - "Redis bad" articles and videos. I believe the internet is filled with more than enough content on that subject. This one is more of an appreciation for the underlying technology, rathar than the company's decisions and results.

First - a bit of a back story

The most common question people have is what is supported and what not. It makes sense considering how many Redis forks and similar products have come up over the years. Our focus always have been Valkey - supporting new features and commands it introduces, contributing to their repositories or the community as a whole. Redis is also supported, minus the newer and more interesting commands that Valkey has introduced since the split a little over two years ago. A month or two ago we had a client interested in migrating from KeyDB to Valkey. Turned out that with the exception of a few minor issues around the INFO command, KeyDB worked out of the box as well. Yesterday I had some free time on my hands and decided to test everything we've built on a Dragonfly instance. Everything worked out of the box.

Then I ran redis-benchmark against it, mostly out of curiousity, but alsso to see generated data and then use that for testing our migrations to and from Valkey.

While the benchmark was running I was going trough the dashboard tab by tab. Slowlog filling up with the SET and GET spam from the benchmark, clients view showing all 31 connections, ops/sec somewhere above 26k. Memory analytics, keyspace, latency, config - didn't find a single broken tab. Maybe the graphs were a bit jumpier than what I am used to seeing from a Valkey instance, but that could easily be the benchmark itself, I haven't investigated it further.

The migration I mentioned earlier worked as well. Around 1 600 keys went from a Valkey instance into the Dragonfly one, no errors, no special handling. And migrating is the most delicate operation we do - you read every single key out of one engine and write it into a completely different one. I honestly expected at least some drama there. There was none.

The important part - we have no Dragonfly code. None - no adapters, no extra checks and balances, no workaround. And until yesterday I don't think anyone from the team has ever even started a Dragonfly container.

Which is the main topic. A monitor built for Valkey works on a database written from scratch in C++ by people that have no relation to Redis or Valkey whatsoever. Why?

Second - the licensing drama, shortly

You probably know this part already so I will go fast trough it.

March 2024 - Redis drops BSD in favor of SSPL/RSAL dual license. According to Redis - cloud providers were selling managed Redis without contributing much back and this was supposed to stop them. According to the cloud providers that had full time contributors working on Redis this wasn't the case. Everyone has their own thoughts and understanding of what happened and who they support. However, within few weeks the Linux Foundation forked 7.2.4 into Valkey, with the support of AWS, Google, Oracle and many others, as well as a big part of the community. Redis brought AGPL back last year in atempt to be recognised once again as an OSS but the damage was already done.

KeyDB is older than the whole drama - Snap took it over back when forking Redis was about experiments, not politics. Their main goal was around multithreading, but it is no longer officially supported.

Dragonfly is not a fork at all, new engine, C++, they only kept the wire compatibility so that existing clients and tools keep working to ease people trying it out and switching. Also, Dragonfly is BSL licensed, so the landscape of licenses is all over the place.

Different companies, different licenses, different history, different approaches, different C-suite and board members. Still, all of these databases (and many other) answer to the same protocol.

And the list doesn't stop with these four. Microsoft has Garnet - another from-scratch engine, C# this time, released in 2024, speaks RESP. Apache has Kvrocks, which keeps the data on disk with RocksDB underneath, same protocol. There is Redict, one more fork born from the 2024 drama, LGPL this time. Upstash sells a serverless service that answers to the same bytes. Go further back and you will find Pika from Qihoo 360 and Tendis from Tencent, both disk-backed, both RESP. The pattern repeats every time - if you are building a key-value store, you implement RESP first, because every language already has a client for it and every existing tool, ours included, works with you from day one.

Third - the credit

The protocol is called RESP, REdis Serialization Protocol. "Redis got the protocol right" is a sentence I have heard many times and probably said myself, but it puts the credit in the wrong place. Redis as a company didn't design RESP. Salvatore Sanfilippo (antirez) did, back in 2009-2010, when the whole project was more or less him and a mailing list, way before Redis was comerssialised heavily. The protocol settled somewhere between versions 1.2 and 2.0 and after that nobody touched it for almost a decade. The one real revision, RESP3, came in 2018. His design again. He left the project in 2020 (and came back not so long ago, but that is a whole other story).

Now connect this with the list of databases from the previous section. Garnet is Microsoft. Dragonfly is a VC funded startup. Kvrocks is Apache. None of them asked anybody for permission - they took a spec one person wrote fifteen years ago, implemented it, and recieved the entire ecosystem of clients and tools for free. You can put a new license on code. On two pages that thousands of people have already read and implemented - good luck.

The protocol

If you never saw it raw:

$ nc localhost 6379
PING
+PONG
INFO server
$3540
# Server
redis_version:7.4.0
...

Yes, netcat is a valid Redis client. There are far better options of course, but the point stands - not many databases will let you talk to them by hand like this. The whole type system fits in five prefixes:

+  simple string
-  error
:  integer
$  string, with its length in front
*  array

A command is an array of strings. A reply is one of the above. There are a few more details (inline commands, the RESP3 additions), but if you understood the code block, you understood the protocol. The spec really is a couple of pages.

Which, if you ask me, is the whole explanation why everybody implemented it. Nobody has the appetite to reimplement some 300 page protocol with schema compilers and multi-step handshakes - that work gets done once, by the vendor, and never again. Reimplementing RESP is a weekend. So people did it, over and over, and today client libraries in every language work against a dozen engines that share nothing between each other except these five prefixes. From our side - one RESP client, four supported databases. Every difference we actually deal with sits above the protocol, in what INFO returns and which admin commands exist. The bytes on the wire have not surprised us once.

About RESP3, since I mentioned it a few times already. It brought real types - maps, sets, doubles, booleans - so clients can stop guessing what a flat array is supposed to mean. It also brought push messages, meaning the server may speak first. That is the mechanism behind client side caching in Redis 6 and newer, the server pokes you when a key you cached locally gets changed by someone else. And the whole migration path is one HELLO 3 command. Server too old? Fine, you are talking RESP2, nothing broke. The only revision in fifteen years, and you have to explicitly ask for it to even notice it exists.

Debugging deserves a mention too. With RESP, tcpdump output is readable, you scroll trough the conversation like a chat log. Anyone who has reconstructed a session from hex dumps of some binary protocol knows how much that is worth.

The same trick, elsewhere

Not a RESP-only phenomenon, to be fair. CockroachDB and YugabyteDB speak the Postgres wire protocol without carrying any Postgres code in them, and because of that every Postgres driver ever written works with them out of the box. Vitess and TiDB did the same with the MySQL protocol. Apparently a good wire protocol, given enough time, outgrows its creator. RESP is simply the sharpest example I know of, since it also managed to outlive the license of the codebase it was created for.

Try it yourself

A couple of minutes and docker is all you need:

docker network create demo
docker run -d --network demo --name dragonfly --ulimit memlock=-1 -p 6390:6379 docker.dragonflydb.io/dragonflydb/dragonfly
docker run -d --network demo -p 3009:3001 -e DB_HOST=dragonfly -e DB_PORT=6379 betterdb/monitor:latest

Then open localhost:3009 - a Dragonfly instance, inside a dashboard built for Valkey. Run redis-benchmark -p 6390 -c 30 -n 1000000 if you want the graphs to move. This is honestly the entire setup behind this article.

Summary

I promised in the beginning that this won't be one more licensing rant, so let me close it accordingly. Companies rebrand, change owners, change licenses, sometimes change them back. A good protocol just sits there. RESP sat trough a fork, trough a couple of from-scratch rewrites, trough its own company switching licenses twice. The fact that our monitor picked up Dragonfly with literally zero preparation is a straight consequence of choices one person made a decade and a half ago.

So - thank you, antirez. The data structures get all the fame, but the boring two page protocol might end up being the most durable thing you made.

As usual, this is my reading of the events and I am open for discussion. And if you run some RESP speaking database that I didn't mention here - point the monitor at it and tell me what breaks. My expectations after yesterday - nothing will :)