It's not right to say that Redis "had nothing to do with its development."
They were a major contributors and were managing the project for many years. The problem like many other open source project is that the innovation is shared with competitors who happen to be huge corporates. What would you do if for every line of code you add your competitors get X10 customers than you?
Sure. You can do that. But the community needs a single standard. Open standard that all in-memory data stores like Redis, ValKey, DragonflyDB, KeyDB, Kvrocks will support. Otherwise you will end up in a vendor lock.
The figma route is exactly the case were the cost of service is very low. It make sense for Figma to offer a free tier because it costs them almost nothing. But when you have to keep the data available in submillisecond latency it is to expensive to sponsor a free tier.
All, My name is Oded Poncz, I am the CEO of DragonflyDB. Our goal with the FAQ was to aggragate valuable information for our community. We will take all the valuable feedback from this thread and improve. Thank you all for the feedback.
KeyDB is a fork of Redis, whereas Dragonfly introduces a brand-new architecture, crafted from the ground up utilizing a share nothing, multi-threaded design. It implements both Redis and memcached APIs
hmm, Redis Labs are setting a cluster of 40 Redis processes on the same instance. It would be extremely difficult to do that with Redis OSS for anyone else.
"For the last 15 years, Redis has been the primary technology for developers looking to provide a real-time experience to their users. Over this period, the amount of data the average application uses has increased dramatically, as has the available hardware to serve that data. Readily available cloud instances today have at least 10X the CPUs and 100X more memory than their equivalent counterparts had 15 years ago. However, the single-threaded design of Redis has not evolved to meet modern data demands nor to take full advantage of modern hardware."
That's not what they are saying is wrong with Redis. Is Redis really 'antique tech'? Arguably, concurrent processing with a scale-up-only approach is a poor fit for "modern hardware".
So yes, you are correct: Redis from github requires knowledge and (your) code to make n instances work together (whether on the same node or not). But to claim that this is the case for "anyone else [but Redis Labs]" is questionable.
From a certain architectural camp, pin-to-core-process-in-parallel approach is optimal for [scaling on] "modern hardware". Salvatore can correct me on this but I don't recall that being a consideration at the early days, but it turned out to be a good choice. Some of the Redis apis however require dataset ensemble participation (anykind of total order semantics over the partitioned set) which is what is "difficult" to do effectively.
So basically any startup that can do that, should theoretically be able to squeeze more performance form their SaaS infrastructure than running Dragonfly type of architecture. Bonus, as pointed out by Redis Labs, being that the lots of parallel k/v processes can bust out of the max-jumbo-box should you ever need that to happen (for 'reliability' for example) ..
I think using word "misleading" is also "misleading".
Dragonfly hides complexity. Docker hid complexity of managing cgroups and deploying applications. S3 hid complexity of writing into separate disks. But you do not call S3 or minio misleading because they store stuff similarly to how disk stores files. Dragonfly hides complexity of managing bunch of processes on the same instance and the outcome of this is a cheaper production stack. What do you think has higher effective memory capacity on c6gn.16xlarge: a single process using all the memory or 40 processes which you need to provision independently?
It's misleading because, practically speaking, the type of people who are after the performance you advertise, are running clusters to begin with. So what you are selling is just a simplified stack that lets you not have to manage one more "system". That's fair but you could mention that? Or atleast acknowledge that if you repeat these tests with redis cluster the results will be wildly different and you wont have those crazy looking charts.
For example it's like me claiming that my new python web framework is X faster than Flask because it comes bundles with uwsgi. Yes, technically mine is faster, but its not a fair comparison.
>Change License: Apache License, Version 2.0, as published by the Apache Foundation.
>Effective on the Change Date, or the fifth anniversary of the first publicly available distribution of a specific version of the Licensed Work under this License, whichever comes first, the Licensor hereby grants you rights under the terms of the Change License, and the rights granted in the paragraph above terminate.
