Hacker News Reader

Comment by mehphp | Hacker News Reader

I think you just convinced me to drop redis for my new project.

Definitely a premature optimization on my part.

We dropped Redis from a 4 year old app that had a rapidly growing userbase. Best choice ever. We never looked back once other than to think how annoying it was to have to deal with Redis in addition to Postgres.

Sincerely (Feel the need to add that given the tension around here in these comments), I'm curious how Redis was annoying. Can you give any detail/insight?

Every component takes work. You have to upgrade it, something goes wrong with tuning, you have to debug it, etc. It went wrong about once a month, somehow. I'm sure it was fixable, but time is a commodity, and not having it any more gives us more time to work on other things.

We can't get rid of Postgres, but since we run Postgres on GCP we really never even think about it.

“Dropping” something from a “new” project is premature optimization?

Wherever you go, there you are.

Presumably adding Redis to a new project with no performance issues (yet?) is the premature optimisation.

If you are optimizng for simplicity it may not be, as the use as a cache is much (much) more straightforward. Also, for a new project, I'd go with in-memory service-level cache as it outperforms both (in any metric) and can be easily replaced once the need arises.

I read it as dropping something that _had been_ a premature optimisation.

I was referring to adding redis prematurely

“Premature optimization” typically refers to optimizing before profiling. Ie optimizing in places that won’t help.

Is redis not improving your latency? Is it adding complexity that isn’t worth it? Why bother removing it?

I like to call cases like this "premature distribution." Or maybe you could call it "premature capacity." If you have an application running in the cloud with several thousand requests per day, you could probably really benefit from adding a service like Redis.

But when you have 0-10 users and 0-1000 requests per day, it can make more sense to write something more monolithic and with limited scalability. Eg, doing everything in Postgres. Caching is especially amenable to adding in later. If you get too far into the weeds managing services and creating scalability you might bogged down and never get your application in front of potential users in the first place.

Eg, your UX sucks and key features aren't implemented, but you're tweaking TTLs and getting a Redis cluster to work inside Docker Compose. Is that a good use of your time? If your goal is to get a functional app in front of potential users, probably not.

You probably don't need Redis until you have thousands of requests per minute, nevermind per day.

I'd go further and even say per second! Actually PG can still handle it, the main problem is that it has a more complex runtime that can spike. Backups? Background jobs doing heavy writes? Replication? Vacuum? Can tend to cause multisecond slowdowns which may be undesirable depending on your SLA. But otherwise it would be fine.

To be clear my question isn’t claiming redis isn’t premature optimization, but rather asking why the op thinks that it is. Being new doesn’t automatically mean that there is no need for latency sensitivity. Making that assumption could be just as premature. Ripping something out that is already working also takes time and the trade offs need to be weighed.

Can't respond for them of course but I didn't take the impression that it was already fully implemented, working, and functionally necessary. I took the impression they had started going down that path but it was still easy to bail. That's just a vibe though.

But I agree that it would be appropriate to start out that way in some projects.

Reply on news.ycombinator.com