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

101–110 of 311 posts

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

#101

Post by dmitry-vsl »

neoden wrote: post #46
coder543 wrote: post #36

Earlier quoted context omitted.

I keep hoping Postgres will one day have the ability to mark a timestamp column as an expiry column. It would be useful for all kinds of things beyond caching, including session tokens, feature flags, background jobs, rate limiting, delayed deletion (as a variant of soft deletion), etc. It seems like the autovacuum could take care of these expired rows during its periodic vacuum. The query planner could automatically…

One could use a trigger for this. All we need is to setup a trigger that would delete all expired records looking at some timestamp column on update. That would eat up some latency but as was said, most projects would find it good enough anyway.

Probably better to use partitioned table and drop old partitions.

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

#102

Post by positron26 »

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.

A lot of great benchmarking probably dies inside internal tuning. When we're lucky, we get a blog post, but if the creator isn't incentivized or is even discouraged by an employer from sharing the results, it will never see the light of day.

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

#103

Post by Koffiepoeder »

mj2718 wrote: post #89

My laptop running OOTB Postgres in docker does 100k requests per second with ~5ms latency. How are you getting 20x slower?

If you look at their lab [0], it seems his NAS is separate from his kubernetes nodes. If he hasn't tuned his networking and NAS to the maximum, network storage may in fact add a LOT of delay on IOPS. Could be the difference between fractions of a millisecond vs actual milliseconds. If your DB load is mostly random reads this can really harm performance. Just hypothesizing here though, since it is not clear whether his DB storage is actually done on the NAS.

[0]: https://dizzy.zone/2025/03/10/State-of-my-Homelab-2025/

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

#104

Post by maxbond »

motorest wrote: post #92
maxbond wrote: post #76

Earlier quoted context omitted.

A TTL doesn't really tell you if it's stale though. It gives you an upper bound on how long it can have been stale. But something becomes stale when the underlying resource is written to, which can happen an hour or an instant after you cache it. You should probably evict it when the write comes in. In my mind, it's for evicting things that aren't in use (to free up memory).

> A TTL doesn't really tell you if it's stale though (...) Non-sequitur,and imaterial to the discussion. > You should probably evict it when the write comes in. No. This is only required if memory is maxed out and there is no more room to cache your entry. Otherwise you are risking cache misses by evicting entries that are still relatively hot.

> Non-sequitur,and imaterial to the discussion.

You said:

> The whole point of a TTL is to be able to tell whether a cache entry is still fresh or it is stale and must be revalidated.

So I responded to it. I don't really understand why you think that's nonsequiter.

> No.

I'm a bit confused. We're not using TTLs and we're not evicting things when they become invalid. What is your suggestion?

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

#105

Post by frollogaston »

motorest wrote: post #92
maxbond wrote: post #76

Earlier quoted context omitted.

A TTL doesn't really tell you if it's stale though. It gives you an upper bound on how long it can have been stale. But something becomes stale when the underlying resource is written to, which can happen an hour or an instant after you cache it. You should probably evict it when the write comes in. In my mind, it's for evicting things that aren't in use (to free up memory).

> A TTL doesn't really tell you if it's stale though (...) Non-sequitur,and imaterial to the discussion. > You should probably evict it when the write comes in. No. This is only required if memory is maxed out and there is no more room to cache your entry. Otherwise you are risking cache misses by evicting entries that are still relatively hot.

The cache isn't the only hot thing here. Relax.

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

#106

Post by whateveracct »

motorest wrote: post #67
whateveracct wrote: post #56

Earlier quoted context omitted.

most people with blogs don't know what they're doing. or don't care to know? sadly they get hired at companies and everyone does what they say cuz they have a blog. i've seen some shit in that department it's wild how much some people really are imposters.

> most people with blogs don't know what they're doing. or don't care to know? I don't see any point to this blend of cynical contrarianism. If you feel you can do better, put your money where your mouth is. Lashing at others because they went through the trouble of sharing something they did is something that's absurd and creates no value. Also, maintaining a blog doesn't make anyone an expert, but not maintaining a…

just an observation :)

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

#107

Post by vasco »

dizzyVik wrote: post #96
vasco wrote: post #80

Earlier quoted context omitted.

It's not a paper or a journal but you could at least try to run a decent benchmark. As it is this serves no purpose other than reinforcing whatever point you started with. Didn't even tweak postgres buffers, literally what's the point.

I still end up recommending using postgres though, don't I?

That's the point, you put no effort and decided to do what you had decided already to do before.

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

#108

Post by maxbond »

MobiusHorizons wrote: post #90
maxbond wrote: post #26

Earlier quoted context omitted.

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.

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.

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

#109

Post by frollogaston »

motorest wrote: post #69
frollogaston wrote: post #63

Earlier quoted context omitted.

I didn't say it's cheaper for the same cache size. But yeah a base tier Redis that will carry a small project tends to be a lot cheaper than the base tier Postgres.

> I didn't say it's cheaper for the same cache size. So be specific. What exactly did you wanted to say? > But yeah a base tier Redis that will carry a small project tends to be a lot cheaper than the base tier Postgres. This is patently false. I mean,some cloud providers offer nosql databases with sub-20ms performance as part of their free tier. Just go ahead and provide any evidence, any at all,that support the ide…

Look at the Heroku pricing. If you don't like Heroku then look at AWS pricing. Specifically for Postgres, not a NoSQL DB (which Redis can be too)

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

#110

Post by dizzyVik »

pcthrowaway wrote: post #99
dizzyVik wrote: post #96

Earlier quoted context omitted.

I still end up recommending using postgres though, don't I?

"I'll use postgres" was going to be your conclusion no matter what I guess? I mean what if an actual benchmark showed Redis is 100X as fast as postgres for a certain use case? What are the constraints you might be operating with? What are the characteristics of your workload? What are your budgetary constraints? Why not just write a blog post saying "Unoptimized postgres vs redis for the lazy, running virtualized wit…

I completely agree that this is not relevant for anyone running such workloads, the article is not aimed at them at all.

Within the constraints of my setup, postgres came out slower but still fast enough. I don't think I can quantify what fast enough is though. Is it 1000 req/s? Is it 200? It all depends on what you're doing with it. For many of my hobby projects which see tens of requests per second it definitely is fast enough.

You could argue that caching is indeed redundant in such cases, but some of those have quite a lot of data that takes a while to query.

Post reply on HN