django.tasks · Django 5.2 LTS+

The production worker for Django Tasks

Django ships the Tasks API, but its built-in backends are for development only. Oxpull stores the queue in the database you already run and executes tasks with a separate worker process. No broker, no Redis, nothing new to operate.

enqueue() is a plain INSERT on your default connection, so a task enqueued inside transaction.atomic() commits or rolls back together with your business data. A broker cannot share your database transaction. There is no window where an order exists without its email task, and no on_commit boilerplate.

with transaction.atomic():
    order = Order.objects.create(...)
    send_confirmation.enqueue(order.pk)
# one COMMIT. Both rows exist, or neither does.

The task row and the order row share a transaction

Measured, not promised

Against django-tasks-db 0.12 on PostgreSQL 16 (2,000 no-op tasks, five runs per arm, one machine), django-ox 1.1.0 completed the batch at 124.5 tasks per second against 108.0 with a single worker. Every one of our five runs beat every one of theirs: our slowest was 121.3, their fastest 110.1. In-transaction enqueue latency was a tie, about six tenths of a millisecond at p50 for both. The benchmarks page carries the full matrix and the method behind every figure.

Reliability got the same treatment: 21.5 minutes of sustained load on PostgreSQL 16, 37,804 tasks, including nine minutes in which a worker was SIGKILLed every 20 to 45 seconds. Every task reached a terminal state, no task ran twice in this run, and every interrupted execution was re-executed inside the documented bound. Execution is at-least-once. A worker killed after the work finished but before the result was recorded leaves that task to run again. The harness asserts that a second execution is only ever attributable to a kill.

No-op benchmarks flatter every queue, so read these as relative, not as capacity planning. The full methodology, every run, and the raw per-sample data ship in the repository.

Free core, paid scale

The open source worker is the production backend. Pro adds the features that only start to hurt once you have real volume.

django-ox BSD-3 · free forever

Durable queue in your existing database
Transactional enqueue
At-least-once execution, SKIP LOCKED claiming on PostgreSQL and MySQL 8
Retries with backoff, per-attempt tracebacks
Reaper for tasks from dead workers
Graceful drain on SIGTERM
Priorities, deferred tasks, multiple queues
Recurring schedules, cron or fixed interval, in settings or the Django admin
Pruning command for finished rows
Stats API and health command

PostgreSQL, SQLite and MySQL 8, all tested in CI. Live now: pip install django-ox, or pip install "django-ox[backport]" on Django 5.2 LTS · GitHub · docs · how it compares.

Oxpull Pro commercial license

Batches: group tasks, with a callback when every member is settled
Unique tasks (deduplication)
Rate limiting
Email support from the maintainer
Requires Django 6.0 or later

All three are built and tested. Pro is not on sale yet, and the waitlist below is how to hear when it opens. Delivered from a private package index using credentials issued per company, with no license key and no runtime check to break your production. Install stays pip install.

Pricing, and the waitlist

Pro is planned at $399 per year, per company, flat, self-serve. Seven-day money-back, no trial keys.

Your email is used only to tell you when Pro launches. Reply "remove", or write to [email protected], and it is deleted.

Questions you should ask

What is the license situation?

The worker itself, django-ox, is BSD 3-Clause and stays that way. Pro is separate code under a commercial license, sold per company. The free tier is not a demo. It is the backend the docs mean when they say production systems need a durable queue and a worker process.

When does this ship?

The open source worker is live: pip install django-ox, with documentation here. Pro is built and tested. What is left is the purchase path. Waitlist email is the announcement channel.

Who is behind it?

An independent software vendor with one product: this one. You will know who maintains it, contracts get signed under the company name, and support answers come from the person who wrote the code.

What does support look like?

Open source support is on GitHub issues. Pro comes with email support from the maintainer at [email protected]. If your procurement needs a PO and an invoice instead of a card, write to that address. Invoiced purchasing is planned alongside self-serve.

Do I need Pro to run production?

No. Durability, retries, the reaper, and graceful shutdown are all in the free worker, and so are the stats API and the health command. Pro adds three things the free tier does not do: batches, deduplication and rate limiting. Support comes with it. Pro needs Django 6.0 or later. The free worker also runs on Django 5.2 LTS through the django-tasks backport, and Pro does not.