zlacker

>>bo0tzz+(OP)
We used postgres for some of our queues back when we were at ~10 msg/s. It scaled quite a bit, but, honestly, setting up SQS or some other queue stack in AWS, GCP, or Azure is so simple and purpose built for the task (with DL queues and the like built in), I don’t know why you wouldn’t just go that route and not have to worry about that system shitting the bed and affecting the rest of the DB’s health.

It seems foolish. I am a big fan of “use the dumbest tool”, but sometimes engineers take it too far and you’re left with the dumbest tool with caveats that don’t seem worth it given the mainstream alternative is relatively cheap and simple.

>>vhirem+4o
> I don’t know why you wouldn’t just go that route and not have to worry about that system shitting the bed

Because different software has different requirements. Not having an external service requirement other than Postgres might be a feature of an on-prem/b2b appliance.

Because some software may be projected never outgrow the capabilities of Postgres, and if it does moving to another service can be made very easy.

Because you want a transitional job system and the simplicity of doing it in Postgres.