pg-boss

pg-boss is a free, MIT-licensed job queue built in Node.js that uses PostgreSQL for background processing and asynchronous execution. It supports PostgreSQL and compatible backends including CockroachDB, YugabyteDB, Citus, and embedded PGlite. Workers use PostgreSQL SKIP LOCKED to claim jobs without blocking one another, and a job can be saved in the same transaction as the data change it supports. Delivery is at least once, so a handler may run more than once for a job. Queue controls include priorities, rate limits, debouncing, concurrency policies, retries with exponential backoff, and dead-letter queues. Scheduling includes cron and RRULE patterns, job deferral, and dependency-based workflows. Transaction adapters are available for Knex, Kysely, Drizzle, and Prisma; optional packages provide a web dashboard and JSON HTTP API. It requires Node 22.12 or higher or Bun, plus PostgreSQL 13 or higher. The default shared job table can affect performance if a queue grows substantially or develops an unexpected backlog.

pg-boss offers a broad set of queue and scheduling controls while keeping jobs in PostgreSQL. Teams should account for its runtime and database requirements, and design handlers for at-least-once delivery.

It suits teams already using PostgreSQL who want background jobs without operating another system. The documentation points to users comfortable with SQL, relational database behavior, querying, and backups.

pg-boss is a Node.js job queue that keeps background work in PostgreSQL rather than introducing a separate queue service. It is aimed at teams already running PostgreSQL and comfortable with SQL, relational semantics, and database operations. Its transaction coupling is a substantial advantage, but shared-table scaling and at-least-once delivery require disciplined operations and idempotent handlers.

Overview

A job can be inserted in the same database transaction as the application change it serves. If that transaction fails, the job is not committed either, which prevents workers from acting on state that never became durable. PostgreSQL's SKIP LOCKED allows multiple workers to claim work without waiting on one another, while atomic commits protect the claim-and-process lifecycle.

Delivery is explicitly at least once. A handler can receive the same job again, so applications must make repeated execution safe. The default design also places all queues in one partitioned job table. A queue with major growth or an unforeseen backlog can therefore put pressure on other queues sharing that table; teams should plan capacity and queue behavior accordingly.

Key features

Queue policies cover retries with exponential backoff, rate limiting, debouncing, priorities, concurrency controls, and dead-letter queues. In practice, these controls help smooth bursts, prevent noisy work from consuming all workers, and quarantine jobs that repeatedly fail. They are useful policy primitives, but they do not compensate for handlers that are unsafe to run twice.

Scheduling includes cron and RRULE expressions, delayed jobs, and dependency-based workflow orchestration. That combination suits recurring maintenance and multi-step processes without requiring a second scheduler. Workers poll with backpressure awareness, and optional PostgreSQL LISTEN/NOTIFY can provide millisecond-level delivery latency when prompt wakeups matter.

Transaction adapters are supplied for Knex, Kysely, Drizzle, and Prisma. Supported database backends include PostgreSQL, CockroachDB, YugabyteDB, Citus, and embedded PGlite, giving database-centric teams room to fit the queue to an existing deployment. OpenTelemetry traces and metrics can continue a job trace from send() through worker processing, improving visibility into asynchronous paths.

The @pg-boss/dashboard package adds a web interface for monitoring and managing jobs, queues, and schedules. The @pg-boss/proxy package exposes methods through a JSON HTTP API for non-Node runtimes, connection pooling, or scaling out access. Optional basic authentication, configurable CORS, and route allowlists or denylists provide useful boundary controls for that proxy.

Pricing

pg-boss — free. This is MIT-licensed open source, runs in your own database, and has no per-job charges. There is no free trial because the product itself is free. The trade-off is operational responsibility: you provide the Node.js or Bun runtime, PostgreSQL infrastructure, backups, upgrades, and support arrangements.

Platforms

pg-boss is offered as an API and web-facing tooling for Linux and self-hosted deployments. Official SDK languages are JavaScript and TypeScript. Requirements are Node 22.12 or newer, or Bun, together with PostgreSQL 13 or newer.

Who it's for

This is a strong fit for a team that already runs PostgreSQL and wants jobs to participate in application transactions, avoiding another system to operate and monitor. It also suits engineers who need rich queue policies, recurring schedules, dependency workflows, and database-level observability in a self-hosted stack.

It is a poor match for teams seeking a managed, language-agnostic queue with minimal database administration, or for handlers that cannot be made safe under duplicate delivery. The single shared job table deserves particular scrutiny before high-volume adoption.

Pros and cons

Pros

• Transactional consistency: enqueue work alongside the data mutation it belongs to, so rollback removes both.
• Broad control surface: retries, backoff, priorities, limits, debouncing, concurrency policies, and dead-letter queues cover common production failure modes.
• Scheduling and workflows: cron, RRULE, deferral, and dependencies handle recurring and multi-stage jobs in one system.
• PostgreSQL flexibility: adapters for major Node ORMs and support for several PostgreSQL-compatible backends reduce integration friction.
• Self-hosted economics: MIT licensing and no per-job fees keep direct software cost at zero.

Cons

• Duplicate execution is normal: at-least-once delivery makes idempotent handler design mandatory.
• Shared-table pressure: a large backlog in one queue can affect others unless capacity is managed carefully.
• Infrastructure burden: teams own the runtime, database, backups, security response, and ongoing maintenance; the project is maintained by one person.
• Runtime constraints: Node 22.12+ or Bun and PostgreSQL 13+ exclude older environments.

Alternatives

Choose Google Tasks instead for personal task lists, subtasks, due dates, and notifications across Android, iOS, and the web; it is not a background job queue.

IronWorker is worth considering when a freemium hosted-and-self-hosted worker product with explicit concurrency, runtime, memory, and scheduled-task allowances is preferable.

Pick JobRunr if its freemium model and recurring-job limits better match your deployment.

River offers an open-source option with a web UI and no concurrency limits, while its Open Source plan has no workflows or support; choose it when those trade-offs are acceptable.

Use RQ (Redis Queue) when you want a Python-oriented, BSD-licensed queue backed by Redis or Valkey instead of PostgreSQL.

Sidekiq fits teams choosing a Ruby ecosystem, with an OSS tier and a paid Enterprise tier starting at $269 per month.

Choose Upstash QStash for an HTTP-oriented service with a free allowance of 1,000 messages per day and a 7-day maximum delay.

Celery is the alternative when an open-source distributed task queue installed through PyPI or from source is the priority.

Verdict

Choose pg-boss if your team already operates PostgreSQL and wants queue work to commit atomically with application data, plus serious scheduling and delivery controls at no software charge. Look elsewhere if you need managed operations, older runtime support, or exactly-once-style handler behavior without designing for repeats; the shared table and self-hosted responsibilities are the decisive cautions.