Live data from Hacker News

Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB

docs.keydb.dev

11–20 of 21 posts

Re: Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB

#11

These benchmark posts are good but they are a bit unsatisfying, I wish they’d spend more time a laying out the fundamental differences of each technology and the trade offs that are the result of how the different systems are built. At the end of the day an engineer shouldn’t pick database because it’s the fastest but because it fits their use case the best. I get that reddis, memcached, and keydb are all roughly in…

The post covers all the points you mention. The benchmark only covers Redis forks so it doesn’t get a whole lot more apples-to-apples than this.

> So there are 3 offerings by 3 companies, all compatible with eachother and based off open source Redis: Elasticache is offered as an optimized service offering of Redis; RedisLabs and Redis providing a core product and monetized offering, and KeyDB which remains a fast cutting edge (open source) superset of Redis. This blog looks specifically at performance, however there is a section at the end of this blog that also outlines other key differences.

The last paragraphs give a good overview of the differences.

Re: Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB

#12

These benchmark posts are good but they are a bit unsatisfying, I wish they’d spend more time a laying out the fundamental differences of each technology and the trade offs that are the result of how the different systems are built. At the end of the day an engineer shouldn’t pick database because it’s the fastest but because it fits their use case the best. I get that reddis, memcached, and keydb are all roughly in…

Missing the point all over the place.

Re: Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB

#13
post #8

This is interesting, but why not add in a benchmark for regular redis as a 'baseline'. Is it really worth upgrading to me?

It does use regular Redis, from the new 6.0 release. This post is comparing different products, not versions of Redis.

If you want to see how much Redis itself improved from 5.0 to 6.0 then you can look at Salvatore's updates: https://twitter.com/antirez/status/1110973404226772995 and other benchmarks: https://itnext.io/benchmarking-the-experimental-redis-multi-...

Re: Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB

#14

These benchmark posts are good but they are a bit unsatisfying, I wish they’d spend more time a laying out the fundamental differences of each technology and the trade offs that are the result of how the different systems are built. At the end of the day an engineer shouldn’t pick database because it’s the fastest but because it fits their use case the best. I get that reddis, memcached, and keydb are all roughly in…

> "This blog looks specifically at performance, however there is a section at the end of this blog that also outlines other key differences."

Memcached is not a part of this comparison, only Redis and forks.

It's hard to summarize much more in a single blog post and is really up to the dev to do the research before picking a solution.

Re: Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB

#15
post #7

why a separate project for keydb? couldn't all this just be merged into the main project? are there significant architectural changes/tradeoffs in keydb that made it not-ideal to merge into redis?

Yes, the overview page covers it: https://docs.keydb.dev/docs/intro/

KeyDB offers more performance, functionality and deployment features that are not possible or won't be allowed in mainline Redis.

Re: Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB

#17

Excellent post! I wonder why, given the performance, KeyDB is not more popular? Is there lack of hosted services?

Redis (single-threaded) is just fine for all but the biggest scale, is well-tested, and because it's a simpler model less likely to have all the terribly complicated edge-case bugs the introduction of concurrency implies.

Also there's a matter of need. It does one no good if a KV store can churn through 200 kops/s if you can only deliver 100kops/s. If one or two redis instances (plus replicas, etc., or maybe a minimal three-master cluster) can serve the entire workload, saving two or three nodes by "upgrading" to the likes of KeyDB doesn't seem worth it. I mean, unless you're aiming to get to the melt-the-metal it's so "hot" all the time performance.

Re: Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB

#18
post #17

Excellent post! I wonder why, given the performance, KeyDB is not more popular? Is there lack of hosted services?

Redis (single-threaded) is just fine for all but the biggest scale, is well-tested, and because it's a simpler model less likely to have all the terribly complicated edge-case bugs the introduction of concurrency implies. Also there's a matter of need. It does one no good if a KV store can churn through 200 kops/s if you can only deliver 100kops/s. If one or two redis instances (plus replicas, etc., or maybe a minima…

Interesting, yeah more bugs due to the complexity of multi threaded programming is the first thing that came to mind.

Re: Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB

#19

Excellent post! I wonder why, given the performance, KeyDB is not more popular? Is there lack of hosted services?

Redis has been around a long time. ElastiCache has been around a while and is deployable in AWS very easily. KeyDB is new.

And that comes with lots of libraries, tools, and documentation to make using them easy

Re: Comparing the new Redis6 multithreaded I/O to Elasticache and KeyDB

#20
post #19

Earlier quoted context omitted.

Redis has been around a long time. ElastiCache has been around a while and is deployable in AWS very easily. KeyDB is new.

And that comes with lots of libraries, tools, and documentation to make using them easy

KeyDB is compatible with existing Redis libraries and tools. If you use some of the newer features your library may lack direct support but most have extensiblity features built in.
Post reply on HN