4 ms·

I think you just convinced me to drop redis for my new project. Definitely a premature optimization on my part.

• throwup238 1y ago
  “Dropping” something from a “new” project is premature optimization? Wherever you go, there you are.
  • danielheath 1y ago
    I read it as dropping something that _had been_ a premature optimisation.
  • qu4z-2 1y ago
    Presumably adding Redis to a new project with no performance issues (yet?) is the premature optimisation.
    • rplnt 1y ago
      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.
  • mehphp 1y ago
    I was referring to adding redis prematurely
• MobiusHorizons 1y ago
  “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?
  • maxbond 1y ago
    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.
    • not_kurt_godel 1y ago
      You probably don't need Redis until you have thousands of requests per minute, nevermind per day.
      • foobarian 1y ago
        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.
    • MobiusHorizons 1y ago
      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.
      • 1y ago
• flanked-evergl 1y ago
  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.
  • Implicated 1y ago
    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?
    • flanked-evergl 1y ago
      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.