You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)
11–20 of 82 posts
Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)
#12Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)
#13> Benchmarking and comparing UNLOGGED tables against Memcached or Redis is out-of-scope of this article That’s the interesting part…
Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)
#14It’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…
Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)
#15Before reading the article I thought they author would talk about caching the query results automatically, which most DBs do that.
Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)
#16Systems 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.
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)
#17This 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…
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)
#18If 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)
#19All "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)
#20Why, 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?