Node.js workflow engine or job queue? BullMQ, pg-boss, Trigger.dev, Hatchet, Temporal and Inngest (2026)

Quick answer (August 2026)

Most people searching for a Node.js workflow engine are actually holding two different problems at once, and the tools split cleanly along that seam. If you need this function to run later, reliably, you want a job queue: BullMQ when you already run Redis, pg-boss when Postgres is your only stateful service. If you need this multi-step process to survive a deploy, a crash and a three-day wait, you want a workflow engine with durable execution: Hatchet or Trigger.dev if you want a dashboard and a self-host escape hatch, Temporal if you want the category-defining orchestration engine and can afford to operate it, and Inngest if you are event-driven, serverless-first and will read the license before you plan to self-host.

The distinction matters more than any feature table, because picking a queue for a workflow problem is how teams end up hand-rolling retry state in Postgres columns eighteen months later. All star counts, licenses and versions below were read from each project's GitHub on August 4, 2026, except the Temporal figures, read August 19, 2026.

Every framed piece in this room is self-hostable and open in some meaningful way, which is the whole point of hanging them next to a Next.js app you actually own.

Job queue, workflow engine, or durable execution?

Three labels get used interchangeably in this space and they are not the same thing. Here is the taxonomy we use when someone asks which one they need.

Hatchet's own docs describe the product as helping teams build "mission-critical AI agents, durable workflows, and background tasks", and store "every task, DAG, event or agent invocation" in a durable event log. Temporal describes itself as "a distributed, scalable, durable, and highly available orchestration engine" (both read August 19, 2026). That is the vocabulary of the right-hand column. BullMQ and pg-boss make no such claim, and are better for it when the job really is just a job.

The practical test: write down the longest single unit of work in your app. If it is "send this email" the answer is a queue. If it is "start a trial, wait 14 days, check whether they converted, branch, then notify sales" the answer is a workflow engine, and you will want durable execution rather than a chain of scheduled jobs holding state in your own tables.

The six we hung on the wall

We only curate things a small team can run without a platform contract. Here is the shortlist, with the number that matters most to us up front: the license.

Stars and licenses read from GitHub on August 4, 2026, and August 19, 2026 for Temporal. Everything here speaks TypeScript natively, which is why it earns a place next to Next.js.

BullMQ, the Redis workhorse you operate

BullMQ is the one you already half-know. It is a Redis-backed message queue for Node (also Python, .NET, and more now), MIT licensed, at 9,240 stars and shipping fast, with v6.0.7 tagged on August 4, 2026. It is deliberately a library, not a platform: you install it, you point it at a Redis instance, and you write your own workers and your own dashboard, or you bolt on the community Bull Board UI.

The taste call: BullMQ is the least magical and the most yours. If you are already paying for Redis and you want jobs, retries, rate limiting, and repeatable schedules with zero new vendors in the diagram, this is the honest default. The cost is that concurrency, observability, and deployment of the worker process are your problem, not the library's. That is a feature if you like control and a chore if you wanted a dashboard for free.

pg-boss, jobs that live in the database you already run

pg-boss is the quiet pick we keep recommending. It is MIT licensed, 3,823 stars, on 12.27.0 as of August 3, 2026, and it does one opinionated thing: it runs a job queue entirely inside Postgres using SKIP LOCKED, with no Redis and no broker to babysit. For a small Next.js SaaS that already has a Postgres database and nothing else, that reduction in moving parts is worth more than any feature list.

The taste call: pg-boss wins on operational simplicity. Throughput tops out lower than a Redis-backed queue, and you will feel it if you push hundreds of thousands of jobs an hour, but most SaaS backends never get near that. If your instinct after reading the BullMQ section was "I do not want to run Redis just for a queue," this is your framed piece. It pairs especially well with the kind of database-first admin stack we covered in our open-source admin panel comparison.

Trigger.dev, managed orchestration you can self-host

Trigger.dev is the most-starred piece in the room at 15,892 stars, Apache-2.0 licensed, with v4.5.9 tagged on July 30, 2026. It is not a library, it is a platform: you write long-running tasks in TypeScript with steps, retries, waits, and scheduling, and you get a real dashboard, logs, and versioned deploys. The v3 and v4 lines made durable, long-running execution the headline, which is exactly what serverless functions are bad at.

The taste call: Trigger.dev gives you the ergonomics of a managed service with an Apache-2.0 escape hatch. Most teams will start on Trigger.dev Cloud because self-hosting the full platform (Postgres, Redis, object storage, and the orchestration services) is a real ops project, not a docker run. But the permissive license means the door is open, and for a comparison of open-source tools that door matters. If your jobs are long, branchy, and you want to watch them run, this is the taste pick.

Hatchet, the open-source orchestration layer

Hatchet is the newer frame and the one Redis-avoiders should look at hardest. It is MIT licensed, 7,663 stars, and it is a Postgres-backed distributed task queue with orchestration, a web UI, DAG-style workflows, and durable execution. In other words, it aims at the same problem as Trigger.dev but keeps Postgres as the single stateful dependency and stays under a permissive MIT license.

The taste call: Hatchet is what you pick when you want Trigger.dev's dashboard-and-orchestration experience but you philosophically (or operationally) want everything in Postgres and everything MIT. It is younger, so the ecosystem and edge-case docs are thinner, and self-hosting is still a platform to run rather than a dependency to import. But the trajectory is good, and for an ownership-first team it is the most interesting new arrival on the wall this year.

Temporal, the workflow engine the others are measured against

Temporal is the piece that defines the category, and the reason we widened this shelf. It is MIT licensed, its TypeScript SDK repo sits at 896 stars (read August 19, 2026), and the project describes itself as "a distributed, scalable, durable, and highly available orchestration engine used to execute asynchronous, long-running business logic." You write workflows and activities in TypeScript, the server persists every step, and a worker that dies mid-workflow picks up exactly where it stopped when it comes back.

The taste call: Temporal is the most capable and the least casual thing in this room. The programming model is genuinely different, because workflow code must be deterministic and replayable, and that is a real constraint to design around rather than a flag to set. Operationally it is a server with a database plus your own worker fleet, so it is the heaviest self-host on this list by a wide margin, and Temporal Cloud exists precisely because most teams would rather not run it. We hang it here anyway: if your problem is durable multi-step orchestration and you expect it to matter for years, this is the piece the rest are compared against. If your problem is "run this later," it is dramatic overkill.

Inngest, event-driven and serverless-first

Inngest is the event-driven option, 5,686 stars, and the reason it sits slightly apart in a gallery about open source. The SDK and local dev server are genuinely open and pleasant, and the step-function model (wrap code in steps, get automatic retries and concurrency on any runtime) fits Next.js App Router and serverless deploys cleanly. The nuance is the license: GitHub does not resolve the main repository to a standard OSI license (it reports a non-standard license), and self-hosting the durable engine is possible but is not the paved path the way the cloud product is.

The taste call: Inngest is a strong choice if you are event-driven and cloud-first and you value developer experience over the ability to fully own the runtime. If your hard requirement is a clean, permissive, self-host-anywhere license, read Inngest's terms before you commit, and compare that reading against the Apache-2.0 and MIT pieces above. We are flagging the license honestly, not scoring the product down for it.

How to choose, by how much you want to own

• You already run Redis and want control: BullMQ.
• Your only stateful service is Postgres and you want it to stay that way: pg-boss, or Hatchet if you also want a dashboard and orchestration.
• You want managed-style ergonomics with an open escape hatch: Trigger.dev.
• You are event-driven, serverless-first, and cloud is fine: Inngest, license read.
• Your longest unit of work spans days and must survive deploys: Temporal, or Hatchet if you want most of that promise without running a Temporal cluster.

The gallery bias is obvious and we will own it: the fewer new vendors and the more permissive the license, the higher it hangs. That is the same lens we bring to the rest of the stack, to the boilerplates you start from. If you only want the three most-shipped queue options judged head to head on price and hosting rather than this wider workflow-engine question, that narrower comparison lives in our Inngest vs Trigger.dev vs BullMQ breakdown.

The honest caveat

None of these is a decision you make forever. A queue is one of the easier things to swap later, because the surface area (enqueue a job, run a worker) is small. So optimize for the operational cost you will pay every week, not for the throughput number you will hit twice a year. For most small Next.js SaaS teams in 2026, that math points at Postgres-backed simplicity first, and Redis-backed muscle only once you have measured that you need it.