What does it do?
Dramatiq does the same core job as Celery and RQ, taking slow tasks off a website’s main thread and running them separately, but was designed later with the specific goal of being harder to misuse. It handles retries, rate limiting, and task prioritization out of the box, with sensible defaults instead of requiring engineers to hand-tune every setting. Workers pick up tasks from a broker, usually Redis or RabbitMQ, run them, and report back, the same basic factory-floor model as its competitors, just with fewer sharp edges.
See it in action
This defines a background job that sends an email and immediately hands it off to a worker to process later, rather than doing it right away.
import dramatiq
from dramatiq.brokers.redis import RedisBroker
dramatiq.set_broker(RedisBroker(host="localhost"))
@dramatiq.actor
def send_email(address):
print(f"Sending email to {address}")
send_email.send("user@example.com")Why would a non-developer care?
The gap between a background task queue that works and one that’s misconfigured and silently drops jobs is where a lot of production incidents live. Dramatiq’s whole design philosophy is closing that gap by making the safe choice the default one.
Real-world examples
Dramatiq is newer than Celery and has a smaller but devoted following among teams who found Celery’s flexibility came with too many footguns, like configuration mistakes that cause tasks to be lost or run twice. Its own documentation explicitly compares itself against Celery and RQ, addressing pain points its creator experienced firsthand using those tools in production.
Who uses it
Python teams who want Celery-like power for background processing but with stricter defaults and less configuration risk.
How it compares to alternatives
It directly positions itself against Celery, criticizing its complexity, and against RQ, whose simplicity it matches while adding more robust delivery guarantees.