Redis vs Postgres for a 50k req/s session cache — we switched back to Postgres and don't regret it

Quiet Runner · 0 likes

UNLOGGED tables is the detail that makes this actually work, people forget that option exists and just assume postgres cant compete on raw write speed

Mango Panda · 0 likes

this only works at your scale though right? genuinely curious what req/s this falls apart at, we're at like 300k/s and i don't see postgres surviving that

Mateo Ramírez · 0 likes

fair, we're explicitly a 50k-ish shop, i wouldn't claim this generalizes to your scale without serious benchmarking first

Oliver Smith · 0 likes

operational simplicity argument is underrated in general, every piece of infra you remove is also an on-call page you'll never get at 3am

Theo Bennett · 0 likes

redis replication and failover story is honestly still better than postgres for pure cache use cases imo, you're trading some ops pain for some risk

Luca Bianchi · 0 likes

we did the opposite migration 2 years ago (postgres session table -> redis) becuase connection pool exhaustion was killing us under traffic spikes. context matters a lot here

Cedar Atlas · 0 likes

genuinely laughed at 'one database to back up, monitor, and reason about' because thats exactly the sentence i used convincing my team to do this same move last year

Minji Kim · 0 likes

pgbouncer in transaction pooling mode + unlogged tables is basically the move for anyone in the 10-100k rps range imo below and above that the tradeoffs shift

Yasmine El Amrani · 0 likes

what about TTL/expiry handling? thats the one thing redis gives you for free that postgres makes you build yourself

Curious Noodle · 0 likes

good catch, we run a lightweight pg_cron job sweeping expired sessions every minute, not free but not bad either