Rendered at 20:41:27 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
sc68cal 6 hours ago [-]
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?
tracker1 3 hours ago [-]
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.
sc68cal 1 hours ago [-]
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.
epolanski 40 minutes ago [-]
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.
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?
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.
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.
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.