Ein Wechsel von SQL Server zu PostgreSQL braucht ein nachvollziehbares Zielmodell. WZ-IT bietet die Supabase-Migration ab 3.490 € nach Prüfung von Datenbank, T-SQL und Anwendung an.
Eine Migration von Microsoft SQL Server oder Azure SQL zu Supabase ist eine heterogene Datenbankmigration. Supabase verwendet PostgreSQL. Daten lassen sich übertragen, aber T-SQL, Datentypen, Stored Procedures, Jobs und Berechtigungen benötigen eine bewusste Übersetzung.
Der technische Erfolg wird daher nicht daran gemessen, ob ein Importprozess beendet wurde, sondern ob Daten, Anwendung und Betriebsabläufe auf PostgreSQL korrekt funktionieren.
Welche SQL-Server-Quelle liegt vor?
Zuerst wird der tatsächliche Ausgangspunkt bestimmt:
- SQL Server auf Windows oder Linux
- SQL Server in einer virtuellen Maschine
- Azure SQL Database
- Azure SQL Managed Instance
- SQL Server in AWS RDS
- mehrere Datenbanken mit Cross-Database-Abfragen
- Always On Availability Groups oder Replikation
Edition und Plattform beeinflussen Netzwerkzugriff, verfügbare Exportverfahren, Authentifizierung und verwendete Funktionen.
Assessment von Schema und Anwendung
| Bereich | Zu erfassen |
|---|---|
| Version und Edition | SQL-Server-Version, Compatibility Level und genutzte Features |
| Datenmodell | Datenbanken, Schemas, Tabellen, Schlüssel und Partitionen |
| Datentypen | uniqueidentifier, datetimeoffset, money, bit, XML und räumliche Typen |
| T-SQL | Procedures, Functions, Trigger, Views und dynamisches SQL |
| Jobs | SQL Server Agent, SSIS, ETL und geplante Tasks |
| Identität | SQL Logins, Windows Auth, Entra ID, Rollen und Grants |
| Anwendung | Treiber, ORM, rohe T-SQL-Abfragen und Reporting |
Cross-Database-Abfragen und Linked Servers benötigen besondere Aufmerksamkeit, weil eine Supabase-Datenbank nicht automatisch dieselbe Serverstruktur abbildet.
Datentypen bewusst abbilden
Beispielhafte Entscheidungen:
| SQL Server | Mögliches PostgreSQL-Ziel |
|---|---|
IDENTITY |
Identity-Spalte oder Sequence |
uniqueidentifier |
uuid |
bit |
boolean |
datetimeoffset |
timestamptz nach Zeitzonenprüfung |
nvarchar |
text oder varchar in UTF-8 |
money |
numeric mit definierter Präzision |
rowversion |
eigenes Versions- oder Timestamp-Modell |
hierarchyid |
angepasstes relationales Modell oder Extension |
Auch Kollationen und Case Sensitivity können Such-, Sortier- und Eindeutigkeitsverhalten verändern. Das wird mit realen Daten getestet.
T-SQL, Procedures und Jobs
T-SQL-Code wird je nach Zweck neu eingeordnet:
- Datenbanknahe Logik als SQL oder PL/pgSQL
- zeitgesteuerte Aufgaben über
pg_cronoder externe Scheduler - Integrationslogik als Worker oder Workflow
- HTTP- und Anwendungscode als Edge Function oder Dienst
- Reporting-Abfragen in PostgreSQL-Syntax
SQL Server Agent, SSIS-Pakete und CLR-Code sind keine portablen Datenbankobjekte. Sie benötigen jeweils eine Zielentscheidung.
Transferverfahren
Die offizielle Supabase-Anleitung nennt einen geführten Migrationsweg und pgloader. Für komplexe Datenbanken kann ein kontrollierter ETL-Prozess geeigneter sein, weil Transformationen und Fehler pro Tabelle protokolliert werden.
Der Testtransfer validiert:
- Tabellen- und Zeilenzahlen
- Unicode und Sonderzeichen
- Dezimalwerte und Rundung
- Datum, Uhrzeit und Zeitzonen
- UUIDs, Binärdaten und große Objekte
- Primär- und Fremdschlüssel
- Identity-Werte und Sequenzen
- Views und Ersatz für Routinen
Anwendung und Authentifizierung anpassen
Ein Wechsel des Datenbanktreibers reicht häufig nicht aus. Zu prüfen sind:
- T-SQL in Repositorys und Reporting-Werkzeugen
- ORM-Provider und Migrationshistorie
- Transaktionsisolation, Locks und Fehlercodes
- Pagination, Volltextsuche und JSON-Verarbeitung
- Connection Pooling und TLS
- SQL Logins, Windows Auth und Entra-Verbindungen
Soll Supabase Auth eingeführt werden, ist das eine eigenständige Nutzermigration. Datenbanklogins und Endnutzeridentitäten sind nicht dasselbe.
Fachliche Abnahme statt reinem Schematest
Eine technisch erfolgreiche Übertragung beweist noch nicht, dass sich die Anwendung identisch verhält. Für jede geschäftskritische Funktion wird deshalb ein nachvollziehbarer Abnahmefall festgelegt. Dazu gehören neue Datensätze, Änderungen, Löschlogik, Suche, Filter, Exporte, Reports und parallele Zugriffe. Besonders Abfragen mit impliziten Typkonvertierungen, NULL-Behandlung, Stringvergleichen oder datenbankspezifischer Sortierung können nach dem Wechsel andere Ergebnisse liefern.
Zusätzlich werden Fehler- und Lastfälle geprüft: Wie reagiert die Anwendung auf einen abgebrochenen Schreibvorgang, einen Unique-Constraint, einen Lock oder eine erschöpfte Verbindung? Erst wenn Datenbestand und Nutzerwege zusammen abgenommen sind, ist der T-SQL-zu-PostgreSQL-Wechsel belastbar.
Cutover planen
Der finale Wechsel kann über ein Wartungsfenster oder einen gesonderten Delta-Prozess erfolgen. Vor der Freigabe werden Daten, Anwendung, Jobs und Integrationen in Staging abgenommen.
Der Ablauf orientiert sich an der Supabase-Migrationscheckliste. Das PostgreSQL-Ziel wird in der Anleitung PostgreSQL zu Supabase migrieren vertieft.
Nach dem Cutover kann WZ-IT Supabase als Managed Service übernehmen.
