Bull is in maintenance mode — should I stay or move to BullMQ?
Bull library is in legacy maintenance mode (bug fixes only); BullMQ is the actively developed fork with breaking API changes. Teams on Bull must choose to stay on a stale-but-stable library, migrate to BullMQ, or adopt an alternative such as node-resque.
Blockers
- BullMQ has breaking API changes from Bull, including Queue/Worker split, QueueEvents class, renamed cron option, disallowed integer job IDs, and moved concurrency configuration.
- BullMQ v5 made the Redis connection argument mandatory and changed the Redis marker key structure.
- Lock-in via package/bullmq-pro
- Lock-in via package/bullmq-pro
- Lock-in via package/bullmq-pro
- node-resque is a Node.js implementation of the Resque protocol.
- Bull is described as a Redis-backed job queue for Node.js.
- BullMQ is presented as the successor to Bull for Node.js job queues.
- node-resque is a Node.js implementation of the Resque protocol.
- Bull is Redis-backed.
- BullMQ requires an explicit Redis connection object.
- node-resque is backed by Redis.
Who this is for
- high-scale
- microservices
- low-ops
- enterprise
- small-team
Candidates
BullMQ
The actively maintained, TypeScript-native successor to Bull, backed by Taskforce.sh and released as v5.71.0 on March 11, 2026. MIT-licensed with 10M+ monthly npm downloads; a commercial BullMQ Pro add-on ($1,395/year for organizations under 100 employees as of 2026-03-18) unlocks job grouping, batch processing, and priority support. Key architectural difference from Bull: Queue, Worker, and QueueEvents are now separate classes, and an explicit Redis connection object is mandatory. Taskforce.sh achieved SOC 2 Type II certification in January 2026.
When to choose
Best for high-scale + microservices where you are starting a new project or willing to invest in a migration, and need long-term support, parent-child job flows, or rate limiting. The single most decisive factor is active development: only BullMQ receives new features.
Tradeoffs
Active development, TypeScript-first, parent-child job dependencies, deduplication, multi-language producers (Python, Elixir). Breaking API changes from Bull require significant refactoring: Queue/Worker split, QueueEvents class, cron option renamed to pattern, integer job IDs disallowed, concurrency moved to Worker constructor. Existing Bull job data is not guaranteed compatible — plan for parallel queue drain during migration.
Cautions
BullMQ v5 made the Redis connection argument mandatory and will throw at startup (not just warn) if omitted — existing Bull code that relies on implicit connection defaults will break immediately. The underlying Redis marker key structure changed in v5; running mixed Bull and BullMQ workers against the same Redis keys is unsupported and may silently drop jobs.
Bull (Legacy)
The original Redis-backed job queue for Node.js, now in maintenance mode: only bug fixes are accepted, no new features. It remains a stable, battle-tested option for teams already using it who cannot absorb migration costs. The API is callback- and promise-based with a single Queue class handling both enqueue and processing.
When to choose
Best for small-team + low-ops situations where you have a large existing Bull codebase, no immediate need for new queue features, and migration risk outweighs stagnation risk. Do not choose Bull for new projects as of 2026-03-18.
Tradeoffs
Zero migration cost for existing users; well-understood operational behavior; wide community knowledge base. Receives no new features; TypeScript support is via DefinitelyTyped rather than native types; no parent-child flows, deduplication, or multi-language support. Security fixes only; future Node.js or Redis compatibility issues may go unaddressed.
Cautions
Bull and BullMQ share the same Redis key namespace conventions but are not interoperable — you cannot have Bull producers feeding BullMQ workers or vice versa without a dedicated migration window. Staying on Bull indefinitely means accumulating dependency debt as the ecosystem moves to BullMQ.
node-resque
A Node.js implementation of the Resque protocol (originally a Ruby background job framework) backed by Redis, actively maintained by the Actionhero team at v9.5.0 as of early 2026. API-compatible with Ruby Resque and Sidekiq, making it the only Node.js queue option suitable for mixed Ruby/Node polyglot stacks. MIT-licensed, TypeScript-native since v6, with priority queues, delayed jobs, and a scheduler component.
When to choose
Best for microservices + enterprise teams running polyglot Ruby/Node.js stacks where Resque or Sidekiq compatibility is required, or where ops teams already manage Resque infrastructure. If your stack is Node.js-only, BullMQ's richer feature set and larger ecosystem make it the stronger default.
Tradeoffs
Unique Resque/Sidekiq wire-protocol compatibility; TypeScript-native; scheduler included in the package. Far smaller community (1.4k GitHub stars vs BullMQ's 8.6k); fewer advanced features (no parent-child flows, no rate limiting built-in, no multi-language SDK); the polling-based scheduler introduces Redis round-trip overhead compared to BullMQ's event-driven approach.
Cautions
node-resque's scheduler is a separate long-running process that must be kept alive — it is not embedded in the worker loop like BullMQ's delayed-job mechanism, which means an additional deployment unit and failure surface. The Resque wire protocol constrains job payload structure; migrating away from node-resque later requires re-enqueuing all jobs.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Bull is in maintenance mode — should I stay or move to BullMQ?"