1. Feature‑by‑feature comparison of job queues
- Oban vs. Temporal vs. Celery
- “Temporal – if you have strict workflow requirements, want guarantees that things complete, and are willing to take on extra complexity to achieve that.” – BowBun
- “Oban – DB‑backed worker queue, which processes tasks off‑thread. It does not give you the guarantees that Temporal can because it has not abstracted every push/pull into a first‑class citizen.” – BowBun
-
“Celery + RabbitMQ is hard to beat in the Python ecosystem for scaling.” – TkTech
-
Language‑specific strengths
- “Oban allows you to insert and process jobs using only your database.” – simonw
- “Python has a lot of libraries that are not async‑friendly… Celery has absolutely no asyncio support at all.” – TkTech
2. Open‑source vs. paid feature gating
- “I think we should not lock technical features behind a paywall.” – owaislone
- “Oban Pro locks core features like multi‑process execution, workflows, global and rate limiting, unique jobs, bulk operations, etc.” – TkTech
- “It feels bad to have ‘same thing but better’ gated behind payment.” – qianli_cs
3. PostgreSQL as a durable job queue (transactional outbox pattern)
- “Oban allows you to insert and process jobs using only your database. You can insert the job to send a confirmation email in the same database transaction where you create the user.” – simonw
- “This is called the ‘transactional outbox pattern’!” – nhumrich
- “Good Job is a strong attempt… it uses advisory locks.” – brightball
- “Transactions around fetching/updating aren’t trivial, but they are part of the application logic and make testing easier.” – sorentwo
These three themes—feature trade‑offs across ecosystems, the debate over freemium models, and the appeal of a Postgres‑centric, transactional approach—dominate the discussion.