1.4k stars · MIT · 3.9.0 (2026-06-20)
PostgreSQL-backed task queue for Python — the background worker four editions of product advice quietly assumed he already had.
▶Repo detailsthe review · specs · pros & cons · install
What it is
A distributed task queue for Python that uses PostgreSQL as its entire backend: jobs, locks, retries, scheduling and the dispatch notifications all live in tables in your existing database. It works with both synchronous and async code and has first-class support for periodic tasks.
Why it matters
Read back through this radar and count the phrases "queued worker job", "background job with a progress indicator", "run as a scheduled job": Docling parsing a 90-page PDF, BERTopic clustering, tsfresh over three years of EURUSD, a backtest sweep. Every one of those takes minutes and none of them can happen inside a web request, so the honest position is that several product features you have been handed are not shippable until this exists. The reason this specific library rather than Celery is the reason pgvector beat a dedicated vector database in Edition 2: no Redis, no RabbitMQ, no second thing to secure and back up. One pg_dump still captures everything, and a job's state is a row you can look at in SQL when something goes wrong at 3am.
- No new infrastructure whatsoever — the queue is tables in the PostgreSQL you already run and already back up
- Retries, locks, scheduled and periodic tasks included, so the ingest pipeline stops needing hand-written cron scripts
- Async-native, which matches FastAPI, and small enough that you can read the whole thing when you need to
- 1.4k stars and a small maintainer group. Mature and well documented, but not Celery-sized — a real consideration for something load-bearing
- PostgreSQL as a queue has a genuine ceiling. You are nowhere near it, but it is not the right tool at very high job rates
- The worker is a second process to keep running, which means a systemd unit or a container — one more thing on the box that 08 is now measuring
Install into the FastAPI virtual environment, run its migration against your existing PostgreSQL, and start one worker process beside the API.
source venv/bin/activate pip install procrastinate procrastinate schema --apply # creates its tables in your database procrastinate --app=myapp.app worker # the worker process