Redis and the Cost of Ambition

tao_oat

There was really good discussion of this article on lobste.rs: https://lobste.rs/s/oznirn/redis_cost_ambition

sc68cal

I do agree with the feeling that Redis started to add more and more features as time went on. A lot of that is because the time and cost to stand up a dedicated service (like Kafka, RabbitMq, etc etc) was higher than just putting more data into Redis. While I agree with the theme that Redis has become more and more complicated and had more features added to it, as part of a monetization push by Redis Inc, it's understandable. Especially since there are plenty of other posts on HN titled "Just use Postgres" for everything. So, why does Postgres get a pass on being a message queue, distributed lock manager, JSON document store, and vector database, while Redis is not allowed to?

epolanski

I'm not entirely sure what the point of the author is. Yes, Redis scope got bigger, but not at the expense of the core functionality. It's not like using it as a val key store got worse and more complex. Redis itself is more of a data service that can bend to many needs, and those all of those things well. Not sure why supporting more data structures would be bad.

nicwolff

Citing Aphyr's analysis of a pre-release version of Redis-Raft as though it applied to a shipped product is so disingenuous as to invalidate this whole post. The very next sentence after the one he quoted is > We emphasize, again, that these are all internal development builds: Redis-Raft has no production users, so the real-world impact of these issues is negligible. and of the 21 errors he found, 20 were already fixed before he published his review.