SimpleQ vs BullMQ
BullMQ is powerful — but you run the Redis. You provision it, patch it, monitor it, scale it, and hope it doesn't run out of memory on a Friday night. SimpleQ replaces that infrastructure with a managed service purpose-built for webhook delivery to AI and API-heavy backends — backpressure that never burns retries, a three-signal ack protocol, per-job audit trails, and queue templates for LLM workloads, all included.
| Feature | SimpleQ | BullMQ + Redis |
|---|---|---|
| Managed | Yes — no infra to run | No — requires Redis |
| Delivery model | Push (webhook POST) | In-process worker (pull) |
| Retries | Configurable backoff (exponential/fixed) | Configurable backoff |
| Rate limiting | Per-queue fixed-window, built-in | Rate limiter extension (requires extra Redis config) |
| Ack mode | Three-signal protocol: ack (success), nack (failure with retryable flag), defer (backpressure — redelivers without burning attempts). Once the callback returns 200, the outcome is guaranteed. | No — job succeeds or fails in the worker process. No backpressure signal. |
| Backpressure | 429/503/529 auto-defers with Retry-After relay. Ack-mode /defer does the same. Neither burns a retry attempt — a job can ride out 100 consecutive 429s and still complete. | Manual — throw an error to trigger retry. Every retry counts against maxAttempts. |
| Dead-letter queue | Built-in with single + bulk replay via API and dashboard | Failed job retention (manual retry) |
| Idempotency | Publish-boundary dedup — returns existing job ID on duplicate, safe-to-retry publishers | Manual — caller must check for existing jobs |
| Queue templates | template: "anthropic" or "openai" — one field configures ack mode, timeout, and backoff tuned for each provider's API | None |
| Per-job audit trail | Full attempt history: status, error, HTTP code, timestamp per attempt | Bull Board (community) or BullMQ Pro dashboard |
| Webhook signing | HMAC-SHA256 with per-queue secret — a leaked secret affects one queue, not the org | N/A (in-process, no webhook) |
| AI workload support | Anthropic and OpenAI queue templates, seconds convention matching provider Retry-After headers, ack mode for long LLM calls | None |
| Priorities | No | Yes (priority queues) |
| Repeatable jobs | No (cron not supported yet) | Yes (cron + every-N patterns) |
| Flows/dependencies | No | Yes (parent-child flows) |
| Dashboard | Built-in real-time dashboard | Bull Board (community) or BullMQ Pro |
| Pricing | Free during early access | Free (OSS) + Redis hosting costs |
When to choose SimpleQ
- You don't want to run Redis. No provisioning, patching, monitoring, scaling, or debugging OOM kills on a stateful data store.
- Your downstream APIs return 429s and every retry burns one of your 3-5 attempts. With BullMQ, throwing an error triggers a retry that counts. SimpleQ's defer mechanism holds the job and redelivers after the Retry-After delay — no attempt burned. A job can ride out 100 consecutive 429s and still complete.
- Your work takes longer than 15 seconds. BullMQ workers process jobs synchronously — if your LLM call takes 60 seconds, the worker is blocked. SimpleQ's ack mode lets your handler return 200 immediately, then report success, failure, or backpressure through three distinct callbacks.
- You want one POST to configure a production-ready AI queue.
template: "anthropic"or"openai"sets ack mode, timeout, and exponential backoff tuned for each provider's API. - You want push delivery to a webhook instead of running persistent worker processes. Your worker is a plain HTTP endpoint — deploy it anywhere, in any framework.
- A job failed and you need the full story. SimpleQ logs every attempt with status, error, HTTP code, and timestamp. No Bull Board setup required.
- You want DLQ with replay built into the API and dashboard — not manual job-ID lookups and re-publishes.
When to choose BullMQ
- You need priority queues, parent-child flows, or repeatable (cron) jobs — BullMQ has richer job-orchestration primitives.
- You want in-process workers with direct access to your application context — no HTTP serialization overhead.
- You want open-source with no vendor dependency and full control over the queue internals.
Migrating from BullMQ?
Your job-processing logic stays the same — the shell changes. With BullMQ, your worker pulls jobs from Redis in-process. With SimpleQ, you expose a webhook endpoint that receives the job as a POST. Return 2xx on success, or use ack mode for long-running work: return 200 immediately, then call /ack, /nack, or /defer when the work resolves. The infrastructure you drop: Redis provisioning, monitoring, scaling, worker process management. What you gain: managed backpressure, per-job audit trails, DLQ replay, and per-queue signing secrets. If you're calling LLM APIs, start with template: "anthropic" or "openai".