221–230 of 311 posts
Earlier quoted context omitted.
Select by id is fast. If you’re using it as a cache and not doing select by id then it’s not a cache.
absolutely. But when PG is running out of open connections or has already consumed all available CPU even the simplest query will struggle.
Earlier quoted context omitted.
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.
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?
We can't get rid of Postgres, but since we run Postgres on GCP we really never even think about it.
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.
One thing that I think has gotten lost in the "I need redundant redundancy for my redundantly redundant replicas of my redundantly-distributed resources" world is that you really only need all that for super-real-time systems. Which a lot of things are, such as, all user-facing websites need to be up the moment the user hits them and not 30 seconds later. But when you don't have that constraint, if things can take an extra few minutes or drop some requests and it's not a big deal, you can get away with something a lot cheaper, made even more cheap by the fact that running things on a single node gets you access to a lot of performance you simply can not have in a distributed system because nothing is as fast as the RAM bus being accessed by a single OS process. And sometimes you have enough flexibility to design your system to be that way in the first place instead of accidentally wiring it up to be dependent on complicated redundancy schemes.
(Next up after that, if that isn't enough, is the system where you have redundant nodes but you make sure they don't need to cross-talk at all with something like Redis. Observation: If you have two nodes for redundancy, and they are doing something with caching, and the cached values are generally stable for long periods of time, it is often not that big a deal just to let each node have its own in-memory cache and if they happen to recreate a value twice, let them. If you work the math out carefully, depending on your cache utilization profile you often are losing less than you think here (in particular, if the modal result is that you never hit a given cached value again, it's cheap especially if the ones you hit you end up hitting a lot, and if on average you get cached values all the time, the amortized cost of the second computation is nearly nothing, it's only in the "almost always hit them 2 or 3 times" case that this incurs extra expense and that's actually a very, very specific place in the caching landscape), especially since the in-process caching and such is faster on its own terms too which mitigates the problem, especially because you can set it up so you have no serialization costs in this case, and the architectural simplicity can be very beneficial. No, by no means does this work with every system, and it is helpful to scan out into the future to be sure you probably won't ever need to upgrade to a more complicated setup, but there's a lot of redundantly redundant systems that really don't need to be written with such complication because this would have been fine for them.)
This is totally misguided and incorrect.
Redis can be easily deployed such that any request returns in less than a millisecond, and this is where it's most useful. It's also consistent and stable as hell. There are many use-cases for Redis where Postgres is totally unsuitable and doesn't make sense, and vice versa.
Do yourself a favour and ignore this blog (again: inaccurate, poorly benchmarked, misleading) and do your own research and use better sources of information.
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.
That's the reader's fault then. I see the blog post as the counter to the insane resume-building over-engineered architecture you see at a lot of non-tech companies. Oh, you need a cache for our 25-user internal web application? Let's put an front a redis cluster with elastisearch using an LLM to publish cache invalidation with Kafka.
I sometimes read this stuff like people explaining how they replaced their spoon and fork with a spork and measured only a 50% decrease in food eating performance. And have you heard of the people with a $20,000 Parisian cutlery set to eat McDonalds? I just can't understand insane fork enjoyers with their over-engineered their dining experience.
Earlier quoted context omitted.
If you are going to ask ChatGPT some specific tidbit it's better to force it to search on the web. Remember, an LLM is a JPG of all the text of the internet.
Wait, what? Isn't that the whole point, to ask it specific tidbits of information? Are we to ask it large, generic pontifications and claim success when we get large, generic pontifications back? The narrative around these things changes weekly.
You can see if it's used search in the interface, which helps evaluate how likely it is to get the right answer.
Earlier quoted context omitted.
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?
I run a pricing calculator here - for 50,000 input tokens, 5,000 output tokens (which I estimate would be about right for a PostgreSQL optimization loop) GPT-5 would cost 11.25 cents: https://www.llm-prices.com/#it=50000&ot=5000&ic=1.25&oc=10
I use Codex CLI with my $20/month ChatGPT account and so far I've not hit the limit with it despite running things like this multiple times a day.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
How much that would cost?
Probably about 10 cents, if you're even paying for tokens. Plenty of these tools have generous free tiers or allowances included in your subscription. I run a pricing calculator here - for 50,000 input tokens, 5,000 output tokens (which I estimate would be about right for a PostgreSQL optimization loop) GPT-5 would cost 11.25 cents: https://www.llm-prices.com/#it=50000&ot=5000&ic=1.25&oc=10 I use Codex CLI with my $2…
If that is true in some months there will be no dba jobs.
Funny that at the same time SQL is one of the most requested languages in job postings.
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. 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 runnin…