February 17, 2026
Background jobs, foreground beef
pg_background: Make Postgres do the long work (while your session stays light)
Dev joy meets DBA dread as Postgres gets a 'do it later' superpower
TLDR: Pg_background lets Postgres run long tasks in the background so apps stay fast; the v2 release adds safer controls and monitoring. Comments split between excitement for fewer moving parts and warnings from DBAs about abuse and worker limits, with calls for clearer docs on canceling runaway jobs.
Postgres just got a “do the heavy lifting later” button, and internet lit up. pg_background lets the database run long jobs in the background so your app can keep moving. The v2 update adds safer “handles” (process ID plus secret cookie), clearer cancel vs detach rules, and improved observability. Translation: fire off a job, check on it, wait, or walk away—without blocking your current work. The catch? Background workers consume a fixed pool of slots, so size it wisely. Recent releases promise production hardening, safer errors, memory cleanup, and PostgreSQL compatibility.
Then came the comments. tomrod wants more docs, especially on “how do I kill a runaway worker?” Meanwhile pragmatic dropped a bomb: “Every DBA’s nightmare… ripe for abuse.” Cue the split: devs cheering fewer moving parts, DBAs clutching their pearls over turning the database into a job system. One joker dubbed it “cron but make it Postgres,” another quipped, “Detach isn’t cancel—so don’t ghost your queries.”
The drama boils down to control vs risk: keep work inside the database for simpler ops, or push jobs to external queues. The docs say it’s a sharp tool, not a scheduler; the crowd says powerful, yes—just don’t burn down your worker pool.
Key Points
- •pg_background runs SQL asynchronously inside PostgreSQL server background workers, allowing client sessions to continue.
- •Each worker has its own transaction, enabling autonomous commit/rollback independent of the caller.
- •The recommended v2 API uses a (pid, cookie) handle to prevent PID reuse issues and adds cancellation, detach, wait, and monitoring functions.
- •Installation is via standard extension build and CREATE EXTENSION; workers consume max_worker_processes and must be sized deliberately.
- •Recent releases: v1.6 (Feb 5, 2026) focused on production stabilization and v2; v1.7 (Feb 13, 2026) improved security and memory management.