TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Redis vs. KeyDB vs. Dragonfly vs. Skytable

130 pointsby johnwoodsalmost 3 years ago
It seems that several projects claim that they have built the &quot;world&#x27;s fastest key&#x2F;value store&quot; or sometimes the phrase used is even more outrageous. The following projects are in question:<p>- Redis: <a href="https:&#x2F;&#x2F;github.com&#x2F;redis&#x2F;redis" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;redis&#x2F;redis</a><p>- KeyDB: <a href="https:&#x2F;&#x2F;github.com&#x2F;snapchat&#x2F;keydb" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;snapchat&#x2F;keydb</a><p>- Dragonfly: <a href="https:&#x2F;&#x2F;github.com&#x2F;dragonflydb&#x2F;dragonfly" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dragonflydb&#x2F;dragonfly</a><p>- Skytable: <a href="https:&#x2F;&#x2F;github.com&#x2F;skytable&#x2F;skytable" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;skytable&#x2F;skytable</a><p>And, these are my benchmark results (30 threads, 1 client per thread with GET&#x2F;SET. See below for setup):<p>1. Redis: 112,100 &#x2F; 99,892<p>2. KeyDB: 288,931 &#x2F; 282,997<p>3. Dragonfly: 408,322 &#x2F; 392,446<p>4. Skytable: 619,992 &#x2F; 676,091<p># Notes<p>1. Redis: I&#x27;ll start with Redis which I&#x27;d like to call the &quot;original&quot; key&#x2F;value store (after memcached) because it is the oldest and most widely used of all. Being a long-time follower of Redis, I do know it&#x27;s single-threaded (and uses io-threads since 6.0) and hence it achieves lesser throughput than the other stores listed above which are multi-threaded, at least to some extent. The best parts about Redis: it&#x27;s the most feature complete of all the systems here, and is the oldest. (not saying old necessarily means better).<p>2. KeyDB: The second is KeyDB. IIRC, I saw it in a blog post which said that it is a &quot;multithreaded fork of Redis that is 5X faster&quot;[1]. I really liked the idea because I was previously running several instances of Redis on the same node and proxying them like a &quot;single-node cluster.&quot; Why? To increase CPU utilization. A single KeyDB instance could replace the unwanted proxying funkiness, so I ditched Redis for KeyDB. Has been a fine experience so far, except for some occasional crashes.<p>3. Dragonfly: Just found it on HN and seems to be relatively new. Dragonfly claims that it is 25X faster (that I couldn&#x27;t reproduce) than Redis[2] and has the slogan &quot;Probably, the fastest in-memory store in the universe!&quot;. Doesn&#x27;t support all the Redis commands yet, but I find it interesting mainly because of performance. Also, it&#x27;s good to know why it is faster because it clearly outlines the underlying architecture[2]. The other three stores don&#x27;t say much about it. Will be following the project.<p>4. Skytable: Found it while looking for projects written in Rust. Claims to be &quot;insanely fast.&quot; Skytable&#x27;s &quot;experimental benchmarks&quot; claim that it is something around 10X faster than Redis and some 2X-3X faster than KeyDB[3]. I hadn&#x27;t heard of Skytable and it doesn&#x27;t seem to be as widely used (unless I&#x27;m missing something?). I find it interesting because of the planned features[4] and performance. Only Skytable natively runs on Windows out of the four. Will be following the project.<p>5. My thoughts: Redis needs no introduction and is arguably super stable for use on production systems (using widely in our systems). KeyDB seems to be &quot;stable enough&quot; and it seems to be good for prod since Snapchat uses it already[5] (and so do we!). I found no Dragonfly v&#x2F;s Skytable benchmarks. The best part about Redis, KeyDB and Skytable is that they don&#x27;t make any &quot;crazy assumptions&quot; about the system they run on. What do I mean?<p>Dragonfly expects you to have the latest hardware[6] and the latest kernel[7] on all your servers. I find this outrageous because not all servers run 5.10 and a majority of them are still using long-running branches on 4.x. Also, I don&#x27;t expect them to have the latest processors, either. I&#x27;d argue if the other three stores started assuming the latest features, they&#x27;d be far faster than what they are today. Finally, both Dragonfly and Skytable are still early in their development so it may not be fair to compare their features against Redis and KeyDB who have been around for far longer. Also, all projects other than Skytable have companies behind them (unless I&#x27;m missing something).<p>Edit #1: I have run the benchmarks myself for each store. In the benchmark with Redis, KeyDB and Skytable (redis-benchmark, memtier and sky-bench): Redis and KeyDB benchmarks seem to be very consistent, Skytable is a little inconsistent at times. However, in the benchmark with Redis, KeyDB and Dragonfly (with memtier), I was NOT able to reproduce the 25X speed that Dragonfly claims. I ran all tests on two m5.4xlarge servers (one with the k&#x2F;v store and one with the benchmark tool).<p>Edit #2: Added benchmark results<p>What are your thoughts? Have you tried benchmarking any of them locally or in the cloud?<p>References:<p>[1]: <a href="https:&#x2F;&#x2F;docs.keydb.dev&#x2F;blog&#x2F;2019&#x2F;10&#x2F;07&#x2F;blog-post" rel="nofollow">https:&#x2F;&#x2F;docs.keydb.dev&#x2F;blog&#x2F;2019&#x2F;10&#x2F;07&#x2F;blog-post</a><p>[2]: <a href="https:&#x2F;&#x2F;github.com&#x2F;dragonflydb&#x2F;dragonfly" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dragonflydb&#x2F;dragonfly</a><p>[3]: <a href="https:&#x2F;&#x2F;github.com&#x2F;ohsayan&#x2F;sky-benches" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ohsayan&#x2F;sky-benches</a><p>[4]: <a href="https:&#x2F;&#x2F;github.com&#x2F;skytable&#x2F;skytable&#x2F;issues&#x2F;203" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;skytable&#x2F;skytable&#x2F;issues&#x2F;203</a><p>[5]: <a href="https:&#x2F;&#x2F;docs.keydb.dev&#x2F;news&#x2F;2022&#x2F;05&#x2F;12&#x2F;keydb-joins-snap" rel="nofollow">https:&#x2F;&#x2F;docs.keydb.dev&#x2F;news&#x2F;2022&#x2F;05&#x2F;12&#x2F;keydb-joins-snap</a><p>[6]: <a href="https:&#x2F;&#x2F;github.com&#x2F;dragonflydb&#x2F;dragonfly&#x2F;issues&#x2F;124" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dragonflydb&#x2F;dragonfly&#x2F;issues&#x2F;124</a><p>[7]: <a href="https:&#x2F;&#x2F;github.com&#x2F;dragonflydb&#x2F;dragonfly&#x2F;issues&#x2F;96" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dragonflydb&#x2F;dragonfly&#x2F;issues&#x2F;96</a>

21 comments

judofyralmost 3 years ago
&gt; I was NOT able to reproduce the 25X speed that Dragonfly claims<p>The Dragonfly benchmark which showed 25x faster was run on c6gn.16xlarge which has 64 vCPU. The m5.4xlarge you used &quot;only&quot; has 16 vCPU. Since Dragonfly is achieving its performance by using multiple threads it&#x27;s not weird that you weren&#x27;t able to replicate its performance gain.<p>In my opinion, when it comes to these types of multi-threaded benchmarks it&#x27;s much better to separate the &quot;baseline, one-process performance&quot; from &quot;how it scales with number of processes&quot;. E.g. if you first pin Dragonfly to only run on a single core you can find the baseline performance compared to Redis, and then you can run different benchmarks of Dragonfly with increasing number of cores to see how it scales. This should give you much better understanding of how the system behaves. (The release of Dragonfly actually prompted me to write a blog post on this: <a href="https:&#x2F;&#x2F;t.holmium.no&#x2F;dia&#x2F;apples-vs-oranges&#x2F;" rel="nofollow">https:&#x2F;&#x2F;t.holmium.no&#x2F;dia&#x2F;apples-vs-oranges&#x2F;</a>)
评论 #31799847 未加载
评论 #31800102 未加载
FridgeSealalmost 3 years ago
&gt; Dragonfly expects you to have the latest hardware[6] and the latest kernel[7] on all your servers. I find this outrageous because not all servers run 5.10<p>I don’t understand why this is “outrageous”? There’s performance features and better hardware utilisation in newer kernels? If you <i>want</i> the performance offered by the applications built on top of these, then arguably you should be prepared to run the hardware and software required to achieve this.
评论 #31799549 未加载
viraptoralmost 3 years ago
&gt; Dragonfly expects you to have the latest hardware[6] and the latest kernel[7] on all your servers. I find this outrageous because not all servers run 5.10 and a majority of them are still using long-running branches on 4.x.<p>I don&#x27;t see anything wrong with that. Either your kv store is performing OK or can be scaled using the usual methods and it&#x27;s not holding you back... or you actually critically depend on the fastest kv performance you can get. In the second case, you&#x27;ll be likely happy to dedicate some time to standing up a couple of machines with updated kernels.
评论 #31799034 未加载
websapalmost 3 years ago
If you&#x27;re running a really old version of Linux, you&#x27;re probably giving up on many-many performance optimizations.<p>&gt; I find this outrageous because not all servers run 5.10 and a majority of them are still using long-running branches on 4.x<p>I don&#x27;t think it&#x27;s outrageous to ask people to upgrade 5.10. This was released over 1.5 year ago and there&#x27;s no reason why your corporate overload shouldn&#x27;t consider migrating to this, or at least have someone working on qualifying their workloads.
fmajidalmost 3 years ago
KeyDB also has another key advantage over Redis: if your data set exceeds RAM, it will spill to disk (SSD) and maintain good performance.
romangealmost 3 years ago
Hi, I am the author of Dragonfly. Following this post, I performed the loadtest on instance m5.4xlarge, recorded myself and posted the video here: <a href="http:&#x2F;&#x2F;assets.dragonflydb.io&#x2F;videos&#x2F;video2609676488.mp4" rel="nofollow">http:&#x2F;&#x2F;assets.dragonflydb.io&#x2F;videos&#x2F;video2609676488.mp4</a><p>the command I used to load was: &quot;memtier_benchmark --ratio 1:0 -t 28 -c 20 -n 100000 --hide-histogram --distinct-client-seed -d 256&quot;<p>I did the recording to clear out any doubts whether my benchmark results are real.
评论 #31806463 未加载
bradknowlesalmost 3 years ago
Sorry, you say you ran the benchmarks, but where in this post do you link to your results?
评论 #31796936 未加载
jdsullyalmost 3 years ago
KeyDB author here. Lack of stable kernel support was a major reason we didn&#x27;t do io_uring yet. The goal for KeyDB is good performance out of the box not in specific benchmarks on specific hardware&#x2F;kernel versions. As io_uring becomes mainstream we will start to support it. In 6.2.3 we have async commands which permit reads to happen outside of the global lock. In some cases it can take extra time for writes from other clients to be visible which changes the consistency model so it is off by default but dramatically improves performance when enabled.<p>Doing a fresh rewrite would have enabled a nicer threading model, but it would make it harder to maintain compatibility. Plus at the time it was more to suggest to Redis multithreading was both desirable and possible which were disputed back then.
spaintechalmost 3 years ago
This article interests me as it has been a bucket list todo to get a good sense of some of the key&#x2F;value offerings, thank you for posting them.<p>Quick ask: I don’t see “some” of the other offering out there like MemCached… what was the criteria used to select these? I don’t see any source of how the test where run, specs of the systems, how the DB where set up, etc. Would be very valuable to have in order to attempt to re-validate these test on our own platform. I also came back and saw some of your updates to the outcomes, While the Get&#x2F;SET numbers are provided, I don’t find a reference to time, resource utilization, or time which would IMO make the data more valuable in understating how the numbers where achieved. * I might be a factor of the benchmarks themselves, but would add value IMO to your fantastic post.
dmitriidalmost 3 years ago
Redis and sqlite are two projects I can&#x27;t really believe exist. They both are absolutely magical.
评论 #31797978 未加载
评论 #31797075 未加载
fortyalmost 3 years ago
One important thing I would look at is &quot;is there independent managed hosting options&quot;, in case at some point you have better things to do than managing database and having to care if it&#x27;s the right hardware and kernel version. I know at least redis shines on this, with managed offering on all major cloud provider.
TheChaplainalmost 3 years ago
I&#x27;m trying to get my workplace to accept Redis for simple caching but they&#x27;re not open to the idea. Instead they&#x27;re all in Hazelcast but real stingy about who gets to use it and for how much memory.<p>I just want to cache some objects and avoid hammer the DB on every request :´(
评论 #31799872 未加载
gkorlandalmost 3 years ago
<a href="https:&#x2F;&#x2F;redis.com&#x2F;blog&#x2F;redis-architecture-13-years-later&#x2F;" rel="nofollow">https:&#x2F;&#x2F;redis.com&#x2F;blog&#x2F;redis-architecture-13-years-later&#x2F;</a>
throwaway81523almost 3 years ago
How about including Pedis in this? It is a Redis partial reimplementation, written around Seastar: <a href="https:&#x2F;&#x2F;github.com&#x2F;fastio&#x2F;1store" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;fastio&#x2F;1store</a>
评论 #31807597 未加载
qatanahalmost 3 years ago
Also if you can add amazon memory db to yor list of benchmarks, would also be interested to know more.<p><a href="https:&#x2F;&#x2F;aws.amazon.com&#x2F;memorydb&#x2F;" rel="nofollow">https:&#x2F;&#x2F;aws.amazon.com&#x2F;memorydb&#x2F;</a>
评论 #31802215 未加载
benedetto73almost 3 years ago
Redis can do 1M or even 2M requests per second on a decent box. What payload are you using? Can we see the script you are using to generate the traffic and measure the performance?
cpercivaalmost 3 years ago
<i>I have run the benchmarks myself for each store.</i><p>I feel like I&#x27;m missing something here. Which benchmarks did you run, and what were the results?
评论 #31796563 未加载
cientificoalmost 3 years ago
Why do you consider single threaded as a reason to have less throughput?<p>Are you looking for throughput or speed?<p>Also, what are your needs?
评论 #31796752 未加载
w-llalmost 3 years ago
Have YOU tried benchmarking any of them locally or in the cloud?
评论 #31796401 未加载
didipalmost 3 years ago
Anyone knows where can I find a good helm chart for KeyDB?
ksecalmost 3 years ago
&gt;Redis, which I&#x27;d like to call the &quot;original&quot; key&#x2F;value store<p>My old friend Memcached just came by and want to say Hello. He is still alive and kicking. Netflix has been treating him well.
评论 #31798127 未加载
评论 #31796865 未加载
评论 #31798865 未加载
评论 #31804559 未加载
评论 #31798924 未加载
评论 #31796969 未加载
评论 #31797109 未加载