Datenmigration von MySQL auf PostgreSQL: Was wirklich kompliziert ist

MySQL und PostgreSQL sind beide relationale Datenbanken. Beide sprechen SQL. Der Umzug von der einen zur anderen klingt deshalb nach Routine. In der Praxis ist eine MySQL zu PostgreSQL Migration selten ein Kopierjob. Die beiden Systeme unterscheiden sich bei Datentypen, im SQL-Dialekt und im Verhalten bei Randfällen. Genau diese Details entscheiden, ob der Wechsel glatt läuft oder das Projekt ausbremst.

Dieser Artikel erklärt, wo die Stolpersteine liegen, was passiert, wenn man sie ignoriert, und wie ein sicherer Ablauf aussieht. Geschrieben für Entscheider, nicht für Datenbankspezialisten.

Warum Unternehmen überhaupt wechseln

Der häufigste Auslöser ist ein erzwungenes Update. Viele ältere Anwendungen laufen noch auf MySQL 5. Diese Versionen erhalten keine Sicherheits-Updates mehr. Was das bedeutet, steht im Artikel zum MySQL 5 End of Life. Wer die Datenbank ohnehin anfassen muss, prüft dabei oft Alternativen.

PostgreSQL ist so eine Alternative. Die Datenbank ist Open Source, wird aktiv gepflegt und gehört keinem einzelnen Konzern. Sie hält sich enger an den SQL-Standard und kann einige Dinge, die MySQL fehlen oder erst spät dazukamen. Für manche Teams zählt auch die Unabhängigkeit von Oracle, dem Eigentümer von MySQL.

Wichtig vorab: Keiner dieser Gründe zwingt zum Wechsel. Ein aktuelles MySQL 8 ist eine solide Datenbank. Wer wechselt, sollte wissen warum.

Beide sprechen SQL. Kompliziert ist es trotzdem

SQL ist ein Standard mit vielen Dialekten. MySQL und PostgreSQL legen ihn unterschiedlich aus. Im Alltag fällt das kaum auf. Bei einer Migration fällt es überall auf.

Datentypen passen nicht eins zu eins

Ein Beispiel: MySQL kennt Zahlenfelder ohne Minusbereich, sogenannte vorzeichenlose Ganzzahlen. PostgreSQL kennt sie nicht. Beim Übertragen muss der Zieltyp größer gewählt werden, sonst passen hohe Werte nicht hinein.

Auch bei Ja/Nein-Feldern trennen sich die Wege. MySQL speichert sie intern als kleine Zahl. PostgreSQL hat dafür einen eigenen Wahrheitswert-Typ. Klingt harmlos. Es bedeutet aber: Jede Abfrage, die mit 0 und 1 arbeitet, muss geprüft werden.

Der Klassiker sind Datumsfelder. MySQL akzeptiert je nach Konfiguration das Pseudo-Datum "0000-00-00". PostgreSQL lehnt es ab. Solche Einträge stecken in fast jeder gewachsenen Datenbank und müssen vor dem Umzug bereinigt werden.

MySQL verzeiht viel, PostgreSQL wenig

Ältere MySQL-Versionen sind nachsichtig. Zu lange Texte werden stillschweigend gekürzt, unpassende Werte zurechtgebogen. PostgreSQL bricht in solchen Fällen mit einer Fehlermeldung ab.

Für die Datenqualität ist diese Strenge ein Gewinn. Für die Migration bedeutet sie Arbeit. Alles, was MySQL über Jahre durchgewunken hat, kommt beim Import wieder hoch. Die Altdaten-Probleme, die sich angesammelt haben, werden auf einen Schlag fällig.

Dazu kommt die Groß- und Kleinschreibung. MySQL behandelt "Meier" und "meier" beim Vergleichen von Texten meist gleich. PostgreSQL unterscheidet strikt. Eine Suche, die vorher zehn Treffer fand, findet plötzlich drei. Solche Abweichungen meldet kein Importskript. Sie fallen erst im Betrieb auf.

Abfragen und Funktionen heißen anders

Der SQL-Dialekt weicht in vielen Kleinigkeiten ab. Schon Tabellennamen werden unterschiedlich geschrieben. Funktionen zum Formatieren von Datumswerten oder zum Verketten von Texten tragen andere Namen. Den praktischen MySQL-Befehl für "einfügen oder aktualisieren" gibt es in PostgreSQL nur mit anderer Syntax.

Jede dieser Stellen im Anwendungscode muss gefunden und angepasst werden. Bei einer Anwendung mit einigen hundert Abfragen ist das der größte Einzelposten im Projekt. Gespeicherte Prozeduren, also Programmlogik direkt in der Datenbank, lassen sich gar nicht übernehmen. Sie werden neu geschrieben.

Zeichensätze und Sortierung

MySQL hat eine historische Eigenheit: Der Zeichensatz mit dem Namen "utf8" ist dort kein vollständiges UTF-8. Für Emojis und seltene Zeichen braucht es "utf8mb4". PostgreSQL arbeitet von Haus aus mit echtem UTF-8. Beim Umzug müssen alte Zeichensatz-Reste sauber umgewandelt werden, sonst kommen Umlaute als Zeichensalat an.

Auch die Sortierung ändert sich je nach Spracheinstellung. Für Menschen ist die Reihenfolge in einer Liste ein Detail. Für Software, die sich auf eine bestimmte Reihenfolge verlässt, ist sie eine Fehlerquelle.

Was passiert, wenn man das unterschätzt

Die typische Geschichte geht so: Ein Testimport läuft nach wenigen Korrekturen durch. Das Team hält die Migration für fast fertig. Dann startet der Testbetrieb, und die Anwendung verhält sich an zwanzig Stellen anders. Suchergebnisse stimmen nicht, Berichte zeigen abweichende Zahlen, und irgendwo speichert ein Formular nicht mehr.

Jetzt beginnt die eigentliche Arbeit, nur unter Zeitdruck. Im schlechtesten Fall ist das alte System schon gekündigt. Dann läuft die Fehlersuche im Live-Betrieb, mit echten Kundendaten.

Der zweite häufige Fehler ist der fehlende Abgleich. Wer nach dem Import nicht prüft, ob alle Datensätze vollständig und unverändert angekommen sind, merkt Verluste erst Monate später. Dann sind sie kaum noch zu reparieren.

So läuft eine MySQL zu PostgreSQL Migration in der Praxis

Ein geordneter Ablauf hat fünf Etappen.

1. Bestandsaufnahme

Zuerst wird gesichtet. Wie groß ist die Datenbank? Welche MySQL-Besonderheiten stecken im Schema, also im Bauplan der Tabellen? Wie viele Abfragen enthält der Anwendungscode und wo stehen sie? Gibt es Programmlogik in der Datenbank? Das Ergebnis ist eine Liste aller Baustellen und eine belastbare Aufwandsschätzung.

2. Schema und Daten testweise übertragen

Für den technischen Umzug gibt es erprobte Werkzeuge. Das bekannteste ist pgloader, ein Open-Source-Tool, das Tabellenstrukturen übersetzt und Daten überträgt. Es erledigt die Standardfälle zuverlässig. Die Sonderfälle aus der Bestandsaufnahme bleiben Handarbeit. Der erste Durchlauf geht immer auf eine Testumgebung, nie auf ein System im laufenden Betrieb.

3. Anwendung anpassen

Parallel werden die Abfragen im Code umgestellt. Anwendungen mit einer Abstraktionsschicht, einem sogenannten ORM, das Datenbankzugriffe vereinheitlicht, sind hier im Vorteil. Direkt geschriebenes SQL kostet mehr Zeit. Wie man solche Umbauten plant, ohne den Betrieb zu gefährden, zeigt unsere Checkliste für Software-Migrationen.

4. Testen und Daten abgleichen

Getestet wird auf zwei Ebenen. Fachlich: Verhält sich die Anwendung wie vorher? Und auf Datenebene: Stimmen Zeilenzahlen und Prüfsummen zwischen Quelle und Ziel überein? Eine Prüfsumme ist ein rechnerischer Fingerabdruck über die Daten. Weichen die Werte ab, ist beim Import etwas verloren gegangen. Die Grundregeln dafür beschreibt unser Beitrag zur Datenmigration aus Altsystemen.

5. Umstellung mit Rückweg

Für den Stichtag gibt es zwei Muster. Kleine Systeme ziehen in einem Wartungsfenster um: alte Datenbank einfrieren, final übertragen, umschalten. Größere Systeme lassen beide Datenbanken eine Zeit lang parallel laufen und gleichen Änderungen fortlaufend ab. In beiden Fällen bleibt der Rückweg offen, bis sich das neue System einige Wochen bewährt hat.

Nach dem Umzug lohnt ein Blick auf die Leistung. PostgreSQL hat eigene Stellschrauben für Indexe und Speicher. Was dabei herauszuholen ist, zeigt der Artikel zur Datenbank-Optimierung.

Wie lange dauert so ein Projekt?

Das hängt vor allem an drei Faktoren: der Menge an direkt geschriebenem SQL, dem Zustand der Daten und dem Umfang der Programmlogik in der Datenbank. Eine kleine Anwendung mit sauberem Code ist in ein bis zwei Wochen umgezogen. Eine gewachsene Anwendung mit hunderten Abfragen und alten Datenbeständen braucht eher mehrere Monate. Seriös schätzen lässt sich das erst nach der Bestandsaufnahme. Einem Festpreis, der vorher genannt wird, sollten Sie misstrauen.

Fazit: Machbar, aber kein Selbstläufer

Eine Migration von MySQL auf PostgreSQL ist gut beherrschbar, wenn man die Unterschiede ernst nimmt. Die Technik ist erprobt, die Werkzeuge sind ausgereift. Was Projekte scheitern lässt, ist die Annahme, zwei SQL-Datenbanken seien austauschbar.

Sie überlegen, ob der Wechsel für Ihr System sinnvoll ist? Wir schauen uns Datenbank und Anwendung an und sagen Ihnen ehrlich, was der Umzug bedeutet. Auch wenn die Antwort lautet: Bleiben Sie bei MySQL. Sprechen Sie uns an. Das Erstgespräch ist kostenlos.