Skip to content

pg-boss

pg-boss is an open-source queue for JavaScript backends. It keeps jobs in PostgreSQL and uses a worker you run to process them.

Visit pg-boss

Can a record and its follow-up job be saved together?

Yes, when both writes use the same PostgreSQL transaction, a group of changes the database saves or cancels as one. Use a supported transaction adapter. The worker still needs to run to create the report after that transaction finishes.

The current project requires PostgreSQL 13 or later and Node.js 22.12 or later, or Bun. Check the versions and permissions of your own database and runtime.

Where does a job go after it keeps failing?

Set retry limits and delays for the queue. A configured dead-letter queue receives a copy of the failed job’s input after retries are exhausted. Give that review queue its own limits and decide who checks whether the work already happened before asking for another attempt.

The queue can limit overlapping or pending jobs depending on its policy. Give the app’s result a stable ID as well. A job rule cannot undo an outside action that happened before a failure. Queue retention controls how long you can inspect work, so keep important outcomes separately.

What stays yours if you move the queue?

pg-boss is MIT-licensed. Budget for PostgreSQL, worker hosting, retained jobs and backups. Keep the worker code and the rules that define retries, expiration, retention and how failed jobs are reviewed.

Before switching to another queue, compare pending report IDs with completed results. Decide which worker can act on each unfinished job so both systems do not process it.

How can you check that a failed save leaves no stray job?

Draw a fictional PostgreSQL transaction on paper. Do not connect a database or run a worker.

  1. Cancel one change
    Draw a report record and a matching pending job inside the same transaction. Cancel the save and check that neither becomes visible.
  2. Save another change
    Complete the transaction. Both the new record and its job should exist, but the report should still read Waiting.
  3. Mark a finished result
    Only after the worker’s pretend output exists should the app mark it Ready. Draw a separate review path for a job that uses up its retries.