There’s a special kind of joy in watching a database do something heavy… without making your app threads cry.
That’s the promise of pg_background: execute SQL asynchronously in background worker processes inside PostgreSQL, so your client session can move on—while the work runs in its own transaction.
It’s a deceptively simple superpower:
Kick off a long-running query (or maintenance) without holding the client connection open
Run “autonomous transaction”-style side effects (commit/rollback independent of the caller)
Monitor, wait, detach, or cancel explicitly
Keep the operational model “Postgres-native” instead of adding another job system
What pg_background is (and what it isn’t)
pg_background enables PostgreSQL to execute SQL commands asynchronously in dedicated background worker processes. Unlike approaches such as opening another connection (e.g., dblink) or doing client-side async orchestration, these workers run inside the server with local resources and their own transaction scope.
It’s not a full-blown scheduler. It’s not a queueing platform. It’s a sharp tool: “run this SQL over there, and let me decide how to interact with it.”
... continue reading