zlacker

> This said, I'd use a dedicated queue these days.

I agree, primary reason being that if you're in the cloud (thus this applies to a lot of people but obviously not everyone), all the cloud providers have extremely easy to use, and cheap, hosted queueing tech. Even if you're worried about vendor lockin, queueing primitives are so small (basically push and pop), that it's relatively easy to write things in a way so it would be easy to migrate if necessary.

>>hn_thr+(OP)
Is it cheap if you already using Postgres though?

>>klysm+n4
I commented elsewhere, but in most cases I think it would be a bad idea to host your queue tables and logic in the same instance that hosts your primary data. This if you spin up another PG instance in the cloud, it could very well end up costing you more than a default cloud-hosted queue service.

>>hn_thr+452
I don’t think that’s best for small things. Unless you can’t vertically scale your instance to handle to load, being able to join and keep transactions within one data store is massively valuable. I wouldn’t want to open myself to distributed systems problems unless I’m absolutely forced to.