You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)
1–10 of 82 posts
Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)
#2[deleted]
Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)
#3Systems 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.
Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)
#4> 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)
#5It’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 rest of the application (reading/writing to this cache consumes cpu and IO).
Also, missing an index on the inserted_at and there’s no uniqueness constraint on the key.
Overall, it reads like someone read about UNLOGGED and thought it could be useful for caching use cases. I don’t think anyone doubted that PG can be used a cache really, the trade offs would be a more interesting read than the POC
Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)
#6at a previous gig, we put a Redis cache in front of a slow monolithic Microsoft SQL Server db
that gave us breathing room to migrate the data we were interested in into a much smaller dedicated db for our purposes (the user data, used on every login and other operation in the system)
in a correctly specced RDS, MySQL can be set up to store all the data both in memory and on disk (note, I'm not referring to the ephemeral disk only db engine, I'm referring to giving the RDS the correct memory settings and parameters to store all the data both in memory and on disk)
once we did that, there was no difference in read speed between the Redis and just hitting the db, so we got rid of the Redis, which vastly simplified the architecture of the user service
= the article title is true, caching is often understood to be a default requirement but it kind of isn't if you architect things correctly
Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)
#7> Benchmarking and comparing UNLOGGED tables against Memcached or Redis is out-of-scope of this article
Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)
#8Before 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)
#9This 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 aren't as fast for most of us that leverage "the cloud".
Sure, you can do it, but why? I am all for removing complexities in my infrastructure. That said, Memcached and/or Redis are both rock solid and dead simple.
This just seems to be a waist of time 99.999% of use cases.
Re: You Don't Need a Dedicated Cache Service – PostgreSQL as a Cache (2023)
#10> Benchmarking and comparing UNLOGGED tables against Memcached or Redis is out-of-scope of this article That’s the interesting part…
yeah exactly - write isnt generally the concern, its the read that makes or breaks a cache...