MySQL und MariaDB zu Supabase migrieren: von MySQL zu PostgreSQL

Der Wechsel von MySQL zu PostgreSQL sollte vor dem Cutover vollständig geprobt werden. WZ-IT bietet die Supabase-Migration ab 3.490 € nach Prüfung von Schema, Daten und Anwendung an.

Eine Migration von MySQL oder MariaDB zu Supabase wechselt nicht nur den Anbieter, sondern auch das Datenbanksystem. Supabase basiert auf PostgreSQL. Tabellen und viele Standarddatentypen lassen sich konvertieren, während SQL-Dialekt, Routinen, Zeichensätze und Anwendungsannahmen eigenständig geprüft werden müssen.

Das Ziel ist deshalb keine möglichst schnelle Kopie, sondern eine reproduzierbare PostgreSQL-Struktur mit überprüften Daten und einer kompatiblen Anwendung.

Warum die Migration mehr als Datenexport ist

MySQL, MariaDB und PostgreSQL unterscheiden sich unter anderem bei:

• Auto-Increment und Sequenzen
• Boolean- und Integer-Verhalten
• ENUM, SET und Domain-Modellen
• UNSIGNED-Zahlen
• DATETIME, TIMESTAMP und Zeitzonen
• Zero Dates und ungültigen Datumswerten
• JSON-Funktionen und Operatoren
• Kollationen, Sortierung und Groß-/Kleinschreibung
• Stored Procedures, Functions, Trigger und Events
• Upserts, Quotes und herstellerspezifischer SQL-Syntax

Ein Import kann technisch erfolgreich enden und trotzdem fachlich falsche Werte, Sortierungen oder Anwendungsfehler erzeugen. Deshalb wird die Abnahme auf Daten- und Verhaltensebene durchgeführt.

Bestand strukturiert aufnehmen

Zusätzlich werden Datenqualitätsprobleme gesucht, die MySQL toleriert, PostgreSQL aber ablehnt. Dazu gehören ungültige Datumswerte, abgeschnittene Texte oder Fremdschlüsselverletzungen.

Zielmodell für PostgreSQL festlegen

Die Konvertierung sollte bewusst dokumentiert werden. Beispiele:

Die richtige Abbildung hängt vom fachlichen Zweck ab. Eine automatische Konvertierung ist ein Ausgangspunkt, keine fertige Architekturentscheidung.

pgloader oder kontrollierter ETL-Prozess

Die offizielle Supabase-Anleitung nennt einen geführten Colab-Workflow und pgloader. pgloader kann Schema und Daten direkt von MySQL nach PostgreSQL übertragen und viele Typen automatisch abbilden.

Ein eigener ETL- oder Exportprozess ist sinnvoll, wenn:

• nur ausgewählte Daten migriert werden
• Werte vor dem Import bereinigt werden müssen
• große Tabellen inkrementell übertragen werden
• komplexe Typ- und Namensregeln gelten
• jede Transformation nachvollziehbar protokolliert werden soll

Das Verfahren wird nach einer repräsentativen Testmigration festgelegt.

Routinen und Anwendungslogik

Stored Procedures und Functions werden nicht einfach durch einen Datenimport portiert. MySQL- oder MariaDB-Code muss nach PL/pgSQL, SQL, Edge Functions oder einen externen Anwendungsdienst übertragen werden.

Zu prüfen sind außerdem:

• Raw SQL im Quellcode
• ORM-Dialekt und generierte Migrationen
• Transaktionsisolation und Locking
• Case Sensitivity von Tabellen- und Spaltennamen
• Pagination, Volltextsuche und JSON-Abfragen
• Fehlercodes und Retry-Verhalten

Eine Staging-Version der Anwendung läuft vor dem Cutover vollständig gegen Supabase.

Stille Semantikfehler verhindern

Einige Unterschiede erzeugen keinen offensichtlichen Importfehler, verändern aber das Ergebnis. Leere Zeichenketten und NULL, Groß- und Kleinschreibung, implizite Typkonvertierungen, Divisionen, Zeitzonen sowie die Sortierung von Umlauten müssen mit echten Anwendungsdaten verglichen werden. Gleiches gilt für ON UPDATE-Zeitstempel, automatische Default-Werte und Abfragen, die sich auf eine bestimmte MySQL-SQL-Mode-Einstellung verlassen.

Für kritische Tabellen werden deshalb nicht nur Zeilenzahlen, sondern fachliche Invarianten definiert. Beispiele sind eindeutige Kundennummern, unveränderte Salden, konsistente Statusübergänge und vollständige Beziehungen. Diese Prüfungen laufen nach der Testmigration und erneut unmittelbar vor der Freigabe.

Supabase-Dienste sind ein separater Schritt

Nach der Datenbankmigration kann die Anwendung weiterhin per PostgreSQL-Treiber arbeiten. Supabase Auth, Storage, Realtime, Data API und RLS werden nur eingeführt, wenn sie fachlich benötigt werden.

Besonders RLS verändert das Berechtigungsmodell. Bestehende Anwendungsrollen müssen auf Nutzer-JWTs, anon, authenticated und serverseitige Zugriffe abgebildet und mit Negativtests geprüft werden.

Testmigration und Cutover

Die Testmigration umfasst mindestens:

• Tabellen- und Zeilenzahlen
• Prüfsummen oder Stichproben kritischer Daten
• Dezimal-, Datums-, Unicode- und Binärwerte
• Primär- und Fremdschlüssel
• Sequenzen und neue Inserts
• Views, Trigger und Ersatz für Routinen
• zentrale Lese-, Schreib- und Reporting-Abfragen
• Laufzeit und Belastung der Quelle

Für den finalen Transfer wird eine Schreibpause oder ein gesonderter Delta-Prozess geplant. Der Ablauf folgt der Supabase-Migrationscheckliste, während die PostgreSQL-zu-Supabase-Anleitung die Zielseite vertieft.

Nach Abnahme kann WZ-IT Supabase als Managed Service weiterbetreiben.

Quellen

• Supabase: Migrate from MySQL to Supabase
• pgloader documentation
• PostgreSQL: Data Types