> I believe this model is almost always the right starting point for a web application, barring some unusual job requirements or massive initial scale.
Would you run this job queue on the same postgres database as the rest of the application or rather use a different one specific for workers?
One of the main benefits of this model is the ability to transactionally enqueue any jobs that are being triggered at the same time as other changes your app is making. Also the ability to transactionally apply changes to your database at the same time as marking the job completed.
You only get this benefit if you’re doing everything in a single Postgres database. By the time you outgrow that setup, you may as well move to a more dedicated job queue or something built on Redis, because you’ve already lost the benefits of having a single system.
I suppose you could maintain the queue in a separate Postgres database, but without sharing ACID with the app I’m not sure What you’d gain vs another system.
Would you run this job queue on the same postgres database as the rest of the application or rather use a different one specific for workers?