TKTkTech·Jan 29, 2026
I kinda have my own https://github.com/tktech/chancy :P
In Oban, the job processing framework from Elixir, has come to PythonTkTech
chancy
Python2024–2026
TkTech / chancy
chancy
A postgres-backed task queue for Python.
2Distinct people
12Mentions
0Explicit recommenders
294GitHub stars
What to know before exploring
What it is
A postgres-backed task queue for Python.
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- procrastinate-org/procrastinate · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by month12 dated mentions
Observed mentions: 2024-08-19 22:08:52 UTC to 2026-01-29 15:59:01 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| Aug 2024 | 2024-08-01 00:00:00 UTC | 2024-09-01 00:00:00 UTC | 1 | 0 | 1 |
| Sep 2024 | 2024-09-01 00:00:00 UTC | 2024-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2024 | 2024-10-01 00:00:00 UTC | 2024-11-01 00:00:00 UTC | 0 | 0 | 0 |
| Nov 2024 | 2024-11-01 00:00:00 UTC | 2024-12-01 00:00:00 UTC | 2 | 1 | 1 |
| Dec 2024 | 2024-12-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| Jan 2025 | 2025-01-01 00:00:00 UTC | 2025-02-01 00:00:00 UTC | 0 | 0 | 0 |
| Feb 2025 | 2025-02-01 00:00:00 UTC | 2025-03-01 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2025 | 2025-03-01 00:00:00 UTC | 2025-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2025 | 2025-04-01 00:00:00 UTC | 2025-05-01 00:00:00 UTC | 1 | 0 | 1 |
| May 2025 | 2025-05-01 00:00:00 UTC | 2025-06-01 00:00:00 UTC | 2 | 0 | 2 |
| Jun 2025 | 2025-06-01 00:00:00 UTC | 2025-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2025 | 2025-07-01 00:00:00 UTC | 2025-08-01 00:00:00 UTC | 1 | 0 | 1 |
| Aug 2025 | 2025-08-01 00:00:00 UTC | 2025-09-01 00:00:00 UTC | 0 | 0 | 0 |
| Sep 2025 | 2025-09-01 00:00:00 UTC | 2025-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2025 | 2025-10-01 00:00:00 UTC | 2025-11-01 00:00:00 UTC | 0 | 0 | 0 |
| Nov 2025 | 2025-11-01 00:00:00 UTC | 2025-12-01 00:00:00 UTC | 2 | 0 | 2 |
| Dec 2025 | 2025-12-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| Jan 2026 | 2026-01-01 00:00:00 UTC | 2026-02-01 00:00:00 UTC | 2 | 0 | 2 |
What Hacker News says
12 sourcesThe Oban folks have done amazing, well-engineered work for years now - it's really the only option for Elixir. That said, I'm very confused at locking the process pool behind a pro subscription - this is basic functionality given CPython's architecture, not a nice-to-have.
For $135/month on Oban Pro, they advertise:
All Open Source Features
Multi-Process Execution
Workflows
Global and Rate Limiting
Unique Jobs
Bulk Operations
Encrypted Source (30/90-day refresh)
1 Application
Dedicated Support
I'm going to toot my own horn here, because it's what I know, but take my 100% free Chancy for example - https://github.com/tktech/chancy. Out of the box the same workers can mix-and-match asyncio, processes, threads, and sub-interpreters. It supports workflows, rate limiting, unique jobs, bulk operation
Read the rest
s, transactional enqueuing, etc. Why not move these things to the OSS version to be competitive with existing options, and focus on dedicated support and more traditional "enterprise" features, which absolutely are worth $135/month (the Oban devs provide world-class support for issues). There are many more options available in the Python ecosystem than Elixir, so you're competing against Temporal, Trigger, Prefect, Dagster, Airflow, etc etc.
(I'm biased, I'm the author of Chancy)
One of the major complaints with Celery is observability. Databased-backed options like Procastinate and Chancy will never reach the potential peak throughput of Celery+RabbitMQ, but they're still sufficient to run millions upon millions of tasks per day even on a $14/month VPS. The tradeoff to this is excellent insight into what's going on - all state lives in the database, you can just query it. Both Procastinate and Chancy come with Django integrations, so you can even query it with the ORM.
For Chancy in particular, retries are a (very trivial) plugin (that's enabled by default) - https://github.com/TkTech/chancy/blob/main/chancy/plugins/re.... You can swap it out and add whatever complex retry strategies you'd like.
Chancy also comes with a "good enough" metrics plugin and a dashboard. Not suita
Read the rest
ble for an incredibly busy instance with tens of thousands of distinct types of jobs, but good enough for most projects. You can see the new UI and some example screenshots in the upcoming 0.26 release - https://github.com/TkTech/chancy/pull/58 (and that dashboard is for a production app running ~600k jobs a day on what's practically a toaster). The dashboard can be run standalone locally and pointing to any database as-needed, run inside a worker process, or embedded inside any existing asgi app.
If you like Procastinate, you might like my Chancy, which is also built on postgres but with a goal of the most common bells and whistles being included.
Rate limiting, global uniqueness, timeouts, memory limits, mix asyncio/processes/threads/sub-interpreters in the same worker, workflows, cron jobs, dashboard, metrics, django integrations, repriotization, triggers, pruning, Windows support, queue tagging (ex: run this queue on all machines running windows with a GPU, run this one on workers with py3.14 and this one on workers with py3.11) etc etc...
https://tkte.ch/chancy/ & https://github.com/tktech/chancy
The pending v0.26 includes stabilizing of the HTTP API, dashboard improvements, workflow performance improvements for workflows with thousands of steps and django-tasks integration.
In A first look at Django's new background tasksWith that experience behind you, would you have feedback for Chancy[1]? It aims to be a batteries-included offering for postgres+python, aiming for hundreds of millions of jobs a day, not massive horizontal worker scaling.
It both polls (configurable per queue) and supports listen/notify simply to inform workers that it can wake up early to trigger polling, and this can be turned off globally with a notifications=false flag.
[1]: https://github.com/tktech/chancy
In Postgres LISTEN/NOTIFY does not scaleGonna toss my own hat in the ring there for the python+postgres ecosystem :)
https://github.com/tktech/chancy
> As a rule of thumb, if you're processing less than 1000 jobs per day or your jobs are mostly lightweight operations (like sending emails or updating records), you can stick with this solution.
This seems... excessively low? Chancy is on the heavier side and happily does many millions of jobs per day. Postgres has no issue with such low throughput, even on resource constrained systems (think a $5 vps). Maybe they meant 1000 per second?
In How to run cron jobs in Postgres without extra infrastructurehttps://tkte.ch/chancy/
https://github.com/tktech/chancy
Chancy is a postgres-backed task queue for Python that scratches a lot of the Celery itches. It's not meant for folks that need to run a million tasks a second, but for the majority of projects (many millions per day) it offers:
- Robust job support, including timeouts, memory limits, retries, global uniqueness, global rate limiting, scheduling (cron and "in 10 seconds"), priorities, etc...
- DAG based workflow plugin
- It's asyncio-first with support for threading, multiprocessing, asyncio, and sub-interpreter tasks so each job can use the optimal concurrency model. Workflows can mix tasks across multiple queues and concurrency models.
- Can be embedded inside your existing ASGI servers - great for things like development docker containers or containers deployed on say, unraid.
- W
Read the rest
orker's handle scheduling (no need for `celery beat`) and have an optional built-in dashboard.
- 1 infrastructure dependency (postgres) and 1 required package (psycopg3) - with everything else isolated in optional plugins.
- Dynamically re-assign queues to new workers based on tags, add, pause (with auto-resume), modify or destroy queues at any time.
- Highly observable - unlike Celery, you can just query your database when needed to see the entire system state
- Portable - Linux/Windows/OSX
- Permanently free and open-source without any "premium" or paid features.
- Django integration - ORM/models, admin, and django auth integration for the dashboard.
Chancy is a young tool, but is used in production environments with tens of thousands of users and billions of jobs run with great feedback from early users:
> ...thank you for this amazing library...
> hey, first thanks for such a great library! Chancy has worked incredibly well, and its modular design has made it a pleasure to use. Super lightweight but feature-full; it's a hard balance to strike.
How does this compare to other pg-backed python job runners like Procrastinate [0] or Chancy [1]?
[0] https://github.com/procrastinate-org/procrastinate/
[1] https://github.com/TkTech/chancy
In Show HN: Hatchet v1 – A task orchestration platform built on PostgresAlso https://github.com/TkTech/chancy for another (early) Python option that goes the other way and aims to have bells and whistles included like a dashboard, workflows, mixed-mode workers, etc...
Check out the Similar Projects section in the docs for a whole bunch of Postgres-backed task queues. Haven't heard of pgqueuer before, another one to add!
In How to use Postgres for everythingShow HN: Chancy, a Postgres-backed, batteries-included task queue for Python
Chancy is an early-stage project to address a lot of the issues I've run into over the years trying to use Celery+Flower on small and large projects. It's now been used in a few projects with thousands of users, over a billion jobs, and hundreds of thousands of workflows. All Chancy features work with just Postgres, on 1 or 1000 workers or even embedded inside your existing asyncio servers like FastAPI.
- Support for job priorities, retries, timeouts, scheduling, global rate limits, memory limits, unique jobs, cancellation, and more
- asyncio-based worker with support for asyncio, threaded, process-based, and sub-interpreter job execution.
- Configurable job retention for easy debugging and tracking
- Minimal dependencies (only psycopg3 required)
- Plugins for a dashboard, workflows, cron jobs, and more
- Opti
Read the rest
onal transactional enqueueing for atomic job creation
- asyncio & sync APIs for easy integration with existing codebases
This is a fairly old article, but this has become a very common pattern. For 90% of projects that just need a task queue for sending email or generating reports, you're not going to be doing millions of messages a second and anything that simplifies your stack is worth looking at. I've used these patterns so often to work around issues encountered with Celery that I've split them into their own framework, https://github.com/TkTech/chancy (feedback appreciated ;)
There are lots of these, several of which are commercial ventures so there's definite interest behind it:
https://worker.graphile.org/ (Node.js)
https://riverqueue.com/ (Go)
https://github.com/acaloiaro/neoq (Go)
https://github.com/contribsys/faktory (Go)
https://github.com/sorentwo/oban (Elixir)
https://github.com/procrastinate-org/procrastinate (Python)
In Do you need Redis? PostgreSQL does queuing, locking, and pub/sub (2021)https://github.com/tktech/chancy is a very early-stage pet project to work around specific issues I keep running into with Celery that has all of this, including a simple plugin-extendable UI with DAG workflow visualization.
In Show HN: PgQueuer – Transform PostgreSQL into a Job Queue