SQL Server nach PostgreSQL: was leichter ist als bei Oracle und was nicht

Wenn über den Abschied von teuren Datenbanklizenzen geredet wird, geht es fast immer um Oracle. Im Mittelstand steht aber viel häufiger ein Microsoft SQL Server im Keller. Die Migration nach PostgreSQL ist dort in einem Punkt deutlich einfacher und in 3 Punkten unangenehmer, als die meisten erwarten.

Die kurze Antwort

• Der teuerste Posten einer Oracle-Migration fällt bei SQL Server weg: Packages gibt es dort nicht. Die Datenbanklogik ist meist kleiner und flacher.
• Dafür beißt eine Kleinigkeit, die niemand auf dem Zettel hat: Groß- und Kleinschreibung. Abfragen, die 10 Jahre funktioniert haben, finden nach der Migration nichts mehr.
• Der eigentliche Aufwand liegt selten in der Datenbank, sondern in dem, was Microsoft drumherum gebaut hat: SSIS, SSRS und SSAS.
• Dazu die Windows-Anmeldung, die bisher einfach da war und neu gebaut werden muss.

Warum SQL Server der häufigere Fall ist

Oracle sitzt in Konzernen und in gewachsenen Fachverfahren. SQL Server sitzt im Mittelstand: hinter dem ERP, hinter der selbst entwickelten Fachanwendung, hinter dem Reporting. Er ist über Jahre mitgewachsen, oft ohne eigenen Datenbankadministrator. Irgendwann steht die Frage nach der nächsten Lizenzstufe im Raum.

Die Motivation ist dabei meist nicht dieselbe wie bei Oracle. Bei Oracle geht es um viel Geld und um Herstellerabhängigkeit. Bei SQL Server geht es häufiger um eine konkrete Schwelle: Die Standard Edition reicht nicht mehr, für die Enterprise Edition fehlt die Rechtfertigung und plötzlich rechnet jemand nach, was PostgreSQL kosten würde. Wie bei Oracle gilt: die eingesparte Lizenz ist der einfache Teil der Rechnung.

Was leichter ist als bei Oracle

Keine Packages

Das ist der wichtigste Unterschied. In gewachsenen Oracle-Umgebungen liegt Geschäftslogik in Packages, PostgreSQL kennt dieses Konstrukt nicht — die Struktur muss ersetzt werden. T-SQL hat nie Packages gehabt. Was Sie vorfinden, sind einzelne Prozeduren, Funktionen und Views. Die haben in PL/pgSQL ein direktes Gegenstück.

Das verschiebt die Aufwandskurve spürbar. Der Posten, der Oracle-Migrationen teuer macht, existiert hier schlicht nicht.

Datentypen mit klaren Entsprechungen

Die üblichen Verdächtigen lassen sich sauber abbilden: DATETIME2 wird zu timestamp, UNIQUEIDENTIFIER zu uuid, BIT zu boolean. Die NVARCHAR-Unterscheidung verschwindet ersatzlos, weil PostgreSQL ohnehin durchgehend UTF-8 spricht.

Auch die automatischen Schlüssel sind unkritisch: IDENTITY-Spalten werden zu GENERATED AS IDENTITY, das PostgreSQL seit Version 10 als Standardsyntax mitbringt. Eine Ausnahme ist der Typ MONEY — den gibt es zwar in beiden Systemen, er verhält sich aber unterschiedlich und gehört in beiden Welten ersetzt, üblicherweise durch numeric.

Weniger Betriebs-Sonderwelt

Oracle bringt mit ASM einen eigenen Volume-Manager und mit RAC eine Cluster-Architektur mit, für die es in PostgreSQL keine Entsprechung gibt. SQL Server überlässt den Speicher ohnehin dem Betriebssystem. Der Umstieg berührt hier weniger Grundsätzliches.

Die 3 Punkte, die unterschätzt werden

1. Groß- und Kleinschreibung

Das ist der Klassiker. Er kostet oft mehr Nerven als der gesamte Datenumzug. SQL Server wird üblicherweise mit einer Sortierung installiert, die Groß- und Kleinschreibung ignoriert. WHERE name = 'meier' findet dort auch „Meier". PostgreSQL vergleicht standardmäßig exakt und findet nichts.

Das Tückische daran: Es fällt beim Testen nicht zwangsläufig auf. Die Anwendung startet, die Masken laden, die meisten Abfragen liefern Ergebnisse. Nur bestimmte Suchen liefern plötzlich leere Listen. Niemand verbindet das sofort mit der Datenbank. Dazu kommt, dass PostgreSQL unquotierte Bezeichner in Kleinbuchstaben umwandelt, während SQL Server sie in eckigen Klammern nimmt und die Schreibweise beibehält.

Beides ist lösbar, aber es ist eine Entscheidung, die früh fallen muss und die den Testaufwand bestimmt.

2. Der Rattenschwanz drumherum

Bei einer Oracle-Migration diskutiert man über RAC und Data Guard. Bei SQL Server diskutiert man über die Microsoft-Werkzeuge, die im Laufe der Jahre um die Datenbank herum gewachsen sind:

• SSIS für Datenimporte und Nachtläufe. Diese Pakete sind Anwendungen, keine Datenbankobjekte. Sie wandern nicht mit, sie werden ersetzt.
• SSRS für Berichte. Jeder Bericht ist eine kleine Anwendung mit eigener Abfrage und eigenem Layout.
• SSAS für Analysemodelle, häufig als Unterbau für Excel und Power BI.
• Verbindungsserver, über die andere Datenquellen eingebunden sind. In PostgreSQL übernehmen das Foreign Data Wrapper, aber die Abfragen müssen umgeschrieben werden.

Wer nur die Datenbank betrachtet, schätzt an dieser Stelle systematisch zu niedrig. Häufig ist dieser Block größer als die Datenbank selbst.

3. Die Windows-Anmeldung

SQL Server ist tief mit dem Active Directory verzahnt. Wer angemeldet ist, ist auch an der Datenbank angemeldet, Berechtigungen hängen an AD-Gruppen. Das ist so selbstverständlich, dass es in Migrationsplänen oft gar nicht auftaucht.

PostgreSQL kann sich ebenfalls gegen ein Verzeichnis authentifizieren, über LDAP oder Kerberos. Nur ist das nichts, was mitkommt — es ist ein eigenes Arbeitspaket, das Infrastruktur, Betrieb und Sicherheit berührt und typischerweise nicht vom Datenbankteam allein entschieden wird.

T-SQL gegen PL/pgSQL: die Kleinarbeit

Der Code selbst ist überwiegend Fleißarbeit mit wiederkehrenden Mustern. TOP wird zu LIMIT, ISNULL zu COALESCE, GETDATE() zu now(), die Zeichenkettenverkettung mit + zu ||. Temporäre Tabellen mit # werden zu CREATE TEMP TABLE, CROSS APPLY wird zu LATERAL und Fehlerbehandlung mit TRY/CATCH wandert in EXCEPTION-Blöcke.

MERGE ist ein gutes Beispiel dafür, wie sich die Lage in den letzten Jahren verbessert hat: PostgreSQL kennt den Befehl seit Version 15 und man muss ihn nicht mehr von Hand nachbauen.

Kritisch bleibt das, was ein Werkzeug nicht lesen kann. Dynamisch zusammengesetztes SQL steht erst zur Laufzeit fest und ist Handarbeit. Prozeduren, die stark mit Transaktionssteuerung arbeiten,, brauchen eine fachliche Prüfung, weil beide Systeme dort unterschiedlich ticken.

Verfügbarkeit: Always On

Läuft die Datenbank in Always On Availability Groups, gilt sinngemäß dasselbe wie beim Data-Guard-Vergleich: PostgreSQL bringt die automatische Umschaltung nicht selbst mit, gelöst ist das Problem trotzdem seit Jahren. Patroni, repmgr oder pg_auto_failover übernehmen das im Produktivbetrieb. Wie bei Microsoft und Oracle braucht es dafür eine unabhängige dritte Instanz, die die Mehrheitsentscheidung trägt.

Das ist Einrichtungs- und Betriebsaufwand, kein Ausschlusskriterium.

Wann sich der Wechsel lohnt und wann nicht

Er lohnt sich tendenziell, wenn die Anwendungen selbst entwickelt sind, die Datenbank überwiegend als Datenspeicher dient und das Reporting ohnehin modernisiert werden soll. Wenn Sie vor der Entscheidung stehen, für ein einzelnes Feature auf die Enterprise Edition zu wechseln. Vorausgesetzt, Linux ist im Haus kein Fremdkörper.

Er lohnt sich tendenziell nicht, wenn eine Standardsoftware SQL Server voraussetzt — dann entscheidet der Hersteller, nicht Sie. Wenn das halbe Berichtswesen in SSRS liegt und niemand Zeit hat, es neu zu bauen. Und wenn die Fachbereiche über SSAS-Modelle direkt in Excel arbeiten, dieser Weg also erhalten bleiben muss.

Ein Zwischenweg wird oft übersehen: Man muss nicht alles auf einmal migrieren. Der übliche Einstieg ist eine abgegrenzte Eigenentwicklung mit wenig Datenbanklogik. Das Team sammelt Erfahrung, Sie haben nach wenigen Monaten eigene Zahlen statt fremder Schätzungen.

Häufige Fragen

Ist eine Migration von SQL Server nach PostgreSQL einfacher als von Oracle?

In der Datenbank meistens ja, weil T-SQL keine Packages kennt und die Datenbanklogik in SQL-Server-Umgebungen typischerweise kleiner ausfällt. Außerhalb der Datenbank oft nein: SSIS-Pakete, SSRS-Berichte, SSAS-Modelle und die Windows-Authentifizierung sind eigene Arbeitspakete, die es in dieser Form bei Oracle nicht gibt.

Was ist der häufigste Fehler bei einer SQL-Server-Migration?

Die Sortierung zu übersehen. SQL Server vergleicht Zeichenketten üblicherweise ohne Rücksicht auf Groß- und Kleinschreibung, PostgreSQL vergleicht exakt. Der Fehler fällt beim Testen häufig nicht auf, weil die Anwendung startet und die meisten Abfragen Ergebnisse liefern — nur bestimmte Suchen bleiben leer.

Was passiert mit SSIS, SSRS und SSAS?

Diese Werkzeuge wandern nicht mit. SSIS-Strecken werden durch andere Werkzeuge ersetzt, SSRS-Berichte müssen neu gebaut werden und für SSAS-Modelle braucht es eine Entscheidung darüber, wie das Reporting künftig aussehen soll. Dieser Block gehört in die Aufwandsschätzung, sonst wird das Projekt planbar zu klein gerechnet.

Läuft PostgreSQL auch unter Windows?

Ja, PostgreSQL läuft unter Windows. In der Praxis ist der Betrieb unter Linux verbreiteter und besser dokumentiert. Wenn Windows im Haus gesetzt ist, ist das kein Hindernis, gehört aber in die Betriebsplanung.

Der ehrliche Schluss

Eine SQL-Server-Migration hat eine freundlichere Datenbank und eine unfreundlichere Umgebung als eine Oracle-Migration. Wer nur die Tabellen und Prozeduren zählt, kommt zu einem zu optimistischen Ergebnis. Wer zusätzlich aufschreibt, welche Berichte, Importstrecken und Anmeldemechanismen daran hängen, hat eine Zahl, die trägt.

Die Reihenfolge ist in beiden Fällen dieselbe: erst erheben, was tatsächlich da ist, dann bewerten, dann entscheiden. Alles andere ist Raten mit besserer Rechtschreibung.