Live data from Hacker News

You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)

martinheinz.dev

11–20 of 82 posts

Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)

#12
All "Postgres as an X" are valid to a point. If your use case doesn't require anything else and you prefer to build / test / maintain dedicated (a little snowflakey probably) logic, fine. Unfortunately, few such articles discuss the edges at which these solutions no longer work.

Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)

#14

It’s a weird article. It claims that one only needs Postgres but then presents a half-baked solution: the takeaway I got is “it’s not HA or horizontally scalable, and it’s probably slow” so it sounds like I _do_ need a dedicated cache service? They just handwave benchmarking against cache databases as “out of scope”, that is very much in scope to claim I can use PG rather than redis. Also a cache would impact the res…

[deleted]

Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)

#16

Systems that are used as cache such as redis evict keys with some randomness to avoid scanning all of them. They also evict keys you read that expired without you having to check for that. And they don't store both a key and an id. Given the value of redis for caching and outside of caching, bur the ease and low cost of setting it up, I would say postgres as a cache seems niche.

Postgres doesn't need to scan them all because it has indexes. It also has a number of random sampling strategies available.

It is niche, but it's a viable option for a lot of use cases if you need to limit the number of service dependencies.

Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)

#17

This appears to be riding the [Solid Cache]( https://dev.37signals.com/solid-cache/ ) idea that DHH has started espousing. At the core of this idea is that SSD's are sufficiently fast for caching. Sure, this may work for 37signals, but that is because they manage their own hardware. That is the exception and not the rule. And, per [this discussion two weeks ago]( https://news.ycombinator.com/item?id=39443679 ). SSD's…

> Sure, you can do it, but why?

Re. Solid cache they effectively answered this in the post. The cost is less meaning they can cache more so p95 response time goes down. If you're not constrained my money you can just buy a bigger memcached or Redis of course.

If you're talking about moving things to Postgres /in general/, then cost and/or complexity are compelling reasons to do so. Small engineering teams, small budgets, simplifying and reducing cost can really help. Obviously it's not suitable for everyone but it's nice to have the option.

Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)

#18
You almost always don't need a specialized or dedicated (blank). You can usually get away with using some boring off the shelf tech that can do the job, even if it isn't doing the job as perfectly as a dedicated (blank). Any additional cost in resources is probably offset by the savings in cognitive load and admin hours.

If you do, you're probably operating at a scale at which you have a whole big devops team to figure out, deploy, and manage your dedicated (blank). Or if you're really huge, you might be creating your dedicated (blank) in a way that's custom engineered around your problem.

Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)

#19

All "Postgres as an X" are valid to a point. If your use case doesn't require anything else and you prefer to build / test / maintain dedicated (a little snowflakey probably) logic, fine. Unfortunately, few such articles discuss the edges at which these solutions no longer work.

Do you mean just in general, or are there known edge cases where Postgres performs poorly as a cache?

Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)

#20
Calling Postgres experts:

Why, exactly, do we need to put a memory cache such as Redis in front of Postgres? Postgres has its own in-memory cache that it updates on reads and writes, right? What makes Postgres' cache so much worse than a dedicated Redis?

Post reply on HN