Redis and the Cost of Ambition(charlesleifer.com) |
Redis and the Cost of Ambition(charlesleifer.com) |
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.
> 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.