Budget connections before parallel PostgreSQL dumps

Set a connection budget and lock-aware maintenance window before enabling parallel PostgreSQL dumps.

Source facts

PostgreSQL 17 supports parallel pg_dump jobs only with directory-format output. A run with N workers opens N plus one database connections, and additional workers increase server load. Concurrent requests for exclusive table locks can make a parallel dump fail: a worker cannot safely wait behind the conflicting lock while the leader holds its own shared lock. Directory and custom archives both support parallel restoration, but that does not make custom-format dumping parallel.

Source: PostgreSQL 17 — pg_dump.

Applicability

This applies to PostgreSQL 17 logical backups using pg_dump. It addresses scheduling and output-format decisions, rather than physical backups or a promise of faster completion.

DSE recommendation

DSE recommends setting a worker budget alongside the application’s connection reserve, rather than selecting workers from CPU count alone. Put schema migrations outside the planned dump window, retain standard-error output, and make a failed job visible to the backup owner. Compare a conservative parallel run with the existing serial process using representative data. Record the chosen format in the recovery instructions so the operator knows which restore tool and archive directory to retrieve.

Verification

In a nonproduction database, check connection consumption during a small parallel dump and inspect its complete archive listing afterward. Rehearse a restore using that directory. Keep the exit code, warnings, elapsed time, and application checks as separate evidence; archive creation alone is insufficient.

Official reference

PostgreSQL 17 — pg_dump. Reviewed October 15, 2026.