> 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. If one thing fails, everything is rolled back. This is such a key feature. Lots of people will tell you that you shouldn't use a relational database as a worker queue, but they inevitably miss out on how important transactions are for th…
Oban, the job processing framework from Elixir, has come to Python
71–80 of 107 posts
Re: Oban, the job processing framework from Elixir, has come to Python
#72This is something my company has been considering for a while. We've been using celery and it's not great. It gets the job done but it has its issue. I've never heard of Oban until now and the one we've considered was Temporal but that feels so much more than what we need. I like how light Oban is. Does anyone have experience with both and is able to give a quick comparison? Thanks!
It’s a heavy weight that covers a lot of use cases. But we just run simple ProcessWorkers for our regular needs and ECS worker for heavier ML tasks.
Re: Oban, the job processing framework from Elixir, has come to Python
#73Is Postgres fast enough for job processing these days? We do hundreds of millions of jobs now and even years ago when our volume was a fraction of that, we got a huge performance boost moving from Postgres + Que to Redis + Sidekiq. Has that changed in the intervening years?
Re: Oban, the job processing framework from Elixir, has come to Python
#74> 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. If one thing fails, everything is rolled back. This is such a key feature. Lots of people will tell you that you shouldn't use a relational database as a worker queue, but they inevitably miss out on how important transactions are for th…
Re: Oban, the job processing framework from Elixir, has come to Python
#75This is something my company has been considering for a while. We've been using celery and it's not great. It gets the job done but it has its issue. I've never heard of Oban until now and the one we've considered was Temporal but that feels so much more than what we need. I like how light Oban is. Does anyone have experience with both and is able to give a quick comparison? Thanks!
Very, very different tools, though they cover similar areas. Temporal - if you have strict workflow requirements, want _guarantees_ that things complete, and are willing to take on extra complexity to achieve that. If you're a bank or something, probably a great choice. 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…
Re: Oban, the job processing framework from Elixir, has come to Python
#76Is there a web U/I to view jobs, statuses, queue length etc?
Re: Oban, the job processing framework from Elixir, has come to Python
#77> 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. If one thing fails, everything is rolled back. This is such a key feature. Lots of people will tell you that you shouldn't use a relational database as a worker queue, but they inevitably miss out on how important transactions are for th…
It feels like such a super power. What you're describing is particularly important in the era of long running AI processes. Something as simple as running a deploy creates pressure on your agent orchestration. But if everything is powered by OBAN you have wonderful ways to build durability.
By the way, it's all "free" and built-in.
In other language ecosystems, people literally pay for durability that has this shape (like temporal)
Re: Oban, the job processing framework from Elixir, has come to Python
#78Re: Oban, the job processing framework from Elixir, has come to Python
#79While this is a Cool Thing To See, I do wish things would go the other way—and have all the BI/ML/DS pipelines and workflows folks are building in Python and have them come to Elixir (and, as would follow, Elixir). I get where the momentum is, but having something functional, fault-tolerant, and concurrent underpinning work that’s naturally highly concurrent and error-prone feels like a _much_ more natural fit.
Agree, and Claude Code does very well with Elixir despite TS/Python getting all the hype: https://youtu.be/iV1EcfZSdCM?si=KAJW26GVaBqZjR3M This helps with keeping it on track writing idiomatic elixir and using good patterns: https://skills.sh/agoodway/.claude/elixir-genius
How much context is eaten up by skills that rehash what a SOTA model should already know?
Maybe token-wise, it's a wash: Elixir/OTP does a lot without third-party libs, which would require massive npm dependencies to achieve the same thing.
Re: Oban, the job processing framework from Elixir, has come to Python
#80BTW its free.