"Maybe Redis for caching".

Really that's going way too far - you do NOT need Redis for caching. Just put it in Postgres. Why go to this much trouble to put people in their place for over engineering then concede "maybe Redis for caching" when this is absolutely something you can do in Postgres. The author clearly cannot stop their own inner desire for overengineering.

I personally wouldn't like to put caching in Postgres, even though it would work at lower scales. But at that scale I don't really need caching anyway. Having the ephemeral data in a different system is more appealing to me as well.

The caching abstractions your frameworks have are also likely designed with something like Redis in mind and work with it out of the box. And often you can just start with an in-memory cache and add Redis later, if you need it.

A cache can help even for small stuff if there's something time-consuming to do on a small server.

Redis/valkey is definitely overkill though. A slightly modified memcached config (only so it accepts larger keys; server responses larger than 1MB aren't always avoidable) is a far simpler solution that provides 99% of what you need in practice. Unlike redis/valkey, it's also explicitly a volatile cache that can't do persistence, meaning you are disincentivized from bad software design patterns where the cache becomes state your application assumes any level of consistency of (including it's existence). If you aren't serving millions of users, stateful cache is a pattern best avoided.

DB caches aren't very good mostly because of speed; they have to read from the filesystem (and have network overhead), while a cache reads from memory and can often just live on the same server as the rest of the service.

Redis is the filler you shove in there when Postgres itself starts slowing down. Writing database queries that work and writing database queries that work efficiently are very different things.

It'll give you time to redesign and rebuild so Postgres is fast enough again. Then you can take Redis out, but once you've set it up you may as well keep it running just in case.

Postgres has support for an eventually consistent in-memory caching layer?

The sentiment here is right, but redis does make a difference at scale. I built a web app this year on AWS lambda that had up to 1000/requests/second and at that scale, you can have trouble with Postgres, but redis handles it like it’s nothing.

I think that redis is a reasonable exception to the rule of ”don’t complicate things” because it’s so simple. Even if you have never used it before, it takes a few minutes to setup and it’s very easy to reason about, unlike mongodb or Kafka or k8s.

Imho, if you can, use a fixed chunk of server memory directly for cache. That scales out with instances if/when you ever scale out

Because they’re meeting the patients at their own level. Plus while using PG for everything is a currently popular meme on HN (and I am all for it), it’s not something you see all that often. An app server, a database and a cache is a pretty sensible and simple starting point.

Until you get to 100 test users. Then you need Kafka and k8.

That seemed odd to me too, they're talking about single server, which to me would mean running postgres on the application server itself.

In that scenario, the last thing you need is another layer between application and database.

Even in a distributed environment, you can scale pretty far with direct-to-database as you say.

Sometimes you have to pick your poison when those with other agendas or just inexperience want to complicate things. Conceding that they can use Redis somehow might be enough to get them to stop blaming you for the 'out of date' architecture?

"Why is Redis talking to MongoDB?"

lol, In the diagram, Redis is not even talking with MongoDB

Or do not use caching at all until you need it

just use the filesystem, it's superfast and reliable.