Today we're releasing Oban for Python. Not an Oban client in Python. Not a pythonx wrapper
embedded in Elixir. No, it's a fully operational, PostgreSQL backed, typed, async,
pythonic-as-we-could-muster implementation of Oban in Python.
Why on Earth?
2025 was supposed to be the year of Elixir interop. We're fashionably late, and what better way to celebrate than bringing Oban to another ecosystem? Python seemed like a natural fit. One of us, (not naming any names), wouldn't even consider Oban for Go...
Python is undeniably ubiquitous across most domains of computing. There are packages and frameworks available in Python that are sorely missing in other ecosystems, including Elixir.
Oban has proven to be a valuable tool for developers looking to build reliable applications in Elixir. So why not Python? As Elixir evangelists we recognize the value in expanding Oban into a new community, championing Elixir, and enticing developers to consider its benefits.
Oban for Python
The OSS oban-py package is available on GitHub, published to PyPI, and the
documentation is hosted here. The initial release is v0.5.0; it's not yet v1.0 but full
featured enough that we shan't call it a v0.1.
If you're coming from any one of the other Python background job systems, some of the standouts of Oban in Python are below (if you're an Elixirist familiar with Oban, skip beyond the bullet list):
-
No message broker — Just PostgreSQL. No Redis, no RabbitMQ, no separate infrastructure to manage. Jobs live in the same database as your application data.
-
Historic job retention — Oban keeps jobs after execution rather than immediately deleting them — completed, failed, cancelled, all of it. You receive a full audit trail and can query job history.
-
Independent concurrency — Each queue has its own concurrency limit. Configure
emailsat 5,reportsat 2 and they won't compete for a shared worker pool. A slow report can't starve your email queue. -
Runtime queue control — Pause, resume, or scale queue concurrency without restarting workers. Especially useful for maintenance windows or throttling during incidents.
-
The CLI — This one's not a surprise, but we're super keen on it. The schmancy CLI shown above handles installation, upgrades, and running worker processes with auto-discovery of workers and cron schedules.
We encourage you to give it a go! Clock the docs, kick the tires, peruse the source, throw your agents at it, and interrogate us (via email only).
Oban Pro for Python
Yes, we're dropping Oban Pro for Python at the same time. The initial Pro release is also v0.5.0, and the docs are here. It ships with some of our favorite Pro features and something BEAM-ish:
-
Workflows — Durable job composition with sequential, fan-out, and fan-in patterns. Nest sub-workflows, pass results downstream automatically, or graft new jobs onto running workflows at runtime. State lives in Postgres, not memory.
-
Smart concurrency — Rate limit jobs globally across your cluster (e.g., 60 API calls per minute, enforced across all nodes), or partition queues to apply limits per worker, tenant, or any argument you choose.
-
Multi-process execution — Call it "BEAM mode" for Python. Bypass the GIL and allow jobs to fan out across all processors, using available CPU cores automatically.
Oban Pro for Python is its own product with its own license. If you've purchased Pro for Elixir, the pricing and flow is similar if not intuitive.
We're launching in beta, and the first 10 subscribers that use the coupon code
OBAN4PY will be grandmothered in at 50% off for the lifetime of their Oban Pro for
Python subscription.
Elixir Interop
From the outset we were determined to make the Elixir and Python implementations fully compatible. This is about interop and expansion after all! To that end, the underlying table structures are nearly identical (some column types are subtly different for the sake of optimization).
It's entirely possible to enqueue jobs from an Oban instance running in Elixir and run them in Python, or vice-versa!
In fact, recorded job output is stored in erlang term format, so you can retrieve output from jobs run in an entirely different platform. Since the PubSub notification format is identical, it's even conceivable to pause/resume/scale queues running on heterogeneous nodes.
Building Oban for Python encouraged us to revisit legacy decisions baked into the Elixir implementation. The exercise will inform Oban 3.0 and Pro 2.0. Interop goes both ways.
To the Future
This is a v0.5, not a v1.0. There's much more to design and build—full parity with Oban, missing Pro features, complete interop with the Oban Web dashboard. Perhaps alternate database support? We're working on it!
Building Oban for Python was a significant undertaking, and we're genuinely excited to see what people do with it. If you try it out, do let us know how it goes.
As usual, if you have any questions or comments, ask in the Elixir Forum. For future announcements and insight into what we're working on next, subscribe to our newsletter.