BullMQ
Redis-based job and message queue for Node.js/TypeScript with priority queues, rate limiting, job scheduling, and parent-child job dependencies. BullMQ Pro adds additional features including batching and observability.
Score Breakdown
⚙ Agent Friendliness
🔒 Security
Redis-based queue — Redis auth is the security boundary. Use Redis AUTH and TLS in production. Job data stored in Redis — encrypt sensitive payloads.
⚡ Reliability
Best When
A Node.js/TypeScript agent needs reliable background job processing with priorities, rate limiting, and retry logic backed by Redis.
Avoid When
You need cross-language workers, durable multi-step saga patterns, or managed infrastructure without Redis.
Use Cases
- • Dispatching background jobs from Node.js agents with retry and priority control
- • Rate-limited API call queuing to stay within provider limits
- • Scheduled and delayed job execution from automated workflows
- • Fan-out patterns with parent-child job dependencies and flow producers
- • Processing AI pipeline steps as ordered, retriable job sequences
Not For
- • Non-Node.js environments (official SDK is Node.js only; use Celery for Python)
- • Long-running durable workflows requiring persistent state beyond Redis TTL
- • Teams without Redis infrastructure
- • Very high-throughput messaging at Kafka scale (Redis is the bottleneck)
Interface
Authentication
No built-in auth API. Authentication is delegated entirely to Redis connection credentials. No API key, token, or HTTP interface. Access control is at the Redis/network layer.
Pricing
OSS BullMQ covers most production use cases at no cost. BullMQ Pro adds enterprise features. Redis infrastructure is the primary operational cost. Bull (the predecessor) is deprecated in favor of BullMQ.
Agent Metadata
Known Gotchas
- ⚠ No REST API — agents must be Node.js applications or use a custom REST wrapper
- ⚠ Redis memory usage grows if completed/failed jobs are not periodically pruned — configure removeOnComplete and removeOnFail
- ⚠ Stalled job detection requires correct lockDuration — too short causes false-positive stalled detection and duplicate processing
- ⚠ Workers must explicitly handle SIGTERM for graceful shutdown — unhandled shutdown leaves jobs in active state
- ⚠ Parent-child job dependencies require Flow Producer — not all job relationship patterns are supported
- ⚠ Rate limiter uses Redis time — clock skew between workers and Redis can cause unexpected rate limit behavior
- ⚠ Bull (v3) and BullMQ (v4+) are incompatible — do not mix clients against the same Redis queue
Alternatives
Full Evaluation Report
Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for BullMQ.
Scores are editorial opinions as of 2026-03-06.