Hacker News Reader

I'm still trying to find an engineer that can explain to me why they use Redis for job queuing over Postgres.

Redis for HTML caching: Cool.

Redis for queueing: Are you really sure you need the performance gain? Really? You can do 10k writes per second with Postgres (100k per second with COPY). If you need more than that fine, but for 99% of web apps out there it's just one more moving piece that probably doesn't get included in your backups.

View on HN

I was looking at that choice for my latest project and the gem recommended (resque?) only using Redis for the job queuing at the benefit of much higher performance over something like delayed_jobs using postgresql in jobs. It didn't seem worth it as job queueing was not the main feature of the server. I suppose if one were doing some sort of real time feature where you had to queue things off a Rails API response thread it would make sense but wasn't doing that for now. But just judging by the number of downloads, the Redis based job queue is possibly more popular for some reason.

Proper queuing in RDBMSs can be tricky.

2ndQuadrant has a good write up of what is required to make sure you don't fall into any traps: https://blog.2ndquadrant.com/what-is-select-skip-locked-for-...

Now if we're just talking about persisting data to somewhere - postgres COPY is pretty amazing.

Reply on news.ycombinator.com