Von Oracle zu PostgreSQL: was die Migration wirklich kostet

Die Rechnung sieht auf den ersten Blick einfach aus: Oracle kostet Lizenz und Support, PostgreSQL kostet keine Lizenz, also spart der Wechsel Geld. An dieser Verkürzung scheitern die meisten Migrationsvorhaben, und zwar erst dann, wenn schon Geld ausgegeben ist. Dieser Artikel zeigt, wo der Aufwand tatsächlich liegt und wie Sie zu einer Zahl kommen, die einer internen Prüfung standhält.

Die kurze Antwort

Wenn Sie es eilig haben:

• Die eingesparte Lizenz ist der einfachste Posten der Rechnung. Er ist bekannt, er steht im Vertrag, er lässt sich ausrechnen.
• Der Aufwand des Wechsels liegt fast nie in den Daten. Tabellen und Inhalte umzuziehen ist weitgehend Werkzeugarbeit.
• Teuer wird, was an der Datenbank hängt: die über Jahre gewachsene Logik in PL/SQL, die Oracle-Eigenheiten im Anwendungscode und der Testaufwand.
• Deshalb ist die erste sinnvolle Investition keine Migration, sondern eine Bestandsaufnahme. Wer die überspringt, schätzt ins Blaue.

Warum die gesparte Lizenz nicht die Rechnung ist

Oracle-Konditionen sind verhandelt und individuell, öffentliche Listenpreise sagen wenig über das aus, was ein konkretes Haus tatsächlich zahlt. Was sich generell sagen lässt: Der Posten ist meist gut sichtbar, er wiederholt sich jährlich und er wächst mit Kernen, Nutzern oder Optionen. Deshalb landet er regelmäßig auf der Sparliste.

Die Kehrseite: Weil der Einsparbetrag so gut sichtbar ist, wird er zum Anker der ganzen Diskussion. Der Aufwand auf der anderen Seite ist unsichtbar, solange ihn niemand erhoben hat. Eine unsichtbare Zahl gegen eine sichtbare zu stellen, führt entweder zu übertriebenem Optimismus oder zu pauschaler Ablehnung. Beides sind keine Entscheidungen, sondern Vermutungen.

Die 4 Posten, die den Aufwand treiben

1. Die Logik, die in der Datenbank steckt

Das ist der mit Abstand größte Posten. In gewachsenen Oracle-Umgebungen liegt oft erhebliche Geschäftslogik in Packages, Prozeduren, Funktionen und Triggern. Ein Teil davon lässt sich mit überschaubarem Aufwand nach PL/pgSQL überführen, weil die Konzepte ähnlich sind. Ein anderer Teil nutzt Konstrukte, für die es in PostgreSQL keine direkte Entsprechung gibt. Der muss neu gedacht werden.

Der entscheidende Punkt ist nicht die Zeilenzahl, sondern die Verteilung. 50.000 Zeilen gleichförmiger CRUD-Prozeduren sind harmlos. 5.000 Zeilen, die tief in Oracle-Eigenheiten sitzen, können mehr Arbeit machen. Wer den Aufwand schätzen will, muss diese Verteilung kennen und nicht nur die Gesamtmenge.

Hilfreich ist dabei ein Gefälle, das sich quer durch alle Projekte zieht. Tabellen und Daten sind fast vollständig automatisierbar, weil die Struktur in beiden Systemen nach demselben Standard beschrieben ist und sich das Ergebnis über Zeilenzahlen prüfen lässt. Views, Funktionen und Prozeduren haben ein Gegenstück, solange sie für sich stehen: Dort geht es meist um Typnamen und Schreibweisen. Sobald sie Teil eines Packages sind oder auf dessen Zustand zugreifen, wird daraus Umbau. Trigger werden aufwendiger, weil PostgreSQL Trigger und Triggerfunktion trennt: aus einem Objekt werden zwei. PostgreSQL kennt keine Packages, die Struktur muss ersetzt werden. Dynamisches SQL ist reine Handarbeit, weil der Inhalt erst zur Laufzeit feststeht und kein Werkzeug ihn vorher lesen kann.

Der eigentliche Grund für dieses Gefälle ist die Prüfbarkeit. Eine Tabelle ist richtig oder falsch übertragen, das zeigt ein Vergleich. Eine Prozedur kann fehlerfrei durchlaufen und trotzdem ein falsches Ergebnis liefern. Deshalb können 2 gleich große Datenbanken im Aufwand um ein Vielfaches auseinanderliegen.

2. Oracle-spezifische Funktionen und Datentypen

Vieles hat in PostgreSQL eine Entsprechung, manches heißt nur anders, einiges fehlt oder funktioniert grundlegend anders. Typische Kandidaten sind proprietäre Erweiterungen, Besonderheiten bei Datums- und Zeitverarbeitung, Sequenzen und automatische Schlüssel, Hierarchie-Abfragen sowie Zusatzoptionen, die separat lizenziert sind und deren Wegfall nicht nur technisch, sondern fachlich zu klären ist.

Diese Liste lässt sich nicht allgemein abarbeiten. Sie hängt davon ab, was Ihre Anwendungen tatsächlich benutzen. Das weiß niemand aus dem Kopf.

3. Die Anwendungen, die daran hängen

Der Posten, der am häufigsten unterschätzt wird. Eine Datenbank steht selten allein: Fachanwendungen, Schnittstellen, Reporting-Strecken, Import- und Exportjobs, ältere Werkzeuge, an die sich kaum noch jemand erinnert. Überall dort können Treiber, Verbindungszeichenfolgen und vor allem Oracle-spezifisches SQL im Anwendungscode stecken.

Bei eigenentwickelter Software ist das Fleißarbeit mit kalkulierbarem Risiko. Bei zugekaufter Standardsoftware entscheidet der Hersteller, ob PostgreSQL unterstützt wird. Falls nicht, ist die Frage an dieser Stelle beantwortet, und zwar unabhängig davon, wie attraktiv die Einsparung wäre.

Ein Planungsfehler kostet hier regelmäßig mehr als die Arbeit selbst: Wird der Anwendungsstrang erst nach der Datenbankarbeit gestartet, laufen 2 Arbeitspakete nacheinander, die parallel laufen könnten. Die Projektlaufzeit wächst dann um die volle Dauer des Anwendungsteils, ohne dass irgendjemand mehr Arbeit geleistet hätte.

4. Test und Abnahme

Der Posten, den Projektpläne gern auf die letzten 2 Wochen legen. Bei einem Datenbankwechsel reicht es nicht, dass die Anwendung startet. Sie muss dieselben Ergebnisse liefern: gleiche Summen, gleiche Sortierung, gleiches Verhalten bei Sonderfällen, vergleichbare Antwortzeiten unter Last. Sortierreihenfolgen und Zeichensatzfragen sind ein klassischer Stolperstein, weil die Abweichungen klein und trotzdem fachlich relevant sind.

Als Faustregel aus der Praxis mit Migrationen allgemein: Wer den Testaufwand nicht mindestens so hoch ansetzt wie die eigentliche Umstellung, plant zu knapp.

Was den Wechsel wirklich blockiert und was nur Aufwand ist

In Migrationsdiskussionen werden regelmäßig 4 Oracle-Funktionen als Ausschlusskriterium ins Feld geführt. Bei genauem Hinsehen ist davon genau 1 ein echter Blocker. Die anderen 3 sind Aufwandsposten, die in die Rechnung gehören, aber keine Entscheidung vorwegnehmen. Die Unterscheidung lohnt sich, weil sie in beide Richtungen vor Fehlern schützt.

Der echte Blocker

Zertifizierte Fremdsoftware. Unterstützt der Hersteller Ihrer Anwendung ausdrücklich nur Oracle, kostet ein Wechsel ohne Freigabe den Support für die gesamte Anwendung. Das ist eine Vertragsfrage und keine technische, deshalb lässt sie sich auch nicht wegentwickeln. Nachfragen lohnt trotzdem: Die Zertifizierungslisten werden erweitert und bei manchen Herstellern steht PostgreSQL längst drauf.

Der Sonderfall

Real Application Clusters. Mehrere Server arbeiten gleichzeitig schreibend auf derselben Datenbank. Das kann PostgreSQL nicht, dort hält jeder Server seine eigene Kopie und nur einer darf schreiben. Wer diese Architektur wirklich braucht, baut mehr um als die Datenbank.

Die ehrliche Rückfrage lautet aber: Brauchen Sie RAC oder haben Sie RAC? Ein erheblicher Teil der Installationen läuft aus Verfügbarkeitsgründen im Cluster, nicht wegen der Schreiblast. Wenn Ausfallsicherheit der eigentliche Zweck ist, führt der Weg über den nächsten Punkt und nicht über eine Architekturentscheidung.

Die 2 Punkte, die nur Arbeit sind

Automatisches Failover. Oracle löst das mit Data Guard und Fast-Start Failover. PostgreSQL bringt die Umschaltung nicht selbst mit, das ist richtig. Gelöst ist das Problem trotzdem, und zwar seit Jahren: Patroni, repmgr oder pg_auto_failover übernehmen diese Aufgabe im Produktivbetrieb. Sie brauchen dafür eine unabhängige Instanz, die die Mehrheitsentscheidung trägt, damit sich nicht 2 Server gleichzeitig für den neuen Primary halten. Das wird gern als PostgreSQL-Schwäche verkauft, ist aber keine: Auch Oracle setzt für Fast-Start Failover einen Observer voraus, der auf einem dritten Host laufen muss und ohne den die automatische Umschaltung nicht stattfindet. Die Architektur ist auf beiden Seiten dieselbe, die Bausteine heißen nur anders. Was bleibt, ist Einrichtungs- und Betriebsaufwand, kein Grund, bei Oracle zu bleiben.

Storage-Verwaltung. Oracle bringt mit ASM einen eigenen Volume-Manager mit. PostgreSQL überlässt das dem Betriebssystem oder dem Storage-System, also LVM, Software-RAID oder schlicht dem SAN. Die Aufgabe verschwindet nicht, sie wechselt den Zuständigen. In den meisten Rechenzentren macht das ohnehin längst jemand anderes als das Datenbankteam.

Wer diese 3 Punkte als Ausschlusskriterium präsentiert bekommt, sollte nachfragen, ob damit „geht nicht" oder „kostet Einrichtungszeit" gemeint ist. Der Unterschied entscheidet über das Projekt.

Ein Hinweis, der in der Praxis viel Ärger spart: Diese Bewertung gilt je Datenbank und nicht für das ganze Haus. In den meisten Häusern laufen mehrere Oracle-Datenbanken mit völlig unterschiedlichem Profil. Nichts spricht dagegen, jede einzeln zu bewerten und nur einen Teil zu wechseln.

Was meistens einfacher ist als befürchtet

Damit das Bild nicht schief wird: Einiges spricht klar für die Machbarkeit. Der reine Datenumzug ist heute weitgehend Werkzeugarbeit. Tabellenstrukturen, Indizes und Constraints lassen sich in hohem Maß automatisiert übertragen. PostgreSQL ist als Datenbank ausgereift, hat für die allermeisten betrieblichen Anforderungen die passenden Funktionen und wird von jedem gängigen Anwendungsframework unterstützt.

Auch die Betriebsseite ist kein Hindernis mehr. Sicherung, Wiederherstellung, Replikation, Hochverfügbarkeit und Überwachung sind gelöste Probleme mit etablierten Werkzeugen. Was es braucht, ist Personal, das damit umgehen kann. Das ist eine Frage von Schulung und nicht von Technik.

Lizenzfrei heißt nicht kostenlos

Damit die Rechnung ehrlich bleibt, gehört die andere Richtung dazu. PostgreSQL verlangt keine Lizenzgebühr, das steht in jedem Werbematerial. Was dort meist fehlt, kostet trotzdem Geld:

• Support mit Zusage. Community-Hilfe über Mailinglisten und Foren ist kostenlos, kommt aber ohne vertragliche Reaktionszeit. Wer eine verbindliche Zusage braucht, bucht sie bei einem Drittanbieter. Diese Gebühr ersetzt dann einen Teil der bisherigen Oracle-Supportkosten.
• Betriebsaufwand in der Einarbeitung. Ihr Team administriert ein neues System ohne die über Jahre gewachsene Routine. Der Mehraufwand sinkt mit der Zeit, ist am Anfang aber real und gehört eingeplant.
• Werkzeuge. Manches, was bei Oracle im Lieferumfang steckte, muss unter PostgreSQL separat ausgewählt und eingerichtet werden.
• Wissensaufbau. Schulung und Einarbeitungszeit sind ein einmaliger, aber realer Posten.

Ein Posten fehlt zudem in fast jedem Projektplan: Während der Migration läuft der Oracle-Vertrag weiter. Sie zahlen für eine Übergangszeit beides, das alte System und den Aufbau des neuen. Je länger das Projekt dauert, desto größer wird dieser Posten. Das ist ein weiteres Argument für einen eng geschnittenen Pilot statt eines Big Bang.

Diese Posten machen den Wechsel selten unwirtschaftlich. Sie verschieben aber den Zeitpunkt, ab dem er sich rechnet. Wer sie unterschlägt, produziert genau die Überraschung, die solchen Projekten später den Rückhalt entzieht.

Wann sich der Wechsel lohnt und wann nicht

Er lohnt sich tendenziell, wenn die Anwendungen selbst entwickelt sind oder von einem Hersteller stammen, der PostgreSQL ohnehin unterstützt. Wenn die Datenbank überwiegend als Datenspeicher genutzt wird und die Geschäftslogik in der Anwendung liegt. Wenn ohnehin eine Modernisierung ansteht, in deren Rahmen der Wechsel mitlaufen kann. Wenn eigene Datenbankleute da sind, die das Ziel danach betreiben können.

Er lohnt sich tendenziell nicht, wenn eine Standardsoftware Oracle voraussetzt. Wenn die halbe Fachlogik in Packages liegt, die niemand mehr vollständig versteht. Wenn kein Budget für ernsthaftes Testen vorhanden ist. Wenn die Erwartung lautet, das nebenher zu erledigen. Ein Datenbankwechsel ist ein Projekt und kein Wartungsfenster.

Wer statt Oracle einen Microsoft SQL Server ablösen will, findet die Unterschiede in einem eigenen Artikel: SQL Server nach PostgreSQL — was leichter ist als bei Oracle und was nicht. Kurz gesagt: in der Datenbank einfacher, drumherum aufwendiger.

Ein Zwischenweg wird oft übersehen: Man muss nicht alles migrieren. Der übliche Einstieg sind Datenbanken hinter Eigenentwicklungen mit wenig Datenbank-Code. Der Aufwand bleibt überschaubar, das Team sammelt Erfahrung und erst danach folgt eine größere oder kritischere Datenbank. Das senkt das Risiko und liefert nach wenigen Monaten belastbare eigene Zahlen statt fremder Schätzungen.

Ein Nebeneffekt, den viele erst spät entdecken: Eine Migration ist die beste Gelegenheit, Altlasten loszuwerden. Objekte, die seit Jahren niemand aufruft, werden sonst mitkonvertiert und mitgeprüft. Jedes davon kostet Zeit im teuersten Schritt des Projekts, ohne dass am Ende jemand den Nutzen benennen kann. Ausmisten vor der Migration ist billiger als danach.

Wie man zu einer belastbaren Zahl kommt

Die Reihenfolge, die sich bewährt hat, ist unspektakulär. Zuerst erheben, was tatsächlich vorhanden ist: Schemata, Objekte, Menge und Art der Datenbanklogik, angehängte Systeme. Dann bewerten, welche Teile davon direkt übertragbar sind, welche angepasst werden müssen und welche Neuentwicklung bedeuten. Daraus ergibt sich eine Aufwandsbandbreite nach Datenbank, Anwendungen und Test, dazu die Liste der offenen Risiken. Erst mit diesen Zahlen ist die Entscheidung überhaupt entscheidbar.

Wichtig dabei: Das Ergebnis muss ergebnisoffen sein dürfen. Eine Bestandsaufnahme, die immer zur Migration rät, ist keine Bestandsaufnahme. In manchen Häusern lautet die richtige Empfehlung, es zu lassen oder auf einen späteren Zeitpunkt zu vertagen, an dem eine Anwendung ohnehin abgelöst wird.

Häufige Fragen

Was kostet eine Migration von Oracle nach PostgreSQL?

Eine seriöse Pauschalzahl gibt es nicht, weil der Aufwand fast vollständig davon abhängt, wie viel Geschäftslogik in der Datenbank liegt und wie viele Anwendungen daran hängen. Der Datenumzug selbst ist der kleinste Teil. Belastbar wird die Zahl erst nach einer Bestandsaufnahme der Datenbankobjekte und der angebundenen Systeme.

Wie lange dauert eine Oracle-Migration?

Das hängt vom selben Faktor ab. Ein abgegrenztes System mit wenig Datenbanklogik kann in Wochen umgestellt sein, eine gewachsene Landschaft mit umfangreichen PL/SQL-Paketen und mehreren angebundenen Anwendungen beschäftigt ein Team über Monate. Sinnvoll ist fast immer ein Pilot mit einem klar abgegrenzten Teil, statt alles auf einmal anzugehen.

Kann man PL/SQL automatisch nach PL/pgSQL übersetzen?

Teilweise. Es gibt Werkzeuge dafür, allen voran das quelloffene Ora2Pg, die einen erheblichen Anteil des Codes maschinell überführen. Bei gleichförmigem Code funktioniert das gut. Der Rest braucht manuelle Arbeit und fachliches Verständnis, weil es um Konstrukte geht, die in PostgreSQL anders gelöst werden. Ein Werkzeug ersetzt die Prüfung nicht, es verkürzt sie.

Ist PostgreSQL für unternehmenskritische Systeme geeignet?

Ja. PostgreSQL wird seit Jahren in großem Maßstab produktiv eingesetzt, auch im Finanz- und Behördenumfeld. Sicherung, Replikation, Hochverfügbarkeit und Überwachung sind mit etablierten Werkzeugen abgedeckt. Voraussetzung ist wie bei jeder Datenbank, dass jemand im Haus sie sicher betreiben kann.

Der ehrliche Schluss

Der Wechsel von Oracle zu PostgreSQL ist für viele Häuser sinnvoll und für manche nicht. Was beide Fälle verbindet: Ohne eine Bestandsaufnahme lässt sich nicht sagen, welcher Fall vorliegt. Die Lizenzersparnis kennen Sie ohnehin schon, sie steht im Vertrag. Was fehlt, ist die andere Seite der Rechnung. Wer die erhebt, entscheidet auf Basis von Zahlen. Wer sie überspringt, verlängert am Ende wieder die Lizenz, weil niemand das Risiko einer unbekannten Größe verantworten will.