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

121–130 of 311 posts

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

#121

Post by ahoka »

hvb2 wrote: post #97
re-thc wrote: post #87

Earlier quoted context omitted.

> 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.

You would need to get to insane read counts pretty much 24/7 for this to work out. For HA redis you need at least 6 instances, 2 regions * 3 AZs. And you're paying for all of that 24/7. And if you truly have 24/7 use then just 2 regions won't make sense as the latency to get to those regions from the other side of the globe easily removes any caching benefit.

A 6 node cache and caching in DynamoDB, what the hell happened to the industry? Or people just call every kind of non business-object persistence cache now?

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

#122

Post by vidarh »

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…

On one hand I agree with you, but on the other hand defaults matter because I regularly see systems with the default config and no attempt to tune.

Benchmarking the defaults and benchmarking a tuned setup will measure very different things, but both of them matter.

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

#124

Post by Timshel »

k9294 wrote: post #119

> For postgres, the bottleneck was the CPU on the postgres side. It consistently maxed out the 2 cores dedicated to it, while also using ~5000MiB of RAM. Comparing throttled pg vs non-throttled redis is not a benchmark. Of course when pg is throttled you will see bad results and high latencies. A correct performance benchmark would be to give all components unlimited resources and measure performance and how much the…

Since it's in the context of a homelab you usually don't change your hardware for one application, using the same resources in both test seems logical (could argue that the test should be pg vs redis + pg).

And their point is that it's good enough as is.

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

#125

Post by m000 »

lelanthran wrote: post #82
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?

The use case is not representative of a real-life scenario, so the value of the presented results are minimal.

A takeaway could be that you can dedicate a postgres instance for caching and have acceptable results. But who does that? Even for a relatively simple intranet app, your #1 cost when deploying in Google Cloud would probably be running Postgres. Redis OTOH is dirt cheap.

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

#126

Post by high_na_euv »

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…

Disagree, majority of software is running on defaults, it makes sense to compare them this way

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

#127

Post by ahoka »

Neikius wrote: post #111

I skimmed the article, but why is everyone always going for distributed cache? What is wrong with in-memory cache? Lowest latency, fast, easy to implement. Yeah ok, you have 30 million entries? Sure. You need to sync something over multiple nodes? Not sure I would call that a cache.

Consistency could be one reason, but I think the best caching strategy is not to need a cache. Adding a (not just) distributed cache early can hide performance issues that can be fixed instead of working around while introducing complexity and maybe even adding data consistency issues and paradoxically performance degradation.

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

#128

Post by m000 »

Timshel wrote: post #124
k9294 wrote: post #119

> For postgres, the bottleneck was the CPU on the postgres side. It consistently maxed out the 2 cores dedicated to it, while also using ~5000MiB of RAM. Comparing throttled pg vs non-throttled redis is not a benchmark. Of course when pg is throttled you will see bad results and high latencies. A correct performance benchmark would be to give all components unlimited resources and measure performance and how much the…

Since it's in the context of a homelab you usually don't change your hardware for one application, using the same resources in both test seems logical (could argue that the test should be pg vs redis + pg). And their point is that it's good enough as is.

It's a homelab. If it works, it works. And we already knew that it would work without reading TFA. No new insights whatsoever. So what's the point of sharing or discussing?

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

#129

Post by IanCal »

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…

I disagree. They found that Postgres, without tuning, was easily fast enough on low level hardware and would come with the benefit of not deploying another service. Additionally tuning it isn’t really relevant.

If the defaults are fine for a use case then unless I want to tune it for personal interest it’s either a poor use of my fun time or a poor use of my clients funds.

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

#130

Post by odie5533 »

hvb2 wrote: post #97
re-thc wrote: post #87

Earlier quoted context omitted.

> 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.

You would need to get to insane read counts pretty much 24/7 for this to work out. For HA redis you need at least 6 instances, 2 regions * 3 AZs. And you're paying for all of that 24/7. And if you truly have 24/7 use then just 2 regions won't make sense as the latency to get to those regions from the other side of the globe easily removes any caching benefit.

It's $9/mo for 100 MB of ElastiCache Serverless which is HA.

It's $15/mo for 2x cache.t4g.micro nodes for ElastiCache Valkey with multi-az HA and a 1-year commitment. This gives you about 400 MB.

It very much depends on your use case though if you need multiple regions then I think DynamoDB might be better.

I prefer Redis over DynamoDB usually because it's a widely supported standard.

Post reply on HN