PACKAGE · QUEUE

bullmq

Queue for messages and jobs based on Redis

WEEKLY DOWNLOADS 6.5M
STARS 9.2K
FORKS 662
OPEN ISSUES 382
GZIP SIZE 141.1 kB
UNPACKED SIZE 2.9 MB
DEPENDENCIES 5
LAST UPDATED 5mo ago
DOWNLOAD TRENDS

bullmq downloads — last 12 months

Download trends for bullmq1 download series from Aug 2025 to Jul 2026. Use left and right arrow keys to inspect monthly values.07.7M15.3M23.0M30.6MAug 2025NovFebMayJul 2026
bullmq
ABOUT BULLMQ

BullMQ is a robust job queue system built on top of Redis, designed to handle background tasks and message processing efficiently. It addresses the common challenge of decoupling time-consuming operations from the main application flow, preventing request timeouts and improving overall user experience.

Its core philosophy emphasizes reliability, scalability, and developer ergonomics, making it suitable for Node.js applications requiring dependable background job execution. The library is engineered for developers who need to manage complex job workflows, retries, and scheduling without compromising application responsiveness.

BullMQ exposes a clear and powerful API for job management, including methods like `add()`, `getJob()`, and `remove()`. It supports advanced features such as delayed jobs, repeatable jobs with cron syntax, and priority queues, allowing fine-grained control over job execution. The event-driven architecture with listeners for job states (completed, failed, etc.) facilitates real-time monitoring and error handling.

This package integrates seamlessly into various Node.js frameworks and architectures. Whether you're using Express, NestJS, or a custom server setup, BullMQ can be embedded to manage tasks like email sending, data processing, or external API calls. Its Redis dependency makes it a natural fit for microservices architectures where Redis is already in use for caching or inter-service communication.

With 7.7 million weekly downloads and 9.2K GitHub stars, BullMQ has demonstrated significant adoption and community trust. Its unpacked size of 2.9 MB and gzipped bundle size of 141.1 kB indicate a substantial but manageable footprint for its feature set, reflecting a balance between functionality and performance considerations.

While powerful, BullMQ relies heavily on Redis. Ensuring Redis availability and proper configuration is critical for queue operation. The current open issue count of 376 suggests that while actively maintained, there are ongoing areas for community contribution and potential bug fixes.

WHEN TO USE
  • When decoupling time-intensive tasks like image resizing or video encoding from synchronous user requests.
  • When implementing scheduled or repeatable background jobs using cron syntax for tasks like daily reports or cleanup scripts.
  • When requiring advanced job retry strategies with exponential backoff and customizable attempts.
  • When building distributed systems that need a reliable message broker for inter-service communication.
  • When prioritizing fault tolerance with features like job idempotency and robust error handling mechanisms.
  • When needing to monitor and manage job lifecycles via a Redis-backed queue, especially with support for priority levels.
WHEN NOT TO USE
  • If your application only requires simple in-memory task scheduling without persistence or distributed capabilities, consider using Node.js's built-in `setTimeout` or a simpler timer library.
  • If your background processing needs are met by leveraging serverless functions (e.g., AWS Lambda, Google Cloud Functions) triggered by events, direct integration might be more cost-effective.
  • When a distributed queue with Redis as a central dependency introduces unnecessary complexity or operational overhead for your specific deployment environment.
  • If you need a basic pub/sub mechanism for ephemeral message passing, Redis's native pub/sub capabilities or a dedicated messaging library might suffice with less overhead.
  • If the primary requirement is simple task queuing without complex scheduling, retry logic, or priority management, a lighter-weight queue implementation may be more suitable.

CORRECTIONS

Spot wrong data here?

A short note helps us fix it.

Anonymous · No account · No email back

COMPARISONS 2
bullmq vs agenda ★ 9.7K · 148.4K/wk bullmq vs bee-queue ★ 4.0K · 40.5K/wk