Background Jobs in Node.js 2026: BullMQ, Trigger.dev, or Inngest?
Compared on real client projects: BullMQ vs Trigger.dev vs Inngest for Node.js background jobs. What I pick for what, with cost, DX, and operational trade-offs.
Why this comparison matters
Every non-trivial Node.js app needs background work — sending emails, processing webhooks, running scheduled tasks, chunking heavy work out of the request cycle.
In 2026, the three options I see actually used in production are BullMQ (self-hosted with Redis), Trigger.dev (hosted), and Inngest (hosted, durable execution model).
I've shipped client work on all three in the last year. Here's the comparison.
BullMQ — self-hosted, Redis-backed
The OG. A queue library backed by Redis. Mature, battle-tested, used everywhere.
Strengths:
Weaknesses:
Pick when:
Trigger.dev — hosted, "background functions"
A managed service where you write background functions in your codebase and Trigger handles the runtime, retries, scheduling.
Strengths:
Weaknesses:
Pick when:
Inngest — durable execution model
The newest mental model. Your background function is a "step function" — each step is durably saved, so if the worker dies, execution resumes at the last completed step.
Strengths:
Weaknesses:
Pick when:
My pick per project type
Simple SaaS background work (send emails, process webhooks)
Trigger.dev. Free tier covers most apps. Zero ops. Functions deploy with code.
Long-running, heavy processing (video transcoding, large data jobs)
BullMQ on a dedicated worker. Self-hosted, predictable cost, can run for hours.
AI agent backend (multi-step LLM workflows)
Inngest. Durable execution is exactly what AI agents need — each LLM call as a step, retry-friendly, the run survives worker crashes.
Web3 indexer (consume chain events, write to DB)
BullMQ. Long-running worker, predictable workload, Redis-backed.
Scheduled reports or batch jobs
Trigger.dev for cron-style, BullMQ if already self-hosted.
What changed my mind in 2026
Two specific moments:
Moment 1: shipped on BullMQ, regretted it
Built a SaaS on Vercel with BullMQ workers on Railway. Two services to deploy. Two sets of env vars. Two monitoring dashboards. When the Railway worker died at 2am, I noticed at 9am.
Moved to Trigger.dev. One deploy, one dashboard, same uptime, half the ops.
Moment 2: built an AI agent on Trigger.dev, regretted it
Multi-step LLM workflow: classify intent, then fetch context, then call tool, then format response. Each step is 2-5 seconds of LLM call.
On Trigger.dev v3, the workflow worked but the lack of native step-level durability meant a partial failure retried the whole chain. Wasted tokens, slow recovery.
Moved to Inngest, where each step is durably saved. Failures resume mid-flow. Token spend dropped 60 percent.
Cost reality (numbers from real client work)
For a SaaS at ~10K background jobs per day:
At ~100K jobs per day:
At ~1M jobs per day: BullMQ wins on cost by a wide margin. Hosted options are convenient but expensive at scale.
TL;DR
If you're choosing a background job stack for a Node.js project and want a second opinion before committing, contact me.
You might also like
Caching Strategies for Node.js APIs: Redis, In-Memory, and Edge
Five caching layers I use in production Node.js + Next.js APIs — in-memory LRU, Redis, edge CDN, stale-while-revalidate, and request coalescing. With when each one matters.
Building a Production REST API with Node.js and Express in 2026
Layered architecture, validation, error handling, auth, rate limiting, observability — the patterns I use to ship Node.js + Express APIs that don't fall over in production.
Building Production AI Agents with Claude 4.7 and Tool Use
What I learned shipping AI agents to production: tool design, prompt structure, durable execution, observability, and cost control. Practical patterns from real client work.