Open-source background jobs for Next.js: BullMQ vs Trigger.dev vs pg-boss vs Hatchet vs Inngest (2026)

Quick answer (August 2026)

If you want open-source background jobs for a Next.js SaaS in 2026, there is no single winner, only a right pick for how much infrastructure you want to own. Reach for BullMQ when you already run Redis and want a battle-tested worker library you control end to end. Reach for pg-boss when your only stateful dependency is Postgres and you refuse to add Redis just for a queue. Reach for Trigger.dev or Hatchet when you want a real orchestration layer with a dashboard, retries, and long-running steps, and you are willing to self-host the platform. And keep Inngest on the shortlist for event-driven, serverless-first work, as long as you read its licensing carefully before you plan to self-host. All star counts, licenses, and versions below were read from each project's GitHub on August 4, 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.

The five 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. 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.

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.

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, from open-source internal tools builders to the boilerplates you start from.

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.