zlacker

As German engineers are known to say: "Why make things simple when complicated will do?"

>>arpa+(OP)
If you already have Postgres in your project and now you get the requirement for an additional cache store, I think it will be less complicated to reuse what you already have instead of adding another DB to your stack.

Of course, at some point of scaling needs a dedicated cache store will make sense anyway.

(Just some justifications from a german engineer :) )

>>Fannon+h
True. However, since cache is usually transient, adding this key-value store/cache is as easy as "docker run redis". No need to provision block storage, and it's really lightweight in comparison.

(that being said, I try really hard not to judge; after all, i'm not without fault: it's 2021 and i'm using bash over cgi-bin to serve web pages for my own hobby projects :))) )

>>Fannon+h
Redis as a cache server requires different settings from redis as a job queue. So you can’t reuse the same server anyway.

>>arpa+(OP)
> As German engineers are known to say: "Why make things simple when complicated will do?"

Isn't Redis an in-memory key/value store? Paying for RAM is not the same as paying for SSD.

>>arpa+v1
> True. However, since cache is usually transient, adding this key-value store/cache is as easy as "docker run redis". No need to provision block storage, and it's really lightweight in comparison.

If you're using postgres for caching only, as you do Redis, then you also do not need to provision block storage.

If you happen to already have Postgres running for other uses, you also do not need to provision block storage.

Finally, I would add that Redis clients such as Redisson are resource hogs that cause performance problems on apps, while pg clients are barely noticeable.

>>rualca+o6
There's Redis-compatible alternatives that use disk space instead of RAM.

https://wakatime.com/blog/45-using-a-diskbased-redis-clone-t...