Chancy

Chancy is a distributed task queue and scheduler for Python built on top of Postgres.

Key Features

• Robust Jobs - support for priorities, retries, timeouts, scheduling, global rate limits, memory limits, global uniqueness, error capture, cancellation, and more
• Minimal dependencies - Core functionality requires only psycopg3 - which can be installed side-by-side with psycopg2.
• Minimal infrastructure - No need to run a separate service like RabbitMQ or redis. Every feature is built on top of Postgres. No need for separate monitoring services like Flower or schedulers like Celery Beat - everything is built-in to the worker.
• Plugins - Several plugins including a dashboard, workflows, cron jobs (with timezone support), and more.
• Flexible - A single worker can handle many queues and mix threads, processes, sub-interpreters, and asyncio jobs, allowing powerful workflows that use the optimal concurrency model for each job. Queues can be created, deleted, modified, and paused at runtime.
• async-first - Internals designed from the ground up to be async-first, but has minimal sync APIs for easy integration with existing non-async codebases.
• Transactional enqueueing - Atomically enqueue jobs and the data they depend on in a single transaction.
• Performant - Used in production environments to process millions of jobs per day.
• Portable - Supports Linux, OS X, and Windows.
• 100% open & free - no enterprise tiers or paid features.

Documentation

Check out the getting-started guide and the API documentation at https://tkte.ch/chancy/.

Testing documentation examples

Install the development dependencies with uv sync --all-extras, then run:

uv run sphinx-build -W --keep-going -b doctest docs docs/_build/doctest

Use -b html to build the site with the same checks. Unresolved references produce warnings, and -W makes warnings fail the build, as they do in CI.

Mark runnable examples in RST files or docstrings with .. testcode:: or .. doctest::. Use a named group when examples share setup or variables; .. testsetup:: and .. testcleanup:: provide hidden setup and cleanup. Hidden testcode blocks can assert documented defaults and results without adding test scaffolding to the rendered page. The pruner docstring is an example.

Keep these checks deterministic and independent of a running database. Examples requiring PostgreSQL belong in integration tests. Plain code-block blocks and unmarked >>> examples remain illustrative. CI runs doctests before building the HTML documentation, and a failing example fails the docs job.