Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Redis is fast – I'll cache in Postgres

dizzy.zone

Post reply on HN
Print view View original

81–90 of 311 posts

Re: Redis is fast – I'll cache in Postgres

#81

Post by gopalv »

wewewedxfgdf wrote: post #65
ezekiel68 wrote: post #51

> Both postgres and redis are used with the out of the box settings Ugh. I know this gives the illusion of fairness, but it's not how any self-respecting software engineer should approach benchmarks. You have hardware. Perhaps you have virtualized hardware. You tune to the hardware. There simply isn't another way, if you want to be taken seriously. Some will say that in a container-orchestrated environment, tuning go…

Fully agree. Postgres is a power tool usable for many many use cases - if you want performance it must be tuned. If you judge Postgres without tuning it - that's not Postgres being slow, that's the developer being naive.

> If you judge Postgres without tuning it - that's not Postgres being slow, that's the developer being naive.

Didn't OP end by picking Postgres anyway?

It's the right answer even for a naive developer, perhaps even more so for a naive one.

At the end of the post it even says

>> Having an interface for your cache so you can easily switch out the underlying store is definitely something I’ll keep doing

Re: Redis is fast – I'll cache in Postgres

#82

Post by lelanthran »

jamesblonde wrote: post #43

Why do we promote articles like this that have nice graphs and are well written, when they should get a grade 'F' as an actual benchmark study. The way it is presented, a casual reader would think Postgres is 2/3rds the performance of Redis. Good god. He even admits Postgres maxxed out its 2 cores, but Redis was bottlenecked by the HTTP server. We need more of an academic, not a hacker, culture for benchmarks.

I'm not seeing your point. This wouldn't get an F, purely because all the parameters are documented.

Conclusions aren't incorrect either, so what's the problem?

Re: Redis is fast – I'll cache in Postgres

#83

Post by piniondna »

dizzyVik wrote: post #72
didip wrote: post #66

Is this engagement bait? Sigh... fine, at least I bite the bait here: 1. The use-case is super specific to homelab where consistency doesn't matter. You didn't show us the Redis persistence setup. What is the persistence/durability setting? I bet you'd lose data the one day you forgot and flip the breaker of your homelab. 2. What happened when data is bigger than your 8GB of RAM on Redis? 3. You didn't show us the PG…

1. No persistence for redis. 2. Redis would get OOM killed. 3. The default config coming with the image was used. 4. Yes, I gave it 2 cpus. I wanted to compare how would my http server behave if I used postgres for caching and what the difference would be if I used redis instead. This benchmark is only here to drive the point that sometimes you might not even need a dedicated kv store. Maybe using postgres for this i…

Redis is one of the simplest services I’ve used… we could flip the script and say “for many db use cases postgresdb is overkill, just use Redis… you get caching too”. I’m not sure exactly what this commentary adds to a real world architecture discussion. The whole thing seems a little sophomoric, tbh.

Re: Redis is fast – I'll cache in Postgres

#84

Post by lelanthran »

wewewedxfgdf wrote: post #65
ezekiel68 wrote: post #51

> Both postgres and redis are used with the out of the box settings Ugh. I know this gives the illusion of fairness, but it's not how any self-respecting software engineer should approach benchmarks. You have hardware. Perhaps you have virtualized hardware. You tune to the hardware. There simply isn't another way, if you want to be taken seriously. Some will say that in a container-orchestrated environment, tuning go…

Fully agree. Postgres is a power tool usable for many many use cases - if you want performance it must be tuned. If you judge Postgres without tuning it - that's not Postgres being slow, that's the developer being naive.

He concluded postgresql to be fast enough, so what's the problem?

IOW, he judged it fast enough.

Re: Redis is fast – I'll cache in Postgres

#85

Post by 000ooo000 »

staplung wrote: post #77

I guess my question is: why bother with a benchmark if the pick is pre-ordained? Is it the case that at some point the results would be so lopsided that you would pick the faster solution? If so, what is that threshold? I.e. when does performance trump system simplicity? To me those are the interesting questions.

>why bother with a benchmark if the pick is pre-ordained

Validating assumptions

Curiosity/learning

Enraging a bunch of HN readers who were apparently born with deep knowledge of PG and Redis tuning

Re: Redis is fast – I'll cache in Postgres

#86

Post by ENGNR »

jamesblonde wrote: post #43

Why do we promote articles like this that have nice graphs and are well written, when they should get a grade 'F' as an actual benchmark study. The way it is presented, a casual reader would think Postgres is 2/3rds the performance of Redis. Good god. He even admits Postgres maxxed out its 2 cores, but Redis was bottlenecked by the HTTP server. We need more of an academic, not a hacker, culture for benchmarks.

There’s too many hackers on hacker news!

Re: Redis is fast – I'll cache in Postgres

#87

Post by re-thc »

hvb2 wrote: post #74
motorest wrote: post #60

Earlier quoted context omitted.

> He even admits Postgres maxxed out its 2 cores, but Redis was bottlenecked by the HTTP server. What exactly is your point? That you can further optimize either option? Well yes, that comes at no suprise. I mean, the latencies alone are in the range of some transcontinental requests. Were you surprised that Redis outperformed Postgres? I hardly think so. So what's the problem? The main point that's proven is that th…

I've done this many times in AWS leveraging dynamodb. Comes with ttl support (which isn't precise so you still need to check expiration on read), and can support long TTLs as there's essentially no limit to the storage. All of this at a fraction of the cost of HA redis Only if you need that last millisecond of performance and have done all other optimizations should one consider redis imho

> All of this at a fraction of the cost of HA redis

This depends on your scale. Dynamodb is pay per request and the scaling isn’t as smooth. At certain scales Redis is cheaper.

Then if you don’t have high demand maybe it’s ok without HA for Redis and it can still be cheaper.

Re: Redis is fast – I'll cache in Postgres

#90

Post by MobiusHorizons »

maxbond wrote: post #26
MobiusHorizons wrote: post #16

Earlier quoted context omitted.

“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 ev…

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.
Post reply on HN