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.

▲

pigbearpig an hour ago | parent | next [-]

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.

	▲	themgt 4 minutes ago \| parent [-]
		There's also a sort of anti-everything attitude that gets boring and lazy. Redis is about the simplest thing possible to deploy. This wasn't about "a redis cluster with elastisearch using an LLM" it was just Redis. 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.

▲

phiresky 5 hours ago | parent | prev | next [-]

If your cache fits in Redis then it fits in RAM, if your cache fits in RAM then Postgres will serve it from RAM just as well.

Writes will go to RAM as well if you have synchronous=off.

▲

senorrib 4 hours ago | parent [-]

Not necessarily true. If you're sharing the database with your transaction workload your cache will be paged out eventually.

	▲	jgalt212 3 hours ago \| parent [-]
		This was my take as well, but I'm a MySQL / Redis shop. I really have no idea what tables MySQL has in RAM at any given moment, but with Redis I know what's in RAM.

▲

motorest 5 hours ago | parent | prev [-]

> 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 fact the bottleneck.

Furthermore, using a RDBMS like Postgres may indeed imply storing data in a slower memory. However, you are ignoring the obvious fact that a service such as Postgres also has its own memory cache, and some query results can and are indeed fetched from RAM. Thus it's not like each and every single query forces a disk read.

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?

That's why real world benchmarks like this one are important. They help people think through the problem and reassess their irrational beliefs. You may nitpick about setup and configuration and test patterns and choice of libraries. What you cannot refute are the real world numbers. You may argue they could be better if this and that, but the real world numbers are still there.

	▲	Implicated 2 hours ago \| parent \| next [-]
		> 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.
	▲	lossolo 2 hours ago \| parent \| prev [-]
		> 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.