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

Redis is fast – I'll cache in Postgres

dizzy.zone

Post reply on HN
Print view View original

21–30 of 311 posts

Re: Redis is fast – I'll cache in Postgres

#21

Post by arp242 »

xyzzy_plugh wrote: post #19
arp242 wrote: post #4

When I last benchmarked Redis vs. PostgreSQL for a simple k/v cache it was about ~1ms for PostgreSQL to fetch a key, and ~0.5ms for Redis with a similar setup as in this post (although I used "value bytea" instead of "value string" – I don't know if it matters, probably not; 1ms was fast enough that I didn't care to test). I didn't measure setting keys or req/sec because for my use case keys were updated infrequently…

A difference of 0.5ms is negligible with single digit network latency. You would need significant batching to experience the effects of this difference. Of course such sensitive environments are easily imaginable but I wonder why you'd select either in that case.

> A difference of 0.5ms is negligible with single digit network latency

Yes, that was my take-away.

Re: Redis is fast – I'll cache in Postgres

#23

Post by cortesoft »

Having the ability to set a TTL on the cache key is a critical feature of a cache, not something that can be tacked on later.

I always find these "don't use redis" posts kind of strange. Redis is so simple to operate at any scale, I don't quite get why it is important to remove it.

Re: Redis is fast – I'll cache in Postgres

#24

Post by aaronblohowiak »

iamcalledrob wrote: post #3

This isn't a great test setup. It's testing RTT rather than the peak throughput of Redis. I'd suggest using Redis pipelining -- or better: using the excellent rueidis redis client which performs auto-pipelining. Wouldn't be surprising to see a 10x performance boost. https://github.com/redis/rueidis

Even so 35ms+ latency for Redis reads is very very high I’d want to understand what is happening there

Re: Redis is fast – I'll cache in Postgres

#25

Post by Fire-Dragon-DoL »

firecall wrote: post #22
Fire-Dragon-DoL wrote: post #15

Earlier quoted context omitted.

Didn't DHH just release a sqlite-only cache?

Solid Cache, default in Rails 8. Doesn’t require SQLite. Works with other DBs: https://github.com/rails/solid_cache

Yeah,so no redis

Re: Redis is fast – I'll cache in Postgres

#26

Post by maxbond »

MobiusHorizons wrote: post #16
mehphp wrote: post #7

I think you just convinced me to drop redis for my new project. Definitely a premature optimization on my part.

“Premature optimization” typically refers to optimizing before profiling. Ie optimizing in places that won’t help. Is redis not improving your latency? Is it adding complexity that isn’t worth it? Why bother removing it?

I like to call cases like this "premature distribution." Or maybe you could call it "premature capacity." If you have an application running in the cloud with several thousand requests per day, you could probably really benefit from adding a service like Redis.

But when you have 0-10 users and 0-1000 requests per day, it can make more sense to write something more monolithic and with limited scalability. Eg, doing everything in Postgres. Caching is especially amenable to adding in later. If you get too far into the weeds managing services and creating scalability you might bogged down and never get your application in front of potential users in the first place.

Eg, your UX sucks and key features aren't implemented, but you're tweaking TTLs and getting a Redis cluster to work inside Docker Compose. Is that a good use of your time? If your goal is to get a functional app in front of potential users, probably not.

Re: Redis is fast – I'll cache in Postgres

#27

Post by frollogaston »

cortesoft wrote: post #23

Having the ability to set a TTL on the cache key is a critical feature of a cache, not something that can be tacked on later. I always find these "don't use redis" posts kind of strange. Redis is so simple to operate at any scale, I don't quite get why it is important to remove it.

Yeah, the article was like "I always need a DB anyway" but then sets up an extra cronjob to expire keys, plus more code. I get YAGNI and avoiding deps, but this is really extra stuff to deal with.

Maybe Postgres could use a caching feature. Until then, I'm gonna drop in Redis or memcached instead of reinventing the wheel.

Re: Redis is fast – I'll cache in Postgres

#28

Post by akdor1154 »

cortesoft wrote: post #23

Having the ability to set a TTL on the cache key is a critical feature of a cache, not something that can be tacked on later. I always find these "don't use redis" posts kind of strange. Redis is so simple to operate at any scale, I don't quite get why it is important to remove it.

It's not like it's bad, it's more like cutting down on the amount of systems you need to operate.

Re: Redis is fast – I'll cache in Postgres

#29

Post by frollogaston »

sixo wrote: post #14

If you use an UNLOGGED table in Postgres as a cache, and your DB restarts, you no longer have a cache. Then your main table gets a huge spike in traffic and likely grinds to a halt.

Cache isn't meant to persist, and something is wrong if you hard depend on it persisting.

Re: Redis is fast – I'll cache in Postgres

#30

Post by dizzyVik »

iamcalledrob wrote: post #3

This isn't a great test setup. It's testing RTT rather than the peak throughput of Redis. I'd suggest using Redis pipelining -- or better: using the excellent rueidis redis client which performs auto-pipelining. Wouldn't be surprising to see a 10x performance boost. https://github.com/redis/rueidis

Author here. Redis is definitely faster. I was specifically not going for absolute peak performance for either redis or postgres - that would require going down to the wire protocols. The idea was emphasize that there' a "good enough" level of performance. Once you need that sort of speed - sure, there are ways to achieve it.
Post reply on HN