Trigger.dev vs BullMQ vs pg-boss: Best Background Jobs for Node.js (2026)

Every non-trivial web app needs background jobs: sending emails, processing images, syncing data, running reports. The question is how to manage them.

Trigger.dev offers a managed platform. BullMQ is the Redis-based workhorse. pg-boss uses your existing PostgreSQL. Here's how they compare.

Quick Comparison

Feature	Trigger.dev	BullMQ	pg-boss
Type	Managed platform (+ self-host)	Library (self-manage)	Library (self-manage)
Queue backend	Custom (cloud) / PostgreSQL (v3)	Redis	PostgreSQL
Dashboard	Built-in (excellent)	Bull Board (community)	None (build your own)
Cron/scheduling	Built-in	Built-in	Built-in
Retries	Configurable	Configurable	Configurable
Concurrency control	Yes	Yes	Yes
Long-running jobs	Yes (up to hours)	Limited by Redis memory	Yes
TypeScript	First-class	First-class	Good
Observability	Built-in traces + logs	Minimal (add your own)	Minimal
Free tier	50K runs/month	Free (self-host)	Free (self-host)
Pricing	From $0 (free tier)	Free + Redis costs	Free + Postgres costs

Trigger.dev: Managed Background Jobs

Trigger.dev is a managed platform for running background jobs, scheduled tasks, and long-running workflows. It handles infrastructure so you focus on business logic.

Strengths

Developer experience. Define jobs in TypeScript, deploy alongside your app. The SDK is clean and well-designed.

import { task } from "@trigger.dev/sdk/v3";

export const sendEmail = task({
  id: "send-welcome-email",
  retry: { maxAttempts: 3 },
  run: async (payload: { userId: string; email: string }) => {
    // Your email sending logic
    await resend.emails.send({
      to: payload.email,
      subject: "Welcome!",
      html: renderWelcomeEmail(payload.userId),
    });
  },
});

Built-in dashboard. Real-time visibility into every job: status, logs, traces, errors, and performance. No need to build monitoring.

Long-running tasks. Unlike serverless functions with 30-second timeouts, Trigger.dev supports jobs that run for minutes or hours. Perfect for data processing, AI pipelines, and complex workflows.

Managed infrastructure. No Redis to manage, no worker processes to keep alive, no scaling to figure out. Jobs just run.

Self-hostable (v3). Trigger.dev v3 can be self-hosted using Docker, backed by PostgreSQL.

Weaknesses

• Cost at scale. Free tier is generous (50K runs), but costs add up for high-volume workloads.
• Vendor dependency. Your job definitions are tied to Trigger.dev's SDK (though self-hosting mitigates this).
• Cold starts. Cloud-hosted jobs may have cold start latency.
• Newer platform. Less battle-tested than BullMQ at extreme scale.

Best For

Teams that want a managed solution, need long-running jobs, and value built-in observability. Ideal for serverless/Vercel deployments where you can't run persistent workers.

BullMQ: The Redis Powerhouse

BullMQ is the most popular background job library for Node.js. It uses Redis as its queue backend and provides battle-tested reliability.

Strengths

Battle-tested. Used in production by thousands of companies. Edge cases are well-handled, and the community has solved most problems you'll encounter.

Performance. Redis is fast. BullMQ can process tens of thousands of jobs per second with proper configuration.

Rich feature set. Priority queues, rate limiting, job dependencies (flows), repeatable jobs, delayed jobs, sandboxed processors, and event-driven architecture.

import { Queue, Worker } from 'bullmq';

const queue = new Queue('email', { connection: redis });

// Add a job
await queue.add('welcome', { userId: '123', email: 'user@example.com' });

// Process jobs
const worker = new Worker('email', async (job) => {
  await sendWelcomeEmail(job.data.userId, job.data.email);
}, { connection: redis, concurrency: 10 });

Flows. Define job dependencies — Job B runs only after Job A completes. Useful for multi-step workflows.

Mature ecosystem. Bull Board for dashboards, extensive documentation, and a large community.

Weaknesses

• Requires Redis. Another service to manage, monitor, and pay for. Redis memory costs can be significant for large job payloads.
• No built-in dashboard. Bull Board exists but it's basic compared to Trigger.dev's dashboard.
• Worker management. You manage worker processes — scaling, health checks, graceful shutdown.
• Observability is DIY. You add your own logging, tracing, and monitoring.
• Redis memory. Job data lives in Redis memory. Large payloads or millions of jobs require careful memory management.

Best For

Teams comfortable managing Redis who need high-throughput, battle-tested job processing. The default choice for most Node.js applications.

pg-boss: PostgreSQL-Backed Queues

pg-boss uses your existing PostgreSQL database as a job queue. No additional infrastructure needed.

Strengths

No extra infrastructure. If you have PostgreSQL (and you probably do), you already have everything needed. No Redis, no additional services.

import PgBoss from 'pg-boss';

const boss = new PgBoss(connectionString);
await boss.start();

// Add a job
await boss.send('welcome-email', { userId: '123', email: 'user@example.com' });

// Process jobs
await boss.work('welcome-email', async (job) => {
  await sendWelcomeEmail(job.data.userId, job.data.email);
});

ACID guarantees. Jobs are stored in PostgreSQL with full transactional support. Create a user AND queue a welcome email in the same transaction — if the transaction rolls back, neither happens.

Job persistence. Jobs survive restarts and crashes. PostgreSQL's durability guarantees apply to your job queue.

Scheduling. Built-in cron-like scheduling for recurring jobs.

Simple mental model. Jobs are rows in a table. Debug by querying the database. No Redis mysteries.

Weaknesses

• Lower throughput than BullMQ/Redis. PostgreSQL polling is slower than Redis pub/sub. Fine for hundreds of jobs/second, not thousands.
• Polling-based. pg-boss polls the database for new jobs (configurable interval). Not true real-time like Redis.
• Database load. Job processing adds load to your PostgreSQL instance. At high volumes, this can impact application queries.
• Fewer features. No job flows/dependencies, no priority queues (workaround with multiple queues), less sophisticated rate limiting.
• No dashboard. No built-in UI. Query the database or build your own.

Best For

Apps with moderate job volumes that want to avoid Redis infrastructure. Excellent for startups and small teams running everything on PostgreSQL.

Performance Comparison

Metric	Trigger.dev	BullMQ	pg-boss
Throughput	~1K jobs/sec (cloud)	10K+ jobs/sec	100-500 jobs/sec
Latency	50-200ms (cloud)	<10ms	100-500ms (polling)
Max job size	4MB	Limited by Redis memory	Limited by Postgres row size
Reliability	Platform-managed	Redis persistence	PostgreSQL ACID

For most applications, all three are fast enough. Performance only matters at extreme scale.

Decision Framework

Choose Trigger.dev When:

• You're deployed on serverless (Vercel, Netlify) and can't run persistent workers
• You need long-running jobs (minutes to hours)
• You want built-in observability without setup
• You value developer experience over infrastructure control
• You're a small team and don't want to manage Redis

Choose BullMQ When:

• You need high throughput (thousands of jobs/second)
• You already use Redis in your stack
• You want job flows and dependencies
• You need fine-grained control over job processing
• You're comfortable managing Redis and worker processes

Choose pg-boss When:

• You want zero additional infrastructure (PostgreSQL only)
• Job volume is moderate (up to hundreds/second)
• Transactional job creation is important (enqueue in same DB transaction)
• You're a small team or early-stage startup
• Simplicity is more important than throughput

Common Patterns

The Hybrid Approach

Some teams combine approaches:

• pg-boss for critical business jobs (transactional guarantees)
• BullMQ for high-throughput processing (image resizing, data pipelines)
• Trigger.dev for long-running workflows and scheduled tasks

Migration Path

Start simple, upgrade when needed:

1. pg-boss for your MVP (no extra infrastructure)
2. BullMQ when you need higher throughput or advanced features
3. Trigger.dev when you want managed infrastructure and observability

FAQ

Can I switch between these later?

Yes, but it requires rewriting job definitions and consumers. The concepts are similar across all three, so the migration is mostly mechanical — not architectural.

Do I need background jobs at all?

If any of these apply, yes: sending emails, processing uploads, syncing external APIs, generating reports, sending webhooks, running scheduled tasks. If your app only serves HTTP requests with no side effects, you might not need them yet.

What about AWS SQS or Google Cloud Tasks?

These are cloud-specific queue services. They work well but lock you into a cloud provider. BullMQ and pg-boss are cloud-agnostic. Trigger.dev works anywhere but has its own lock-in.

How do I monitor failed jobs?

Trigger.dev: built-in dashboard with alerts. BullMQ: Bull Board + custom alerting (send failed jobs to Sentry/PagerDuty). pg-boss: query the database for failed jobs + custom alerting.

The Verdict

• Trigger.dev for managed infrastructure, serverless deployments, and the best developer experience. Pay for convenience.
• BullMQ for high-throughput, battle-tested job processing. The industry standard for Node.js.
• pg-boss for simplicity and zero extra infrastructure. The pragmatic choice for most startups.

For most early-stage projects in 2026, pg-boss gets you running fastest with the least infrastructure. Graduate to BullMQ or Trigger.dev when your needs outgrow it.