{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/budget-connections-before-parallel-postgresql-dumps/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/budget-connections-before-parallel-postgresql-dumps/",
        "slug": "budget-connections-before-parallel-postgresql-dumps",
        "url": "https://update.dsesecurity.com/updates/budget-connections-before-parallel-postgresql-dumps/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/budget-connections-before-parallel-postgresql-dumps.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/budget-connections-before-parallel-postgresql-dumps/"
        },
        "title": "Budget connections before parallel PostgreSQL dumps",
        "summary": "Set a connection budget and lock-aware maintenance window before enabling parallel PostgreSQL dumps.",
        "format": {
            "slug": "guide",
            "name": "Guide"
        },
        "priority": {
            "slug": "info",
            "name": "Information"
        },
        "featured": false,
        "image": {
            "theme": "continuity-recovery",
            "label": "Continuity & recovery",
            "alt": "Paired infrastructure paths converging on a stable recovered service.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20",
            "width": 2400,
            "height": 1350
        },
        "topics": [
            {
                "slug": "business-continuity",
                "name": "Business Continuity",
                "url": "https://update.dsesecurity.com/topic/business-continuity/"
            },
            {
                "slug": "it",
                "name": "IT",
                "url": "https://update.dsesecurity.com/topic/it/"
            }
        ],
        "author": {
            "name": "DSE Security Editorial Team",
            "url": "https://update.dsesecurity.com/#editorial-team",
            "type": "Organization"
        },
        "publisher": {
            "name": "Detection Systems & Engineering",
            "url": "https://dsesecurity.com/"
        },
        "published_at": "2026-10-15T13:32:23+00:00",
        "modified_at": "2026-10-15T13:36:14+00:00",
        "reviewed_on": "2026-10-15",
        "reading_minutes": 2,
        "word_count": 243,
        "potentially_affected": "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.",
        "primary_source": {
            "name": "PostgreSQL 17 — pg_dump",
            "url": "https://www.postgresql.org/docs/17/app-pgdump.html",
            "published_on": null,
            "authority": "www.postgresql.org"
        },
        "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
        "usage_info": "https://update.dsesecurity.com/usage/",
        "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
        "content_html": "<p>Set a connection budget and lock-aware maintenance window before enabling parallel PostgreSQL dumps.</p>\n<h2>Source facts</h2>\n<p>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.</p>\n<p>Source: <a href=\"https://www.postgresql.org/docs/17/app-pgdump.html\">PostgreSQL 17 — pg_dump</a>.</p>\n<h2>Applicability</h2>\n<p>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.</p>\n<h2>DSE recommendation</h2>\n<p>DSE recommends setting a worker budget alongside the application&#8217;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.</p>\n<h2>Verification</h2>\n<p>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.</p>\n<h2>Official reference</h2>\n<p><a href=\"https://www.postgresql.org/docs/17/app-pgdump.html\">PostgreSQL 17 — pg_dump</a>. Reviewed October 15, 2026.</p>",
        "content_text": "Set a connection budget and lock-aware maintenance window before enabling parallel PostgreSQL dumps.\nSource facts\nPostgreSQL 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.\nSource: PostgreSQL 17 — pg_dump.\nApplicability\nThis 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.\nDSE recommendation\nDSE 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.\nVerification\nIn 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.\nOfficial reference\nPostgreSQL 17 — pg_dump. Reviewed October 15, 2026.",
        "content_markdown": "Set a connection budget and lock-aware maintenance window before enabling parallel PostgreSQL dumps.\n\n## Source facts\n\nPostgreSQL 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.\n\nSource: [PostgreSQL 17 — pg_dump](https://www.postgresql.org/docs/17/app-pgdump.html).\n\n## Applicability\n\nThis 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.\n\n## DSE recommendation\n\nDSE 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.\n\n## Verification\n\nIn 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.\n\n## Official reference\n\n[PostgreSQL 17 — pg_dump](https://www.postgresql.org/docs/17/app-pgdump.html). Reviewed October 15, 2026."
    },
    "json_ld": {
        "@context": "https://schema.org",
        "@graph": [
            {
                "@type": "Organization",
                "@id": "https://dsesecurity.com/#organization",
                "name": "Detection Systems & Engineering",
                "alternateName": "DSE Security",
                "url": "https://dsesecurity.com/",
                "logo": {
                    "@type": "ImageObject",
                    "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20"
                }
            },
            {
                "@type": "Organization",
                "@id": "https://update.dsesecurity.com/#editorial-team",
                "name": "DSE Security Editorial Team",
                "url": "https://update.dsesecurity.com/",
                "parentOrganization": {
                    "@id": "https://dsesecurity.com/#organization"
                }
            },
            {
                "@type": "WebSite",
                "@id": "https://update.dsesecurity.com/#website",
                "name": "DSE Updates",
                "alternateName": "DSE Security Knowledge Hub",
                "url": "https://update.dsesecurity.com/",
                "inLanguage": "en-US",
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "potentialAction": {
                    "@type": "SearchAction",
                    "target": {
                        "@type": "EntryPoint",
                        "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}"
                    },
                    "query-input": "required name=search_term_string"
                }
            },
            {
                "@type": "WebPage",
                "@id": "https://update.dsesecurity.com/updates/budget-connections-before-parallel-postgresql-dumps/",
                "url": "https://update.dsesecurity.com/updates/budget-connections-before-parallel-postgresql-dumps/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-10-15"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/budget-connections-before-parallel-postgresql-dumps/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Budget connections before parallel PostgreSQL dumps",
                        "item": "https://update.dsesecurity.com/updates/budget-connections-before-parallel-postgresql-dumps/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/budget-connections-before-parallel-postgresql-dumps/#article",
                "identifier": "https://update.dsesecurity.com/updates/budget-connections-before-parallel-postgresql-dumps/",
                "url": "https://update.dsesecurity.com/updates/budget-connections-before-parallel-postgresql-dumps/",
                "headline": "Budget connections before parallel PostgreSQL dumps",
                "description": "Set a connection budget and lock-aware maintenance window before enabling parallel PostgreSQL dumps.",
                "abstract": "Set a connection budget and lock-aware maintenance window before enabling parallel PostgreSQL dumps.",
                "articleBody": "Set a connection budget and lock-aware maintenance window before enabling parallel PostgreSQL dumps.\nSource facts\nPostgreSQL 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.\nSource: PostgreSQL 17 — pg_dump.\nApplicability\nThis 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.\nDSE recommendation\nDSE 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.\nVerification\nIn 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.\nOfficial reference\nPostgreSQL 17 — pg_dump. Reviewed October 15, 2026.",
                "datePublished": "2026-10-15T13:32:23+00:00",
                "dateModified": "2026-10-15T13:36:14+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/budget-connections-before-parallel-postgresql-dumps/"
                },
                "inLanguage": "en-US",
                "isAccessibleForFree": true,
                "author": {
                    "@type": "Organization",
                    "name": "DSE Security Editorial Team",
                    "url": "https://update.dsesecurity.com/#editorial-team"
                },
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "image": {
                    "@type": "ImageObject",
                    "@id": "https://update.dsesecurity.com/updates/budget-connections-before-parallel-postgresql-dumps/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Budget connections before parallel PostgreSQL dumps"
                },
                "articleSection": [
                    "Business Continuity",
                    "IT"
                ],
                "keywords": [
                    "Business Continuity",
                    "IT",
                    "Guide",
                    "Information priority"
                ],
                "genre": "Guide",
                "about": [
                    {
                        "@type": "Thing",
                        "name": "Business Continuity",
                        "url": "https://update.dsesecurity.com/topic/business-continuity/"
                    },
                    {
                        "@type": "Thing",
                        "name": "IT",
                        "url": "https://update.dsesecurity.com/topic/it/"
                    }
                ],
                "wordCount": 243,
                "timeRequired": "PT2M",
                "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
                "usageInfo": "https://update.dsesecurity.com/usage/",
                "copyrightHolder": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
                "citation": {
                    "@type": "CreativeWork",
                    "name": "PostgreSQL 17 — pg_dump",
                    "url": "https://www.postgresql.org/docs/17/app-pgdump.html"
                }
            }
        ]
    }
}