2026 PostgreSQL-14-Upgrade: Wie viel Speicherplatz muss pg_upgrade reservieren?

Der benötigte pg_upgrade-Speicherplatz für PostgreSQL 14 lässt sich nicht mit einem für alle Datenbanken gültigen Aufschlag berechnen: Erfassen Sie zuerst Datenverzeichnisse, Tablespaces und WAL und kalkulieren Sie dann nach Copy-, Link- oder einem auf Ihrer Plattform unterstützten Clone-Modus. Das gilt besonders, wenn Sie die alte Instanz als Rückfallmöglichkeit behalten müssen; reichen Platz oder Wiederherstellungsnachweis nicht aus, sollte die Produktionsmigration warten.

Geeignet: für DBAs, die eine PostgreSQL-14-Produktivinstanz vor dem Supportende aktualisieren und dafür Speicherbedarf und Migrationsmodus festlegen müssen.
Ebenfalls geeignet: für SaaS-Verantwortliche und Backend- oder Plattformingenieure, die prüfen, ob das vorhandene Speichersystem für Zielcluster, Sicherung und Rückfall ausreicht.

Zuletzt geprüft am 04.11.2026 anhand der offiziellen PostgreSQL-Versionierungs- und pg_upgrade-Dokumentation. Die offizielle Versionsübersicht nennt den 12.11.2026 als Supportende für PostgreSQL 14. Prüfen Sie den Status unmittelbar vor dem Wartungsfenster erneut auf der offiziellen PostgreSQL-Seite zu unterstützten Versionen.

Zuerst den tatsächlichen Platzbedarf statt einer Faustformel ermitteln

Die Größe einer Datenbank in einer Verwaltungsansicht ist nicht automatisch die Menge an Speicherplatz, die ein Upgrade benötigt. Für die Planung zählt, was auf den beteiligten Dateisystemen tatsächlich belegt ist und wo die jeweiligen Dateien liegen. Datenverzeichnis, Tablespaces und WAL können sich auf verschiedenen Mountpoints befinden. Ein freier Speicherwert auf dem Volume des Hauptdatenverzeichnisses sagt deshalb nicht, ob auch ein Tablespace-Volume genügend Platz hat.

Wie viel zusätzlichen Speicher sollte pg_upgrade bekommen? Einen festen Multiplikator gibt es nicht. Im Copy-Modus müssen die Dateien des neuen Clusters zusätzlich zu den noch vorhandenen Dateien des alten Clusters Platz finden. Im Link-Modus gelten andere Platzbedingungen, aber ein kleinerer Bedarf ist mit einem höheren Rückfallrisiko verbunden. Auch bei Clone hängt die Planung davon ab, ob die Umgebung die benötigte Klonfunktion unterstützt. Die Dokumentation zu pg_upgrade beschreibt die Unterschiede und Einschränkungen der Modi; sie liefert keine allgemeingültige Kapazitätszahl für jede Instanz.

Ermitteln Sie deshalb zuerst die konkreten Speicherorte und Belegungen. PostgreSQL erläutert die Verzeichnisstruktur und die mögliche Lage von Dateien in seiner Dokumentation zum Dateilayout. Tablespaces können Daten außerhalb des Hauptdatenverzeichnisses speichern; dokumentierte Pfade und Verknüpfungen sollten Sie in die Bestandsaufnahme aufnehmen, statt nur das Cluster-Hauptverzeichnis zu messen. Dafür ist die Dokumentation zu Tablespaces relevant.

WAL verdient eine eigene Zeile im Kapazitätsplan. Prüfen Sie, ob das WAL-Verzeichnis innerhalb des Datenverzeichnisses liegt oder ob es auf ein anderes Dateisystem verweist. Berücksichtigen Sie außerdem, ob während des Upgrade-Fensters Sicherungen, Replikation oder weitere Schreibvorgänge dort Platz beanspruchen. Verwenden Sie für die Messung die Belegung des jeweiligen Dateisystems und prüfen Sie sowohl die Mountpoints als auch die Verzeichnisse, auf die PostgreSQL tatsächlich zugreift.

Erster Schritt: Verzeichnisse und Dateisysteme inventarisieren

Führen Sie die Bestandsaufnahme zunächst in einer kontrollierten Sitzung durch und dokumentieren Sie die Ergebnisse so, dass ein anderes Teammitglied sie vor der Migration überprüfen kann. Die folgende Liste ist zugleich das erste Entscheidungstool: Jeder offene Punkt steht für eine Annahme, die vor einem Produktionswechsel geklärt werden sollte.

• [ ] Den aktuellen Pfad des PostgreSQL-14-Datenverzeichnisses feststellen und seine tatsächliche Dateisystembelegung erfassen.
• [ ] Alle Tablespaces mit Pfad, zugrunde liegendem Dateisystem und tatsächlicher Belegung aufnehmen.
• [ ] Den Speicherort von WAL prüfen und feststellen, ob er auf einem eigenen Volume liegt oder auf das Datenverzeichnis verweist.
• [ ] Das vorgesehene Zielverzeichnis für den neuen Cluster festlegen und den freien Platz auf genau diesem Dateisystem messen.
• [ ] Für Sicherungen, temporäre Dateien und den Betrieb während der Migration eigene Speicherorte und Anforderungen notieren.
• [ ] Festhalten, welche Cluster- und Tablespace-Pfade bei Copy, Link oder Clone auf demselben Dateisystem liegen müssen.
• [ ] Die geplante Sicherung außerhalb des zu migrierenden Systems lokalisieren und ihre Wiederherstellbarkeit nachweisen.

Die letzte Prüfung ist keine Formalität. Eine vorhandene Sicherungsdatei belegt noch nicht, dass sie sich wiederherstellen lässt. Planen Sie den nötigen Speicherplatz und die Zeit für eine Wiederherstellungsprobe in einer isolierten Umgebung ein. Die PostgreSQL-Dokumentation zu Sicherung und Wiederherstellung erläutert die verschiedenen Verfahren; die Dokumentation zu dateisystembasierten Sicherungen beschreibt zusätzliche Anforderungen für diese Sicherungsart.

Prüft pg_upgrade --check, ob genügend Speicherplatz vorhanden ist? Behandeln Sie den Lauf als Prüfung der Upgrade-Kompatibilität, nicht als Kapazitätszusage. Selbst wenn die Prüfung keine blockierende Inkompatibilität meldet, müssen Sie die freien Kapazitäten aller betroffenen Dateisysteme und die geplante Ablage der Zieldateien selbst verifizieren. Ein erfolgreicher Check ist daher kein Beleg, dass Copy, Sicherungen und Rückfall gleichzeitig in Ihr Speicherkonzept passen.

Entscheidung nach Szenario: Speicherknappheit im selben Dateisystem

Wenn alter und neuer Cluster auf demselben Dateisystem liegen sollen und kaum zusätzlicher Platz frei ist, kommt Link als mögliche Platz sparende Variante in Betracht. Der Modus nutzt Verknüpfungen für Datenbankdateien, statt alle Dateien wie beim Copy-Verfahren unabhängig zu kopieren. Daraus folgt jedoch keine pauschale Zusage, dass eine Migration mit beliebig wenig freiem Speicher gelingt: Die Verzeichnis- und Dateisystembedingungen müssen zum gewählten Modus passen, und die Belegung der weiteren Verzeichnisse bleibt zu berücksichtigen.

Kann pg_upgrade --link Platz sparen, ohne den Rückfall zu erschweren? Link kann den Bedarf für eine vollständige zweite Dateikopie verringern, ist aber kein kostenloser Rückweg. Nach dem Start des neuen Clusters kann der alte Cluster nicht unverändert als unabhängige, unverbrauchte Rückfallinstanz weiterverwendet werden. Wer den alten Cluster als verlässliche Rückfalloption benötigt, darf Link nicht allein wegen knappen Speicherplatzes auswählen. Lesen Sie die Bedingungen für Link und den Status des alten Clusters in der offiziellen pg_upgrade-Dokumentation für PostgreSQL 18, bevor Sie den Modus für die eigene Installation freigeben.

Prüfen Sie darüber hinaus, ob alle beteiligten Datenverzeichnisse und Tablespaces die vom gewählten Verfahren verlangten Dateisystembedingungen erfüllen. Ein Hauptdatenverzeichnis auf einem Volume und ein Tablespace auf einem anderen können die Beurteilung verändern. Eine Checkliste, die nur den freien Platz am Hauptverzeichnis erfasst, übersieht diese Abhängigkeiten.

Vor einem produktiven Einsatz von Link sollten mindestens diese Bedingungen erfüllt sein:

1. Die tatsächlichen Cluster- und Tablespace-Pfade sind dokumentiert, und die im Handbuch beschriebenen Dateisystembedingungen sind geprüft.
2. Die Sicherung liegt außerhalb des betroffenen Speichersystems und wurde in einer Testumgebung wiederhergestellt.
3. Die Anwendung kann für die Umstellung kontrolliert angehalten oder umgeschaltet werden, und die Verantwortlichen kennen die Rückfallgrenzen.
4. Das Team hat das Verfahren mit einer repräsentativen Kopie der eigenen Daten und derselben Speicheranordnung erprobt.

Kann eine dieser Voraussetzungen nicht bestätigt werden, ist ein Test in einer isolierten Zielumgebung in der Regel besser als ein auf Verdacht angesetzter Link-Lauf. Ein vermeintlicher Platzgewinn, der die Wiederherstellung nicht absichert, ist kein belastbares Betriebskonzept.

Speicher vorhanden: Copy und Clone nach Rückfallbedarf bewerten

Wenn genug Platz verfügbar ist und eine möglichst klare Trennung zwischen altem und neuem Cluster wichtig ist, ist Copy häufig leichter in die Rückfallplanung einzubeziehen: Der neue Cluster erhält eigene Dateien, während die alten Dateien zunächst erhalten bleiben. Dafür müssen Sie den belegten Platz des Quellclusters und die zusätzliche Belegung des Zielclusters gleichzeitig in der Kapazitätsrechnung berücksichtigen. Die für einen erfolgreichen Kopiervorgang benötigte Reserve ist abhängig von der konkreten Dateianordnung und den übrigen Vorgängen während der Migration; ein allgemeines Verhältnis zwischen Datenbankgröße und freiem Platz lässt sich daraus nicht ableiten.

Clone kann eine Alternative sein, wenn die Betriebssystem- und Dateisystemumgebung die benötigte Klonfunktion unterstützt. Die Dokumentation beschreibt damit verbundene Bedingungen; Sie sollten den Modus nicht als überall verfügbare schnelle Kopie behandeln. Prüfen Sie vorab, ob die in der PostgreSQL-18-Dokumentation zu pg_upgrade genannten Voraussetzungen auf dem Produktionssystem erfüllt sind. Wenn PostgreSQL 17 das tatsächliche Ziel ist, sind stattdessen die Dokumentation zu pg_upgrade für PostgreSQL 17 und deren Modusbedingungen maßgeblich. Maßgeblich ist die Dokumentation der tatsächlich eingesetzten Zielversion, nicht die eines anderen Releases.

Die Tabelle ersetzt keinen Test mit Ihrer tatsächlichen Verzeichnisstruktur. Besonders bei Clone sollten Sie die Unterstützung nicht aus einer anderen Installation ableiten: Betriebssystem, Dateisystem und die konkrete Ausführung müssen zu den dokumentierten Bedingungen passen. Bei Copy ist wiederum nicht nur die geplante Datenmenge relevant, sondern auch, ob Sicherung, WAL-Aufkommen und temporäre Dateien während des Wartungsfensters weitere Belegung verursachen.

Ist Copy oder Link für ein großes PostgreSQL-Upgrade sicherer? Das hängt davon ab, ob „sicherer“ hier möglichst klare Rückfallbedingungen oder möglichst wenig zusätzliche Dateikopie bedeutet. Wenn die alte Instanz unabhängig erhalten bleiben soll und die Speicherkapazität reicht, lässt sich Copy häufig einfacher in eine getrennte Rückfallplanung einordnen. Wenn der Speicher knapp ist, kann Link passend sein, sofern die Einschränkungen verstanden und die externe Sicherung nachweislich wiederherstellbar ist. Entscheiden Sie anhand dieser Bedingungen und eines Probelaufs, nicht allein anhand der Clustergröße.

Migration auf ein getrenntes Zielsystem getrennt berechnen

Bei einer Migration auf ein separates Zielsystem dürfen Sie den freien Platz der Quelle nicht als Platz des Zielsystems zählen. Der Quellcluster bleibt dort zunächst bestehen; der Zielcluster muss auf dem Zielsystem eingerichtet und befüllt werden. Erfassen Sie die Anforderungen deshalb für beide Seiten getrennt und nehmen Sie auch temporäre Dateien, Ziel-WAL und den Speicher für Sicherungen auf. Falls der gewählte Migrationsweg temporäre Kopien oder zusätzliche Synchronisierung erzeugt, muss deren Speicherbedarf aus dem konkreten Ablauf hervorgehen.

Verwenden Sie für diese Planung keine Kapazitätswerte aus einem fremden Erfahrungsbericht als Ersatz für Ihre eigene Messung. Datenmodell, Tabellenverteilung, Tablespace-Pfade und Migrationsverfahren unterscheiden sich. Erzeugen Sie in einer isolierten Umgebung eine repräsentative Kopie oder einen aussagekräftigen Testbestand, führen Sie die tatsächlich geplanten Schritte aus und messen Sie die Belegung auf jedem beteiligten Dateisystem.

Erstellen Sie dazu eine einfache Ressourcenübersicht mit separaten Spalten für Quelle, Ziel, Sicherung und temporäre Bereiche. Für jede Zeile sollten Verantwortliche, Pfad, aktueller Belegungsstand, erwartete Verwendung während des Upgrade-Fensters und gemessener freier Speicher nachvollziehbar sein. Wo ein Wert noch nicht gemessen wurde, kennzeichnen Sie ihn als offene Annahme und lassen Sie die Produktionsfreigabe davon abhängig sein.

Wenn ein anderes Verfahren als pg_upgrade zum Einsatz kommt, muss dessen Platzbedarf separat bewertet werden. Eine parallele Übertragung, eine Sicherungswiederherstellung oder eine zusätzliche Synchronisierung kann vorübergehend andere Kopien oder Protokolldaten erzeugen als der hier beschriebene Ablauf. Übernehmen Sie daher nicht einfach die Speicherannahmen aus einem Copy-, Link- oder Clone-Szenario in einen anderen Migrationsplan.

Rückfall und Sicherungen als eigene Speicheranforderungen behandeln

Drei Speicherfragen sollten in der Freigabe getrennt beantwortet werden: Wo liegt die Sicherung vor dem Upgrade? Wie lange und in welchem Zustand bleibt der alte Cluster verfügbar? Wo liegen Dateien und WAL des neuen Clusters? Wer diese Fragen zu einer einzigen „freien Reserve“ zusammenfasst, riskiert, dass ein für eine Aufgabe eingeplanter Speicherbereich für eine andere benötigt wird.

Eine getrennte Kopie auf demselben physischen Speicher schützt außerdem nicht gegen dessen Ausfall. Ebenso ist eine RAID-Konfiguration oder Datenbankreplikation kein Ersatz für eine Sicherung außerhalb des Servers. Wenn die eingesetzte Hardware kein Hardware-RAID bereitstellt, müssen Sie eine geeignete Software-Spiegelung oder Replikation selbst planen; auch damit bleibt eine externe, getestete Sicherung erforderlich. Die konkrete Speicherplanung muss zugleich berücksichtigen, dass Spiegelung oder Replikation verfügbare Kapazität beanspruchen können.

Vor der Produktionsmigration sollten die Verantwortlichen gemeinsam prüfen, ob die Sicherung wiederherstellbar ist, ob das Anwendungsumschaltverfahren dokumentiert wurde und welche Voraussetzungen für einen Rückfall nach dem gewählten Upgrade-Modus gelten. Bei Link darf die alte Datenstruktur nicht als automatisch unveränderte Ausweichinstanz eingeplant werden. Auch eine erfolgreiche Wiederherstellungsprobe beweist nicht, dass sich jede Anwendung ohne zusätzliche Anpassungen zurückschalten lässt; testen Sie die tatsächlichen Verbindungs- und Umschaltabläufe.

Serverkapazität erst nach dem Testlauf anpassen

Ergibt die Bestandsaufnahme, dass auf dem bestehenden Speichersystem die Dateien für den gewählten Modus, die Sicherung und die Rückfallplanung nicht gleichzeitig Platz finden, gibt es mehrere Wege: Speicherbedarf des tatsächlichen Ablaufs messen und unnötige Annahmen korrigieren, einen anderen zulässigen Modus mit seinen Rückfallfolgen bewerten oder ein separates Zielsystem für einen kontrollierten Test einplanen. Ein Serverwechsel allein beweist weder, dass der Migrationslauf schneller wird, noch dass die Daten sicherer sind.

Prüfen Sie bei der Auswahl eines Zielsystems die tatsächlich angebotenen Laufwerke, nutzbare Kapazität, Anschlussart und Erweiterungsmöglichkeiten in der jeweiligen Produktübersicht. Unter Konfigurationen für AMD-Server bei XFP Cloud können Sie die verfügbaren Serverkonfigurationen gegen Ihre zuvor ermittelte Kapazitätsliste halten. Für die Budgetplanung sind außerdem die tatsächlichen Abrechnungsbedingungen maßgeblich; sie stehen auf der Seite zu den Mietkosten bei XFP Cloud. Die dort ausgewiesene Konfiguration muss anhand Ihres Datenlayouts bewertet werden und ist keine Zusage für einen bestimmten Datenbankdurchsatz oder eine bestimmte Upgrade-Dauer.

Ein dedizierter AMD-Server ist dann eine sinnvolle Alternative, wenn ein gemeinsam genutztes System die benötigte Speicherkapazität oder eine planbare Ressourcenzuteilung nicht hergibt. Bei geteilten Cloud-Instanzen können gemeinsam genutzte Ressourcen, CPU-Überbelegung oder unklare Speichergrenzen die Planung erschweren; ein dedizierter Server löst jedoch nicht automatisch Aufgaben wie Redundanz, Sicherung und Wiederherstellung. Gerade bei einer PostgreSQL-Migration zählen deshalb nicht nur die Laufwerke, sondern auch die Möglichkeit, die gewählte Dateisystemstruktur selbst zu planen und die Sicherung unabhängig abzulegen.

Wer die PostgreSQL-14-Migration vorbereitet, sollte zuerst Datenverzeichnis, Tablespaces, WAL und Zielmodus dokumentieren, danach den Ablauf mit einer repräsentativen Datenkopie messen und erst dann die benötigte Serverkapazität festlegen. Wenn ein gemeinsam genutztes System die ermittelte Kapazität oder eine verlässliche Planung der Speicherressourcen nicht bietet, kann ein dedizierter AMD-Server von XFP Cloud geeigneter sein. Vor einer Produktionsumschaltung sollten jedoch sowohl die verfügbare Konfiguration als auch die Wiederherstellbarkeit der externen Sicherung geprüft sein.