FastWorker vs Dramatiq

Dramatiq is one of the best-designed modern Python task queues. It’s Celery’s spiritual successor for teams who want a cleaner, more opinionated alternative — but it still requires a broker (Redis or RabbitMQ). FastWorker goes one step further by eliminating the broker entirely.

The one-line summary

Dramatiq is a cleaner, more opinionated take on broker-backed task queues. FastWorker is the same “simple task queue” ethos, but brokerless.

Feature matrix

Capability	FastWorker	Dramatiq
External broker	None	Redis / RabbitMQ
Minimal services	2–3 Python processes	3–5
Async FastAPI client	Native	Sync (send)
Built-in dashboard	Yes	Third-party
Priority queues	4 enum levels	Yes (integer priority)
Automatic retries	Manual	Yes (configurable backoff)
Rate limiting	No	Yes (built-in middleware)
Pipelines (chains)	No	Yes
Scheduled tasks	No	dramatiq-crontab
Durable persistence	No	Yes (broker-backed)
Message encryption	No	Via middleware
Recommended scale	1K–10K tasks/min	Higher with RabbitMQ

Code: side by side

Defining a task

# Dramatiq
import dramatiq

@dramatiq.actor
def send_email(user_id: int) -> bool:
    ...
    return True

# FastWorker
from fastworker import task

@task
def send_email(user_id: int) -> bool:
    ...
    return True

Both are delightfully simple.

Sending a task

# Dramatiq
send_email.send(42)

# FastWorker
await client.delay("send_email", 42)

Dramatiq’s .send() is synchronous. FastWorker’s .delay() is async, which matches FastAPI’s execution model.

Retries with backoff

# Dramatiq — declarative, excellent
@dramatiq.actor(max_retries=3, min_backoff=1000, max_backoff=30000)
def call_api(url):
    return requests.get(url).json()

# FastWorker — explicit, less magic
@task
def call_api(url: str):
    for attempt in range(3):
        try:
            return requests.get(url, timeout=5).json()
        except Exception:
            time.sleep(min(30, 2 ** attempt))
    raise

Dramatiq’s retry middleware is genuinely nice. FastWorker is more explicit.

Where Dramatiq wins

• Built-in retries with backoff. Dramatiq’s retry middleware is first-class. FastWorker expects you to handle retries in the task body.
• Rate limiting. Built-in per-actor rate limiting middleware. FastWorker has nothing equivalent.
• Pipelines. Compose actors into sequential flows with pipe(). FastWorker has no pipeline primitive.
• Durable persistence. Messages live in Redis/RabbitMQ; they survive worker crashes.
• Middleware architecture. Dramatiq’s middleware stack is a clean extension point.

Where FastWorker wins

• No broker. Dramatiq still needs Redis or RabbitMQ. FastWorker runs on pure Python.
• Async-native client. Dramatiq’s send() is sync; FastWorker is async.
• Built-in dashboard. Dramatiq’s ecosystem has third-party dashboards; FastWorker ships one.
• Automatic worker discovery. FastWorker’s control plane auto-registers subworkers; Dramatiq workers listen on queue names you declare.
• Smaller operational surface. Fewer services, fewer things to monitor.

Which to choose

Choose Dramatiq if:

• You want automatic retries with backoff as a decorator
• You need rate limiting out of the box
• You use pipelines / actor composition
• You need durable persistence of queued messages
• You’re fine running Redis or RabbitMQ

Choose FastWorker if:

• You don’t want to run a broker
• You want an async-native client for FastAPI
• You want a web dashboard that ships with the queue
• You want the smallest possible deployment footprint
• You can live without built-in retry middleware

Dramatiq and FastWorker are aimed at similar teams. The question is whether you want the broker or not.

Next steps

• FastWorker vs Celery
• FastWorker vs RQ
• Architecture