Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

martinheinz.dev

Post reply on HN
Print view View original

71–80 of 82 posts

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

#71

Post by thunky »

mrd3v0 wrote: post #45
luibelgo wrote: post #39

Earlier quoted context omitted.

Not super constructive either, the beauty of having things like HN is to be able to discuss ideas, rather than just point to them as wrong. At least a couple of counterpoints on why this would be a bad idea and offer a better approach.

There are way more terrible ideas than good ones, and that means treating all of them equally is a one-way road to HN losing the one thing it has going: new ideas. Feedback like root comment is important to keep pushing ideas forward, instead of a loop.

> Feedback like root comment

What feedback? All I see is someone smelling their own farts.

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

#72

Post by macNchz »

lnxg33k1 wrote: post #68
mbreese wrote: post #67

Earlier quoted context omitted.

I see this as an issue of scale. HN loves to think about infinite scales where there are millions of simultaneous users of systems. This is rarely the case. Caching in Postgres is for smaller scale applications where the extra complexity of a dedicated memory cache isn’t worth the extra overhead. But at least you bring up some actual limits that should to be considered. DB load: part of the load on a DB is the networ…

I mean if you have a light application then maybe you dont even need the cache, at a certain threshold of small you can go ahead with sqlite or access, or excel, of course HN has an issue of scaling, because if we talk about caching then lets talk about situations where talking about caching makes sense,

Caching can make sense in more situations than "too many users running the same query at once". For basically anything slow that you'd like to make faster, you can weigh the downsides of caching against the downsides of optimizing its performance in other ways. In a startup context, often some (judicious) caching is preferable to spending a bunch of time carefully optimizing some code that's going to change or be thrown out in a month anyway.

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

#73

Post by drewda »

0xbadcafebee wrote: post #32

Sometimes I feel like the articles posted here are elaborate trolls. Like they wanted to know what the purpose of a cache is and how/when to implement one, but they didn't want to do research, so they came up with the worst idea they could imagine and blogged about it, hoping someone on HN would tell them the right way (or just laughing at people trying to correct them). It gives me anxiety how much truly awful advic…

Many of the technical blog posts that are most up-voted here on HN would be best described as content marketing. That the posts describe something technical is almost incidental to the point of making you aware that the company writing the post exists.

HN eats up all sorts of these posts from companies selling backend-as-a-service, low-code-web-UI-as-a-service, unreliable-replacement-for-Heroku's-free-tier-as-a-service, and so on...

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

#74

Post by koliber »

osigurdson wrote: post #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.

I like the idea of "defining the edges of suitability." Just because you can use it, does not mean you should.

I lean towards fewer tools. Postgres is an awesome swiss army knife. In some cases, using it as a key-value store, a cache, or a messaging queue are fine. In other cases, they're not.

Examine how suitable this particular tool is for your particular use case and your particular requirements.

Maybe you have zero DevOps skills, a background in DB administration, and your cache backs an external API. Perhaps using postgres is the right solution.

Maybe you know enough about databases to be dangerous, but feel comfortable managing virtual clouds environments. Perhaps DynamoDB or a Redis instance is the way to go.

There is no one answer. However, often there is a good default answer.

P.S. The default answer changes over time. There's always the flavor-of-the-year. The technology landscape is also constantly shifting. My heuristic is to use lean towards the default answer that has been around the longest.

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

#75

Post by moltar »

lnxg33k1 wrote: post #63
macNchz wrote: post #61

Earlier quoted context omitted.

Do you have specific criticisms? There are myriad and varied different use cases for a cache. I’ve used Postgres in a pinch. It’s fine, for certain things. I’ve used a lot of other caches as well that would be highly inappropriate for the situations I’ve used Postgres in. In my experience there are far more highly-overwrought bloated architectures deployed than there are overly-clever minimalist ones. Everyone wants…

So for one we do cache to remove load from dbms, then makes a lot of sense to remove load from dbms by giving it the load of cache too, another thing might be that separate services might be optimised for different tasks, redis is built with being first class in memory cache service, postgres is built with different first-class usage in mind, another one I can think of is resources, I can scale redis and dbms indepen…

What if you are removing load from loading data from a network bound third party API which you need to cache locally?

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

#76

Post by koliber »

techscruggs wrote: post #9

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…

In general, caches need to be fast. However, the Solid Cache article you linked says:

> On Basecamp, compared to our old Redis cache, reads are now about 40% slower. But the cache is 6 times larger, and running on storage that’s 80% cheaper.

It seems that their caching needs don't require the speed that Redis provides. Instead, they can get an overall performance improvement in their application if they cache more things -- that's why they want a bigger cache.

Based on this, it seems that Redis was too fast and too expensive. Being self-aware of your needs is key. This way, BaseCamp could tailor a solution that suits their needs.

You don't always need the fastest, the biggest, the most scalable, or the cheapest. If you know the thresholds, you can come up with a better tradeoff.

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

#77

Post by paulmd »

VWWHFSfQ wrote: post #30
antoineleclair wrote: post #29

For projects where I know the team will remain small (less than let's say 15 developers), I usually push to keep the architecture as simple as possible. I've used something similar in the past, but kept the expiration code in the app code (Python) instead of using "fancy" Postgres features, like stored procedures. It's much easier to maintain since most developers will know how to read and maintain the Python code, t…

> Let's say you compute a value inside a transaction, cache it in Redis, and then the transaction fails. That just sounds like an application bug. Nothing should be done with the query result anyway until the transaction either completes our rolls back.

As mentioned this is a distributed system though, and realistically most micro services etc aren’t being fully rigorous about multi-phase transactionality and proper rollbacks etc.

Realistically it is the norm to yolo updates at a service and if it fails then the whole thing 500s and things are just in an unexpected state. Often it is not even possible to guarantee successful rollback etc - if your update back to original state fails then what is the application state now? Undefined and potentially invalid, pretty much. Most people just replay the request again and hope it succeeds.

Obviously the right answer is “don’t do that” or “offload that complexity into graphQL or something” but in the real world… people don’t.

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

#78

Post by sidcool »

The explanation is not convincing enough. Good to know info but I can't see this useful for a large scale production system. There is no description of cache invalidation strategies.

But it's highly voted on HN so may be I am missing something.

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

#79

Post by gembeMx »

0xbadcafebee wrote: post #32

Sometimes I feel like the articles posted here are elaborate trolls. Like they wanted to know what the purpose of a cache is and how/when to implement one, but they didn't want to do research, so they came up with the worst idea they could imagine and blogged about it, hoping someone on HN would tell them the right way (or just laughing at people trying to correct them). It gives me anxiety how much truly awful advic…

It’s most “articles” shared on here these days, low effort gunk

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

#80

Post by osigurdson »

koliber wrote: post #74
osigurdson wrote: post #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.

I like the idea of "defining the edges of suitability." Just because you can use it, does not mean you should. I lean towards fewer tools. Postgres is an awesome swiss army knife. In some cases, using it as a key-value store, a cache, or a messaging queue are fine. In other cases, they're not. Examine how suitable this particular tool is for your particular use case and your particular requirements. Maybe you have ze…

I can say, using pg as a time series database works completely fine for < 1B rows. If you have significantly more than that, it is a good idea to start thinking about alternatives.
Post reply on HN