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

191–200 of 311 posts

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

#191

Post by Implicated »

pbronez wrote: post #187
rollcat wrote: post #167

Earlier quoted context omitted.

It's crazy how wildly inaccurate "top-of-the-list" LLMs are for straightforward yet slightly nuanced inquiries. I've asked ChatGPT to summarize Go build constraints, especially in the context of CPU microarchitectures (e.g. mapping "amd64.v2" to GOARCH=amd64 GOAMD64=v2). It repeatedly smashed its head on GORISCV64, claiming all sorts of nonsense such as v1, v2; then G, IMAFD, Zicsr; only arriving at rva20u64 et al un…

How was the LLM accessing the docs? I’m not sure what the best pattern is for this. You can put the relevant docs in your prompt, add them to a workspace/project, deploy a docs-focused MCP server, or even fine-tune a model for a specific tool or ecosystem.

> I’m not sure what the best pattern is for this.

> You can put the relevant docs in your prompt

I've done a lot of experimenting with these various options for how to get the LLM to reference docs. IMO it's almost always best to include in prompt where appropriate.

For a UI lib that I use that's rather new, specifically there's a new version that the LLMs aren't aware of yet, I had the LLM write me a quick python script that just crawls the docs site for the lib and feeds the entire page content back into itself with a prompt describing what it's supposed to do (basically telling it to generate a .md document with the specifics about that thing, whether it's a component or whatever, ie: properties, variants, etc in an extremely brief manner) as well as build an 'index.md' that includes a short paragraph about what the library is and a list of each component/page document that is generated. So in about 60 seconds it spits out a directory full of .md files and I then tell my project-specific LLM (ie: Claude Code or Opencode within the project) to review those files with the intention of updating the CLAUDE.md in the project to instruct that any time we're building UI elements we should refer to the index.md for the library to understand what components are available and when appropriate to use one of them we _must_ review the correlating document first.

Works very very very well. Much better than an MCP server specifically built for that same lib. (Huge waste of tokens, LLM doesn't always use it, etc) Well enough that I just copy/paste this directory of docs into my active projects using that library - if I wasn't lazy I'd package it up but too busy building stuff.

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

#192

Post by lossolo »

motorest wrote: post #156
lemagedurage wrote: post #145

Earlier quoted context omitted.

The main issue is that a reader might mistake Redis as a 2X faster postgres. Memory is 1000X faster than disk (SSD) and with network overhead Redis can still be 100X as fast as postgres for caching workloads. Otherwise, the article does well to show that we can get a lot of baseline performance either way. Sometimes a cache is premature optimisation.

> The main issue is that a reader might mistake Redis as a 2X faster postgres. Memory is 1000X faster than disk (SSD) and with network overhead Redis can still be 100X as fast as postgres for caching workloads. Your comments suggest that you are definitely missing some key insights onto the topic. If you, like the whole world, consume Redis through a network connection, it should be obvious to you that network is in…

> If you, like the whole world, consume Redis through a network connection

I think "you are definitely missing some key insights onto the topic". The whole world is a lot bigger than your anecdotes.

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

#193

Post by bhaak »

I’m surprised to see this being somewhat controversial.

In Rails we just got database backed everything with the option to go to special backends if need be.

The only question I have is how do I notice that my current backend doesn’t scale anymore and who or what would tell me to switch.

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

#194

Post by didntcheck »

motorest wrote: post #152
smacker wrote: post #141

I like using postgres for everything, it lets me simplify infrastructure. But using it as a cache is a bit concerning in terms of reliability, in my opinion. I have witnessed many incidents when DB was considerably degrading. However, thanks to the cache in redis/memcache, a large part of the requests could still be processed with minimal increase in latency. If I were serving cache from the same DB instance, I guess…

> But using it as a cache is a bit concerning in terms of reliability, in my opinion. This was the very first time I heard anyone even suggest that storing data in Postgres was a concern in terms of reliability, and I doubt you are the only person in the whole world who has access to critical insight onto the matter. Is it possible that your prior beliefs are unsound and unsubstantiated? > I have witnessed many incid…

> This was the very first time I heard anyone even suggest that storing data in Postgres was a concern in terms of reliability

You seem to be reading "reliability" as "durability", when I believe the parent post meant "availability" in this context

> Do you actually have any concrete scenario in mind? Because anyone can make any system "considerably degrading", even Redis

And even Postgres. It can also happen due to seemingly random events like unusual load or network issues. What do you find outlandish about the scenario of a database server being unavailable/degraded and the cache service not being?

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

#195

Post by lomase »

ralegh wrote: post #172
motorest wrote: post #146

Earlier quoted context omitted.

> "If we don't need performance, we don't need caches" feels like a great broader takeaway here. I don't think this holds true. Caches are used for reasons other than performance. For example, caches are used in some scenarios for stampede protection to mitigate DoS attacks. Also, the impact of caches on performance is sometimes negative. With distributed caching, each match and put require a network request. Even wh…

DoS is a performance problem, if your server was infinitely fast with infinite storage they wouldnt be an issue.

If my gandma had wheels it would be a car.

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

#196

Post by Implicated »

motorest wrote: post #156
lemagedurage wrote: post #145

Earlier quoted context omitted.

The main issue is that a reader might mistake Redis as a 2X faster postgres. Memory is 1000X faster than disk (SSD) and with network overhead Redis can still be 100X as fast as postgres for caching workloads. Otherwise, the article does well to show that we can get a lot of baseline performance either way. Sometimes a cache is premature optimisation.

> The main issue is that a reader might mistake Redis as a 2X faster postgres. Memory is 1000X faster than disk (SSD) and with network overhead Redis can still be 100X as fast as postgres for caching workloads. Your comments suggest that you are definitely missing some key insights onto the topic. If you, like the whole world, consume Redis through a network connection, it should be obvious to you that network is in…

> If you, like the whole world, consume Redis through a network connection, it should be obvious to you that network is in fact the bottleneck.

Not to be annoying - but... what?

I specifically _do not_ use Redis over a network. It's wildly fast. High volume data ingest use case - lots and lots of parallel queue workers. The database is over the network, Redis is local (socket). Yes, this means that each server running these workers has its own cache - that's fine, I'm using the cache for absolutely insane speed and I'm not caching huge objects of data. I don't persist it to disk, I don't care (well, it's not a big deal) if I lose the data - it'll rehydrate in such a case.

Try it some time, it's fun.

> And at the end of the day, what exactly is the performance tradeoff? And does it pay off to spend more on an in-memory cache like Redis to buy you the performance Delta?

Yes, yes it is.

> That's why real world benchmarks like this one are important.

That's not what this is though. Just about nobody who has a clue is using default configurations for things like PG or Redis.

> They help people think through the problem and reassess their irrational beliefs.

Ok but... um... you just stated that "the whole world" consumes redis through a network connection. (Which, IMO, is wrong tool for the job - sure it will work, but that's not where/how Redis shines)

> What you cannot refute are the real world numbers.

Where? This article is not that.

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

#197

Post by lomase »

simonw wrote: post #180
Timshel wrote: post #132

Earlier quoted context omitted.

> for only about five minutes of LLM query or web search I think I have more trust in the PG defaults that in the output of a LLM or copy pasting some configuration I might not really understand ...

So run the LLM in an agent loop: give it a benchmarking tool, let it edit the configuration and tell it to tweak the settings and measure and see how much if a performance improvement it can get. That's what you'd do by hand if you were optimizing, so save some time and point Claude Code or Codex CLI or GitHub Copilot at it and see what happens.

How much that would cost?

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

#198

Post by Implicated »

lelanthran wrote: post #149
m000 wrote: post #125

Earlier quoted context omitted.

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.

> The use case is not representative of a real-life scenario, so the value of the presented results are minimal. Maybe I'm reading the article wrong, but it is representative of any application that uses a PosgreSQL server for data, correct? In what way is that not a real-life scenario? I've deployed Single monolith + PostgreSQL to about 8 different clients in the last 2.5 years. It's my largest source of income.

> I've deployed Single monolith + PostgreSQL to about 8 different clients in the last 2.5 years. It's my largest source of income.

And... do you do that with the default configuration?

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

#199

Post by lomase »

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.

This site is called Hackernews btw.

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

#200

Post by IgorPartola »

simonw wrote: post #180
Timshel wrote: post #132

Earlier quoted context omitted.

> for only about five minutes of LLM query or web search I think I have more trust in the PG defaults that in the output of a LLM or copy pasting some configuration I might not really understand ...

So run the LLM in an agent loop: give it a benchmarking tool, let it edit the configuration and tell it to tweak the settings and measure and see how much if a performance improvement it can get. That's what you'd do by hand if you were optimizing, so save some time and point Claude Code or Codex CLI or GitHub Copilot at it and see what happens.

“We will take all the strokes off Jerry's game when we kill him.” - the LLM, probably.

Just like Mr Meeseeks, it’s only a matter of time before it realizes that deleting all the data will make the DB lightning fast.

Post reply on HN