django-pgpubsub VS django-pgtrigger

First I would stick with celery if possible. I am not aware of something like that that is widely adopted. you could write your own crontab scripts or a combination of crontab script that writes to db with some listener like this https://github.com/Opus10/django-pgpubsub or use this one https://github.com/kraiz/django-crontab But both projects are not widely used or do not seem to be well maintained. I hope I was able to be of any help.

If you're using Postgres, you could consider https://github.com/Opus10/django-pgpubsub

django-pgpubsub – A distributed task processing framework for Django built on top of the Postgres NOTIFY/LISTEN protocol

Rather than relying on signals and celery, we may want to consider borrowing a pattern from the land of Postgres: Triggers and NOTIFY/LISTEN. The library django-pgpubsub offers a django application layer abstraction of this pattern. We can refactor our above solution using django-pgpubsub to look as follows:

You could try https://github.com/Opus10/django-pgpubsub. This is distributed task processing framework for Django built on top of the Postgres NOTIFY/LISTEN protocol. Does what you're looking for and isn't as operationally heavy as something like celery.

A common pattern in modern web development is the requirement to process data asynchronously after some user action or database event. In the below article, I describe via a concrete example a traditional approach to solving this problem for a Django/Postgres based application using django signals and Celery. I then proceed to discuss some of the shortcomings of this approach and demonstrate how using django-pgpubsub can offer a lightweight and more robust solution.

For Django there's https://github.com/Opus10/django-pgtrigger that makes it possible to define triggers right in your models, so you have everything in one place.

django-pgtrigger – Write Postgres triggers for your Django models

Note that have now ditched our post_save signal from the previous solution. As we pointed out, signals can easily be missed. Instead, we are using a Postgres trigger : defining the listener as it is above makes use of the django-pgtrigger library to write a Postgres trigger to our database, the job of which is to notify our channel whenever a Comment is inserted in to the database. Triggers are far more robust than signals for detecting database write events; application level triggers can easily be missed, whereas triggers will always be executed.