11–20 of 311 posts
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
I think you just convinced me to drop redis for my new project. Definitely a premature optimization on my part.
“Dropping” something from a “new” project is premature optimization? Wherever you go, there you are.
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…
Don't tell DHH
I think you just convinced me to drop redis for my new project. Definitely a premature optimization on my part.
Is redis not improving your latency? Is it adding complexity that isn’t worth it? Why bother removing it?
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.
If your cache is so performance critical that you can't lose the data then it sounds like you need a (denormalized) database.
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…
Of course such sensitive environments are easily imaginable but I wonder why you'd select either in that case.
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…
When you benchmarked Postgres did you disable WAL for the cache table? That may minimize the difference.