<story><title>A multithreaded fork of Redis that is faster</title><url>https://docs.keydb.dev/blog/2019/10/07/blog-post/</url></story><parent_chain></parent_chain><comment><author>erulabs</author><text>Any time these &amp;quot;much faster than Redis&amp;quot; databases come up, the sysadmin in me wonders how many people have had actual performance limitation issues with Redis. I&amp;#x27;ve seen Redis servers handle hundreds of GB of traffic per hour. I&amp;#x27;ve worked at companies where Aerospike and others are proposed as replacements for Redis because &amp;quot;they&amp;#x27;re faster&amp;quot; - and I point out the 98% idle CPUs on the Redis server, and the near-100%-usage CPUs on the app server fleet and mouth &amp;quot;But... why?&amp;quot;&lt;p&gt;Replacing Redis with &amp;quot;something faster&amp;quot; is a bit like removing the doors on a car because &amp;quot;lighter means faster!&amp;quot;. It might look good on a racetrack, but it&amp;#x27;s about as pragmatic as climbing through a window every morning before setting off for work.</text></comment>
<story><title>A multithreaded fork of Redis that is faster</title><url>https://docs.keydb.dev/blog/2019/10/07/blog-post/</url></story><parent_chain></parent_chain><comment><author>scott_s</author><text>Two HN threads from around when the project started:&lt;p&gt;Show HN: KeyDB – A Multithreaded Fork of Redis, &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=19257987&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=19257987&lt;/a&gt;&lt;p&gt;KeyDB: A Multithreaded Redis Fork, &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=19368955&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=19368955&lt;/a&gt;</text></comment>