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?
For that mater, Redis/Valkey is relatively easy to stand up... I almost don't give it a second thought to stand up Redis, and I'll generally reach for an MQ library that's using Redis over the dbms more often than not... Mostly in that, by comparison setting up Rabbit or Kafka gets a lot more complex.
What I don't always "get" is Redis as a persistent database, such as with the "LamerNews" codebase (which EchoJS uses), so that use case still feels a bit alien to me, and I'm surprised it works as well as it does.
I think that if you develop your application from scratch and directly use Redis as it was intended (data structures over the network) then it makes sense. I've done it for some applications and it's quite nice.
But you have to make the choice to skip using a relational database, and a lot of application frameworks make it very easy to use a relational database out of the box, to the point where you would have to make a conscious choice to use Redis directly, and sometimes for a CRUD app it's easier to just use the RDBMS.
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.
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?
For that mater, Redis/Valkey is relatively easy to stand up... I almost don't give it a second thought to stand up Redis, and I'll generally reach for an MQ library that's using Redis over the dbms more often than not... Mostly in that, by comparison setting up Rabbit or Kafka gets a lot more complex.
What I don't always "get" is Redis as a persistent database, such as with the "LamerNews" codebase (which EchoJS uses), so that use case still feels a bit alien to me, and I'm surprised it works as well as it does.
I think that if you develop your application from scratch and directly use Redis as it was intended (data structures over the network) then it makes sense. I've done it for some applications and it's quite nice.
But you have to make the choice to skip using a relational database, and a lot of application frameworks make it very easy to use a relational database out of the box, to the point where you would have to make a conscious choice to use Redis directly, and sometimes for a CRUD app it's easier to just use the RDBMS.
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.
There was really good discussion of this article on lobste.rs: https://lobste.rs/s/oznirn/redis_cost_ambition
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.