--- title: "PostgreSQL-Migration und Datenübernahme | SKAFFON" description: "PostgreSQL-Migration: Major-Upgrade mit pg_upgrade oder logischer Replikation, Hostwechsel, Umstieg von Oracle, MySQL oder SQL Server. Mit Runbook." url: https://skaffon.de/daten/postgresql-migration/ --- ![Entwickler prüft Quellcode an Tablet, Tastatur und Monitoren am Arbeitsplatz](/_astro/entwickler-quellcode-tablet-tastatur.Bo9lD6vf_wsaWy.jpg) 1. [Startseite](/) 2. [Daten](/daten/) 3. PostgreSQL-Migration und Datenübernahme 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](/projekt-anfragen/) [Zur Verfahrensmatrix](/daten/postgresql-migration/#welches-verfahren-passt-zu-ihrem-ausfallfenster) - Hauptversions-Upgrade - Umzug auf anderen Server oder Anbieter - Wechsel von Oracle, MySQL, SQL Server Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 Drei 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](/daten/datenbank-migration/). Hier geht es um die PostgreSQL-spezifischen Verfahren: pg\_upgrade, logische Replikation für Versionswechsel, die Werkzeuge für Fremdquellen. Danach den Betrieb abgeben? Wer nach der Migration den Betrieb abgeben will, findet ihn unter [Managed PostgreSQL](/managed-services/managed-postgresql/). Support-Ende ## Wenn die Hauptversion aus dem Support läuft PostgreSQL unterstützt eine Hauptversion laut [Projektseite](https://www.postgresql.org/support/versioning/) 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](https://www.postgresql.org/docs/current/upgrading.html) einen der drei dokumentierten Wege: Dump und Restore, pg\_upgrade oder Replikation. Verfahrenswahl ## Welches Verfahren passt zu Ihrem Ausfallfenster? Die Zeilen zu Ausfall, Link-Modus und Kopiermodus folgen der Dokumentation zu [pg\_upgrade](https://www.postgresql.org/docs/current/pgupgrade.html) und den [Upgrade-Wegen](https://www.postgresql.org/docs/current/upgrading.html). 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__ | Kriterium | Dump und Restore | pg\_upgrade | Logische Replikation | | --------------- | --------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | Prinzip | Logischer Export aus der alten, Import in die neue Version | Datendateien werden in-place weiterverwendet, nur Systemtabellen entstehen neu | Neue Instanz holt Daten per Replikation, danach Umschaltung | | Ausfall | Mindestens Export plus Import, sofern währenddessen nicht geschrieben werden darf | Beide Server gestoppt; laut Dokumentation Minuten, besonders im Link-Modus | Laut Dokumentation einige Sekunden für die Umschaltung | | Rückfall | Alte Instanz unverändert, einfach | Kopiermodus: alter Cluster bleibt unverändert nutzbar; Link-Modus: nach Start des neuen Clusters nicht mehr | Alte Instanz bleibt unverändert bis zur Umschaltung | | Zielhost | Beliebig, auch anderer Server | Gleicher Server, gleiches Dateisystem im Link-Modus | Beliebig, auch anderer Server oder Anbieter | | Einschränkungen | Dauer wächst mit Datenmenge | Gleicher Host; Erweiterungen müssen für beide Versionen vorliegen | Schema, Sequenzen, Large Objects, Sichten werden nicht repliziert (siehe Runbook) | | Aufwand | gering | gering bis mittel | hoch | **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. pg\_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](https://www.postgresql.org/docs/current/logical-replication-upgrade.html) 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. Kubernetes ## PostgreSQL auf Kubernetes mit CloudNativePG: drei Wege, ein Haken Auf Kubernetes beschreibt die [CloudNativePG-Dokumentation](https://cloudnative-pg.io/docs/current/postgres%5Fupgrades) 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](/_astro/platine-anschlusssteckers-laufwerke-licht.xBdZ3D2q_o5J2Y.jpg) Cutover ## 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. Runbook ## 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](https://www.postgresql.org/docs/current/runtime-config-wal.html) 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](https://www.postgresql.org/docs/current/logical-replication-restrictions.html) 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. Fremdquellen ## 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](/daten/datenbank-migration/) ![Monitor mit Quellcode in einem abgedunkelten Raum](/_astro/code-auf-monitor-dunkler-raum.BRgGL4PQ_Z1l2Ujt.jpg) Werkzeuge ## 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__ | Quelle | Werkzeug | Was es laut Dokumentation leistet | Grenze | | ----------------------------- | ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Oracle | [Ora2Pg](https://ora2pg.darold.net/) | Schema-Konvertierung, Umsetzung von PL/SQL nach PL/pgSQL, Datenmigration, Validierung, Assessment-Berichte; freie Software unter GPL v3 | Datenmigration 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, SQLite | [pgloader](https://pgloader.readthedocs.io/en/latest/intro.html) | Liest laut Dokumentation SQLite, MySQL, MS SQL Server, PostgreSQL und Redshift als Quellen | Oracle ist nicht unter den dokumentierten Quellen; Logik in Prozeduren und Triggern bewerten wir gesondert | | Alle Quellen, kleines Fenster | CDC-Werkzeug je Quelle | Liest Änderungen aus dem Log der Quelle | Auswahl hängt von der Quelle ab, wird im Projekt festgelegt | Projektablauf ## 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. Zugä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. Ü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 Angebot ## 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. Weiterführend Übersicht: [Daten](/daten/). Architektur und Betrieb des Ziels: [PostgreSQL-Beratung](/daten/postgresql-datenbanken/). Hosting-Ziele: [souveräne Cloud](/infrastruktur/souveraene-cloud/). Abgrenzung ## 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](/projekt-anfragen/)