Projekt anfragen
Entwickler prüft Quellcode an Tablet, Tastatur und Monitoren am Arbeitsplatz

PostgreSQL · Upgrade, Umzug, Engine-Wechsel

PostgreSQL-Migration und Datenübernahme

Wir wählen den Weg nach Verfahrensmatrix, messen ihn in der Testmigration und schalten nach Runbook um.

Migration anfragen Zur Verfahrensmatrix
  • Hauptversions-Upgrade
  • Umzug auf anderen Server oder Anbieter
  • Wechsel von Oracle, MySQL, SQL Server

Autor: Ibrahim Yesilay, Gründer und Geschäftsführer Stand:

01Drei Anlässe

Drei Gründe, eine PostgreSQL-Datenbank zu bewegen

SKAFFON führt PostgreSQL-Migrationen in drei Fällen durch: Upgrade auf eine neue Hauptversion, Umzug einer PostgreSQL-Datenbank auf anderen Server, Plattform oder Anbieter, und Wechsel von Oracle, MySQL oder SQL Server nach PostgreSQL. Die Seite richtet sich an IT-Leitung und Datenbankverantwortliche.

Das allgemeine Vorgehen für Datenbankmigrationen (Inventar, Testmigration, Validierung, Rückfall, Dump gegen CDC) steht auf der Seite Datenbankmigration. Hier geht es um die PostgreSQL-spezifischen Verfahren: pg_upgrade, logische Replikation für Versionswechsel, die Werkzeuge für Fremdquellen.

02Support-Ende

Wenn die Hauptversion aus dem Support läuft

PostgreSQL unterstützt eine Hauptversion laut Projektseite fünf Jahre nach der ersten Veröffentlichung; danach erscheint eine letzte Minor-Version, und die Version ist ohne Support. Stand der Prüfung am 2026-11-13: Version 14 hat ihr letztes Release am 12. November 2026 erhalten, Version 13 am 13. November 2025; Version 15 läuft laut Seite bis 11. November 2027.

Minor-Updates ändern das Speicherformat nie und sind ein Austausch der Programmdateien. Hauptversionen können es ändern und erfordern laut Upgrade-Dokumentation einen der drei dokumentierten Wege: Dump und Restore, pg_upgrade oder Replikation.

03Verfahrenswahl

Welches Verfahren passt zu Ihrem Ausfallfenster?

Die Zeilen zu Ausfall, Link-Modus und Kopiermodus folgen der Dokumentation zu pg_upgrade und den Upgrade-Wegen. Wie lange ein Verfahren bei Ihrer Datenbank dauert, zeigt erst die Testmigration.

Upgrade und Umzug innerhalb von PostgreSQL: Dump und Restore, pg_upgrade und logische Replikation im Vergleich
KriteriumDump und Restorepg_upgradeLogische Replikation
PrinzipLogischer Export aus der alten, Import in die neue VersionDatendateien werden in-place weiterverwendet, nur Systemtabellen entstehen neuNeue Instanz holt Daten per Replikation, danach Umschaltung
AusfallMindestens Export plus Import, sofern währenddessen nicht geschrieben werden darfBeide Server gestoppt; laut Dokumentation Minuten, besonders im Link-ModusLaut Dokumentation einige Sekunden für die Umschaltung
RückfallAlte Instanz unverändert, einfachKopiermodus: alter Cluster bleibt unverändert nutzbar; Link-Modus: nach Start des neuen Clusters nicht mehrAlte Instanz bleibt unverändert bis zur Umschaltung
ZielhostBeliebig, auch anderer ServerGleicher Server, gleiches Dateisystem im Link-ModusBeliebig, auch anderer Server oder Anbieter
EinschränkungenDauer wächst mit DatenmengeGleicher Host; Erweiterungen müssen für beide Versionen vorliegenSchema, Sequenzen, Large Objects, Sichten werden nicht repliziert (siehe Runbook)
Aufwandgeringgering bis mittelhoch

Faustregel. Passt die Testmigration mit Dump und Restore ins Fenster, nehmen wir sie. Läuft die Datenbank auf einem Server, der bleiben soll, und genügt ein kurzer Stillstand, ist pg_upgrade das Mittel. Wird der Server oder Anbieter gewechselt und darf der Stillstand nur Sekunden bis wenige Minuten dauern, ist logische Replikation das Mittel, mit dem höheren Aufwand.

04pg_upgrade

pg_upgrade: sechs Punkte, an denen es schiefgehen kann

  • Modi

    Kopieren (Standard) lässt den alten Cluster nutzbar. Link und Clone sind schneller; nach dem Start des neuen Clusters ist der alte im Link-Modus laut Dokumentation nicht mehr zugänglich. Der Modus --swap verändert den alten Cluster ab Beginn der Dateiübertragung zerstörerisch; ein Rückfall geht dann nur über ein Backup.

  • Vorab prüfen

    pg_upgrade --check kann laufen, während der alte Server noch aktiv ist. Wir führen es mit demselben Modus-Parameter aus, den der Echtlauf nutzt.

  • Statistiken danach

    Die meisten Optimizer-Statistiken werden übernommen, andere nicht (zum Beispiel mit CREATE STATISTICS erzeugte). Die Dokumentation empfiehlt, sie mit vacuumdb --all --analyze-in-stages --missing-stats-only und anschließend --analyze-only neu zu erzeugen, bevor die volle Last zurückkehrt.

  • Standbys

    Replikas werden nach dem Upgrade neu aufgebaut oder per rsync nachgezogen; geplant wird das mit, denn bei großen Datenbanken dauert es.

  • Replikationsslots

    Logische Slots werden laut Dokumentation nur migriert, wenn alle Beteiligten Version 17 oder neuer sind.

  • Vertrauen in die Quelle

    Das Upgrade führt laut Dokumentation beliebigen Code der Superuser der Quelle im Ziel aus; die Superuser der Quelle müssen vertrauenswürdig sein.

05Kubernetes

PostgreSQL auf Kubernetes mit CloudNativePG: drei Wege, ein Haken

Auf Kubernetes beschreibt die CloudNativePG-Dokumentation drei Wege: Dump und Restore (offline), native logische Replikation (online) und ein In-place-Upgrade mit pg_upgrade im Link-Modus (offline).

  • Beim In-place-Weg ist der gesamte Cluster einschließlich Replikas für Anwendungen nicht erreichbar.
  • Nach dem Upgrade werden Replikas neu geklont.
  • Backups vor dem Upgrade ermöglichen kein Point-in-Time-Recovery über die Versionsgrenze. Ein neues Basis-Backup gehört deshalb unmittelbar zum Abschluss.
  • Erweiterungen müssen für beide Versionen im Image vorliegen.
  • Schlägt das Upgrade fehl, lässt sich laut Dokumentation meist durch Zurücksetzen des Images ohne Wiederherstellung aus dem Backup auf die alte Version zurückkehren.
Nahaufnahme der Platine und des Anschlusssteckers zweier Laufwerke in buntem Licht

06Cutover

Logische Replikation im Überblick

Dieses Verfahren verwenden wir für Versionswechsel oder Hostwechsel bei kleinem Ausfallfenster. Es ersetzt nicht die Testmigration: Alle Schritte laufen zuerst vollständig gegen eine Kopie.

Cutover per logischer Replikation Quelle repliziert per Publikation und Abonnement auf das Ziel; danach Umschaltung der Anwendung. Quelle Alte Version / alter Host Publikation Ziel Neue Version / neuer Host Abonnement Anwendung Verbindung wird umgeschaltet Replikation Cutover bis zur Freigabe der Schreibzugriffe: Rückfall auf die Quelle Cutover per logischer Replikation Sequenzen werden vor der Freigabe nachgezogen
Cutover per logischer Replikation Quelle repliziert per Publikation und Abonnement auf das Ziel; danach Umschaltung der Anwendung. Cutover per logischerReplikation Sequenzen werden vor derFreigabe nachgezogen Quelle Alte Version / alter Host Publikation Replikation Ziel Neue Version / neuer Host Abonnement Cutover Anwendung Verbindung wird umgeschaltet bis zur Freigabe der Schreibzugriffe:Rückfall auf die Quelle

07Runbook

Acht Schritte vom Neustart der Quelle bis zum ersten Basis-Backup

  1. 01

    Quelle prüfen

    wal_level = logical ist nötig und erfordert laut Dokumentation einen Neustart der Quelle; das Fenster dafür wird früh eingeplant. Das WAL-Volumen steigt, insbesondere bei vielen UPDATEs auf Tabellen mit REPLICA IDENTITY FULL.

  2. 02

    Tabellen und Datentypen prüfen

    Jede Tabelle braucht Primärschlüssel oder eine passende Replica Identity. Large Objects lassen sich laut Einschränkungen nicht replizieren: Gibt es welche, wird ein eigener Pfad nötig, oder die Daten wandern in normale Tabellen. Nur Tabellen werden repliziert, keine Sichten, materialisierten Sichten oder Fremdtabellen.

  3. 03

    Ziel aufsetzen

    Neue Version, gleiche Erweiterungen, gleiche Rollen. Das Schema wird nicht repliziert und mit pg_dump --schema-only übernommen; Schemaänderungen auf der Quelle müssen von da an manuell nachgezogen werden. Wir vereinbaren deshalb einen Änderungsstopp für DDL während der Laufzeit.

  4. 04

    Publikation, Abonnement, Synchronisation

    Auf der Quelle CREATE PUBLICATION … FOR ALL TABLES (oder eine ausgewählte Liste), auf dem Ziel CREATE SUBSCRIPTION … CONNECTION '…' PUBLICATION …. Die Anfangskopie läuft automatisch. Alle Tabellen müssen im Zustand r (ready) in pg_subscription_rel stehen, danach wird der Replikationsverzug beobachtet.

  5. 05

    Validierung parallel

    Zeilenzahlen, Prüfsummen über Stichproben, fachliche Abfragen und Lasttest auf dem Ziel, solange die Replikation läuft.

  6. 06

    Cutover vorbereiten, Sequenzen nachziehen

    Anwendung in den Lesemodus oder stoppen; Verzug auf null warten. Sequenzen werden nicht repliziert; auf dem Ziel zeigen sie laut Dokumentation noch den Startwert. Vor Freigabe der Schreibzugriffe setzen wir sie auf die aktuellen Werte der Quelle oder auf einen ausreichend hohen Wert aus den Tabellen.

  7. 07

    Umschalten

    Verbindungen der Anwendung auf das Ziel, Anwendungstest, Schreibzugriff freigeben. Abonnement auf dem Ziel entfernen.

  8. 08

    Abschluss

    Statistik aktualisieren (ANALYZE), Backup und WAL-Archivierung auf dem Ziel aktivieren, erstes Basis-Backup ziehen, Quelle nach vereinbarter Frist außer Betrieb nehmen.

Rückfall

Bis zur Freigabe der Schreibzugriffe bleibt die Quelle der Rückweg

Bis zur Freigabe des Schreibzugriffs bleibt die Quelle unverändert und ist der Rückweg. Danach ist ein Zurück nur mit rückwärts laufender Replikation möglich, die wir vorab einrichten, wenn der Fachbereich es verlangt.

08Fremdquellen

Oracle, MySQL, SQL Server: Das Kopieren ist nicht das Problem

Bei Engine-Wechsel ist die Frage nicht das Kopieren, sondern die Abbildung von Typen, Prozeduren und Verhalten. Ob ein Werkzeug Ihre Logik abdeckt, zeigt erst die Testmigration.

  • Gespeicherte Prozeduren
  • Trigger
  • Sequenzen
  • Proprietäre Datentypen
  • Transaktionsverhalten

Allgemeines Vorgehen bei Datenbankmigrationen

Monitor mit Quellcode in einem abgedunkelten Raum

09Werkzeuge

Welches Werkzeug für welche Quelle?

Was ein Werkzeug von der Logik Ihrer Quelle abdeckt, bewerten wir im Inventar, bevor ein Termin genannt wird.

Werkzeuge für den Wechsel einer Fremdquelle nach PostgreSQL, ihre Leistung laut Dokumentation und ihre Grenzen
QuelleWerkzeugWas es laut Dokumentation leistetGrenze
OracleOra2PgSchema-Konvertierung, Umsetzung von PL/SQL nach PL/pgSQL, Datenmigration, Validierung, Assessment-Berichte; freie Software unter GPL v3Datenmigration laut Dokumentation offline mit Ausfallzeit; wie viel der Logik sich automatisch umsetzen lässt, zeigt erst der Assessment-Bericht auf Ihrem Bestand
MySQL, SQL Server, SQLitepgloaderLiest laut Dokumentation SQLite, MySQL, MS SQL Server, PostgreSQL und Redshift als QuellenOracle ist nicht unter den dokumentierten Quellen; Logik in Prozeduren und Triggern bewerten wir gesondert
Alle Quellen, kleines FensterCDC-Werkzeug je QuelleLiest Änderungen aus dem Log der QuelleAuswahl hängt von der Quelle ab, wird im Projekt festgelegt

10Projektablauf

Von der Inventur bis zur Übergabe in sechs Schritten

  1. 01

    Inventar und Risikobericht

    Version, Größe, Erweiterungen, Large Objects, Tabellen ohne Schlüssel.

  2. 02

    Verfahrenswahl

    Nach Matrix, begründet mit dem Ausfallfenster.

  3. 03

    Testmigration

    Mit gemessener Dauer.

  4. 04

    Validierung und Abnahme

    Abnahmekriterien legen wir mit der Fachseite fest.

  5. 05

    Cutover

    Nach Runbook, mit festgelegten Rückfallkriterien.

  6. 06

    Nachlauf

    Statistik, Backup, Monitoring, Übergabe oder Betrieb.

11Zugänge und Testdaten

Zugänge, Verschlüsselung und Testdaten

Zugänge sind personalisiert und werden nach Projektende entzogen; Übertragung ist verschlüsselt. Wo Produktivdaten personenbezogen sind, klären wir mit Ihnen, ob Tests mit maskierten Daten laufen. Rechtliche Bewertung und Auftragsverarbeitung liegen bei Ihrer Datenschutzverantwortung.

12Übergabe

Sechs Unterlagen, die nach dem Cutover bei Ihnen liegen

  • Inventar- und Risikobericht
  • Verfahrensentscheidung mit Begründung
  • Versionierte Migrationsskripte
  • Validierungsabfragen und Abnahmeprotokoll
  • Cutover-Runbook mit Rückfallkriterien
  • Übergabedokumentation

13Angebot

Was ein Migrationsangebot bestimmt

Aufwand bestimmen Datenmenge, Ausfallfenster, Zahl der Datenbanken, bei Fremdquellen der Anteil an Prozeduren und Sonderlogik, Anpassungsbedarf der Anwendung, Zahl der Testläufe und ob Betrieb danach folgt. Umfang und Preis des Angebots leiten sich aus diesen Punkten ab.

14Abgrenzung

Wo eine PostgreSQL-Migration mit uns nicht funktioniert

Das liefern wir

  • Migration mit Testlauf und Abnahme
  • Verfahrenswahl nach Ausfallfenster, belegt durch die Testmigration
  • Ziel PostgreSQL

Das erwarten Sie besser nicht von uns

  • Eine Migration ohne Testlauf und ohne Abnahme.
  • Dass ein Werkzeug die Logik einer Oracle-Anwendung vollständig und fehlerfrei umsetzt.
  • Eine andere Zielplattform als PostgreSQL.

Quelle, Ziel, Datenmenge, Ausfallfenster: mehr braucht der Anfang nicht

Nennen Sie uns diese vier Angaben, daraus entsteht das Inventar und die Wahl des Verfahrens.

Projekt anfragen