Hacker News Reader

Comment by node-bayarea | Hacker News Reader

I understand that Postgres is an awesome DB. But my point is, why not use Redis especially when it comes with RedisJSON, RediSearch, RedisGraph, etc and gets most of the things done without any SQL. Why should we stick to the traditional approach? Is there any actual proof that Redis won't be able to handle it other than just guessing?

View on HN

Because just like Postgres, there's a reason people don't use it for absolutely everything. Usually, purpose built tools will offer better features, performance, etc.

I am digging a company out of using Redis as a main database right now. They put everything in Redis, and the DB grew to be very large and they are paying a ton because they chose this. As far as the actual application logic it is using idiomatic redis, and it works but it is absolutely not optimal.

As far as I'm concerned the question is backwards, why would you want to use Redis for everything? Are you just trying to avoid SQL? SQL is basically the optimal solution (see the field of Relational Algebra) for querying relational data (and almost all data that matters is relational).

The boring "right" answer is use the right tool for the job. It's unlikely that RedisJSON is better (depends how you measure of course) than MongoDB/RethinkDB, RedisGraph better than Neo4J, RediSearch better than ElasticSearch/etc. If I wanted to pick a technology to go all in on, it definitely wouldn't be Redis -- it'd be Postgres (which has JSON support, Graph support, timeseries storage support, full text search built in), a fully open source product with a creator that hasn't left the project, with way more than one company offering tons of support and advanced behavior, etc.

BTW if you really like Redis, check out KeyDB[0]. KeyDB can fallback to FLASH storage so it might actually work in a large data case (I considered switching my client to it.

[0]: https://keydb.dev/

Reply on news.ycombinator.com