[wewewedxfgdf]

"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.

[fabian2k]

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.

[macspoofing]

>I personally wouldn't like to put caching in Postgres, even though it would work at lower scales.

Probably should stop after this line - that was the point of the article. It will work at lower scales. Optimize later when you actually know what to optimize.

[fabian2k]

My point is more that at that scale I'd try to avoid caching entirely. Unless you're doing analytical queries over large tables, Postgres is plenty fast without caching if you're not doing anything stupid.

[noirscape]

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.

[jeroenhd]

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.

[vlovich123]

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

[wewewedxfgdf]

Ha ha nice one - when your startup is Facebook you'll need that, not for your 12 users.

The reason startups get to their super kubernetes 6 layers mega AWS powered ultra cached hyper pipelined ultra optimised web queued applicatyion with no users is because "but technology X has support for an eventually consistent in-memory caching layer!!"

What about when we launch and hit the front page of HN how will the site stay up without "an eventually consistent in-memory caching layer"?

[yencabulator]

Why would it need to be eventually consistent when it's a single server?

https://www.postgresql.org/docs/18/sql-createtable.html#SQL-...

[PretzelJudge]

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.

[fabian2k]

Postgres itself has no issue with 1000 simple requests per second. On normal notebook hardware you'll get easily several thousand requests per second if you're just looking up small amounts of data by the primary key. And that is without any optimization and with non-DB overhead included. The actual performance you can get is probably quite a bit higher, but I've seen ~4-6k requests per second on naive, unoptimized endpoints that just look up some data in Postgres.

[giantrobot]

> Postgres itself has no issue with 1000 simple requests per second

Postgres in isolation has no problem with 1000 RPS. But does your Postgres server have that ability? Your server is also handling more complex requests and maybe some writes and concurrent re-indexing.

[dv_dt]

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

[tclancy]

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.

[xnorswap]

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.

[willvarfar]

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?

[douglee650]

"Why is Redis talking to MongoDB?"

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

[rf15]

oh it is, look again.

[CommonGuy]

Or do not use caching at all until you need it

[simpleas987]

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