Microsoft SQL Server und Azure SQL zu Supabase migrieren
Timo Wevelsiep•Aktualisiert: 25.08.2026Hinweis zum Inhalt: Versionen, Befehle und Preise können sich ändern. Bitte prüfen Sie kritische Schritte vor dem produktiven Einsatz eigenständig. Dieser Leitfaden ersetzt keine individuelle Beratung.
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.
Quellen
Lieber betreiben lassen?
Sie möchten Supabase nicht selbst betreiben? WZ-IT übernimmt Einrichtung, Betrieb und Wartung - datenschutzorientiert aus Deutschland.
Anfrage
Supabase migrieren, absichern oder betreiben
Wir migrieren Supabase-Projekte und bestehende Backends wie Firebase, Lovable, PostgreSQL, MySQL oder Auth0, bauen die Zielumgebung auf und übernehmen auf Wunsch den laufenden Betrieb.
Häufig gestellte Fragen
Antworten auf die wichtigsten Fragen
Daten können mit geeigneten Werkzeugen nach PostgreSQL übertragen werden. T-SQL, Datentypen, Stored Procedures, SQL-Agent-Jobs und Berechtigungen benötigen jedoch eine explizite Konvertierung.
Ja. Azure SQL verwendet die SQL-Server-Familie, bringt aber eigene Netzwerk-, Identitäts- und Plattformfunktionen mit. Diese werden im Assessment gesondert erfasst.
Sie werden nicht automatisch portiert. Je nach Zweck entstehen PostgreSQL-Funktionen, pg_cron-Jobs, Edge Functions, Worker oder externe Automationen.
Entra ID kann als externer Identity Provider weiter eine Rolle spielen. SQL-Server-Authentifizierung und Anwendungslogin müssen getrennt betrachtet und für Supabase neu angebunden werden.
Eine Supabase-Migration beginnt bei 3.490 Euro netto. T-SQL, Routinen, Datenvolumen, Anwendung und Downtime-Anforderung bestimmen den konkreten Umfang.
Mehr zu Supabase
- Was ist Supabase?
- Supabase Cloud vs. Self-Hosted
- Supabase Self-Hosting: Vorteile & Nachteile
- Supabase-Kosten: Cloud vs. Self-Hosted
- Supabase Cloud zu Self-Hosted migrieren
- Supabase-Projekt, Region oder Organisation migrieren
- PostgreSQL zu Supabase migrieren
- AWS RDS und Aurora zu Supabase migrieren
- Heroku Postgres zu Supabase migrieren
- Neon und Vercel Postgres zu Supabase migrieren
- MySQL und MariaDB zu Supabase migrieren
- Microsoft SQL Server und Azure SQL zu Supabase migrieren
- Firebase zu Supabase migrieren
- Lovable Cloud zu Supabase migrieren
- Auth0 zu Supabase Auth migrieren
- Supabase-Migrationscheckliste
- Supabase vollständig sichern
- Supabase Self-Hosted aktualisieren
- Supabase RLS prüfen
- Supabase auf Hetzner betreiben
- Supabase mit Coolify installieren
