Wem gehört deine Datenbank? Oracle, PostgreSQL und die Frage der Unabhängigkeit

Wer beruflich zwischen Oracle und PostgreSQL pendelt, kennt diese eine Frage, die oft in vielen Kundengesprächen fällt: „Was ist denn jetzt eigentlich besser?“ Die ehrliche Antwort lautet: Die Frage muss anders gestellt werden. Die richtige Fragen sind, wofür man es braucht, wer es betreibt, wo es betrieben wird und was es kosten darf (und damit meine ich nicht in Lizenzgebühren). Es wird Zeit für eine unaufgeregte Einordnung.

Enterprise vs. Community – eine kurze Begriffsklärung

Die Oracle Datenbank ist ein kommerzielles Enterprise-Produkt. Eine Firma entwickelt es, verkauft Lizenzen, definiert die Roadmap und steht mit Support-Verträgen dafür gerade, wenn etwas nicht funktioniert. Das ist bequem, hat aber einen Preis. Im wahrsten Sinne des Wortes.

PostgreSQL ist Community-Open-Source. Kein Konzern besitzt es, niemand verkauft Lizenzen für die Nutzung der Datenbank selbst, und die Weiterentwicklung liegt in den Händen eines globalen, freiwilligen Entwicklerkreises unter dem Dach der PostgreSQL Global Development Group. Wenn von „Enterprise PostgreSQL“ die Rede ist, so ist damit meist ein kommerzielles Zusatzangebot gemeint, welches zusätzliche Funktionalitäten, Tools und Support mitbringt.

Diese Unterscheidung ist keine akademische Fußnote. Sie bestimmt, wem man vertraut, wenn eine kritische Sicherheitslücke auftaucht oder ein Major Release ansteht.

Warum es wichtig ist, dass Postgres niemandem gehört

Hier wird es interessant, denn genau das ist der Punkt, den viele Entscheider:innen unterschätzen. Die Datenbanksoftware Oracle gehört dem Unternehmen Oracle. Die Roadmap folgt den Interessen von Oracle. Ein Lizenzmodell, eine Cloud-Strategie, eine Feature-Priorisierung, alles liegt in einer Hand. Das ist legitim, ein Unternehmen darf Geld verdienen wollen. Aber es bedeutet: Die Datenbankstrategie hängt an der Strategie eines einzelnen Anbieters.

PostgreSQL hat diesen Single Point of Failure nicht. Niemand kann das Projekt nach aktuellem Stand „aufkaufen“ und die Lizenzbedingungen über Nacht ändern. Dies ist ein reales Szenario, das bei anderen Open-Source-Projekten mit Business Source License oder ähnlichen „Open-Source-mit-Sternchen“-Modellen durchaus schon vorgekommen ist. So geschehen bei MongoDB, Elastic und Redis. Postgres läuft unter der freizügigen PostgreSQL-Lizenz, und die Governance liegt bei einem Kernteam und Entwickler:innen aus verschiedenen, konkurrierenden Firmen. Genau diese Verteilung auf viele Schultern macht das Projekt widerstandsfähig gegen genau die Art von strategischem Kurswechsel, die Oracle-Kunden in der Vergangenheit öfter kalt erwischt hat. Das ist der eigentliche Wert von Open Source Governance: nicht „kostenlos“, sondern unabhängig.

Die Kehrseite: Open Source ist kein Selbstläufer

Jetzt der Realitätscheck, denn Romantik hilft niemandem beim Betrieb einer Produktivdatenbank. „Community Support“ klingt gut, bedeutet in der Praxis aber: Mailinglisten, Foren, vielleicht ein hilfsbereiter Mensch oder die KI, aber keine vertragliche Reaktionszeit, kein Eskalationspfad und kein Rückruf um drei Uhr nachts. Wenn die Produktionsdatenbank steht, ist „warten, bis jemand aus der Mailing-Liste antwortet“ keine Option.

Deshalb kaufen ernsthafte PostgreSQL-Anwender:innen in der Regel doch Support, nur eben von einem Drittanbieter statt vom Datenbankhersteller selbst. Das bringt neue Fragen mit sich: Welcher Anbieter passt zu meinem Stack? Bekomme ich Patches genauso schnell wie im Community-Projekt oder hängt der Anbieter dem Upstream hinterher? Wie tief ist das Know-how wirklich, wenn es um „Exotisches“ wie Logical Replication über mehrere Major-Versionen oder Extension-Kompatibilität geht? Open Source macht also doch nicht zwingend unabhängig, sondern verlagert die Abhängigkeit. Man tauscht Lizenzabhängigkeit gegen Wissens- und Betriebsabhängigkeit im eigenen Team oder eine neue vertragliche Abhängigkeit vom Support-Partner.

Wann sich Oracle trotzdem lohnt

Genau deshalb bin ich vorsichtig mit dem reflexartigen „Oracle raus, Postgres rein“. Es gibt Szenarien, in denen der hohe Lizenzpreis absolut gerechtfertigt ist.

Wer Workloads mit extremer Kritikalität fährt, zum Beispiel Kernbankensysteme, große ERP-Landschaften oder Umgebungen mit Zero-Downtime-Anspruch, kauft mit der Oracle-Lizenz auch jahrzehntelang gehärtete, hochgradig ausgereifte Hochverfügbarkeits- und Disaster-Recovery-Mechanismen: Real Application Clusters, Data Guard, RMAN und Exadata-Storage-Optimierungen, die auf genau diese Datenbank zugeschnitten sind. Dazu ein Support, bei dem man im Ernstfall tatsächlich einen Menschen mit Root-Cause-Wissen ans Telefon bekommt, vertraglich zugesichert. Wer diese Tiefe braucht und sie selbst nicht im eigenen Team aufbauen kann oder möchte, kauft sich mit der Lizenz nicht „nur eine Datenbank“, sondern Betriebssicherheit als Produkt. Die Kosten dafür sind hoch, relativieren sich jedoch, wenn man sich vor Augen hält, wie hoch die Ausfallkosten für einen ungeplanten Ausfall sind.

Mein Wechsel zwischen den Welten

Ich komme aus der Oracle-Welt: RAC, Data Guard, RMAN, OEM waren jahrelang mein tägliches Handwerkszeug. Der Umstieg auf PostgreSQL war weniger ein Technologiewechsel als ein Perspektivwechsel. Bei Oracle bekommt man Hochverfügbarkeit und Sicherheit weitgehend fertig verpackt. Man konfiguriert ein mächtiges, aber auch komplexes Werkzeug. Bei PostgreSQL baut man sich dieselben Eigenschaften oft aus einzelnen, bewusst gewählten Bausteinen selbst zusammen: eine freie Wahl von Replikationsverfahren und -topologien, Patroni oder pg_auto_failover als Hochverfügbarkeitslösung, pgBackRest oder Barman als Backup-Software.

Das verändert die Arbeit spürbar. Von „Wie konfiguriere ich folgendes Feature richtig?“ hin zu „Welche Komponenten kombiniere ich zu einer Architektur, die meinen Anforderungen entspricht?“. Es ist mehr Verantwortung, aber auch mehr Transparenz – man versteht am Ende genau, warum das System tut, was es tut, weil man es selbst zusammengesetzt hat. Der rote Faden bleibt in beiden Welten derselbe: Hochverfügbarkeit und Sicherheit sind nicht verhandelbar, egal ob man das über eine Oracle-Lizenz einkauft oder über eine sauber durchdachte Open-Source-Architektur selbst baut.

Fazit: Keine Bright Side, keine Dark Side

Ich bin bei einer Erkenntnis gelandet, die wenig glamourös, aber ehrlich ist: Beide Welten haben ihre Daseinsberechtigung und keine ist per se die bessere. Oracle ist keine Dinosaurier-Technologie für Leute, die sich nicht trauen umzusteigen. Es ist die richtige Wahl für bestimmte Anforderungsprofile. PostgreSQL ist keine „kostenlose Notlösung“ für Kund:innen mit kleinem Budget. Es ist für viele Workloads schlicht die technisch und strategisch bessere Antwort.

Die eigentliche Gefahr liegt nicht in der Technologiewahl, sondern im Fanatismus auf beiden Seiten: Oracle-Berater:innen, die jede Alternative kleinreden und Postgres-Enthusiastinnen, die jede Enterprise-Datenbank für überteuerten Ballast halten. Als Beraterin schulde ich meinen Kunden keine Loyalität zu einer Technologie, sondern eine ehrliche Einschätzung, welche Lösung zu ihren Anforderungen, ihrem Team und ihrem Risikobudget passt. Manchmal ist das Oracle, manchmal ist das PostgreSQL und manchmal, das gehört zur Wahrheit dazu, ist die beste Antwort ein hybrides Setup, das beide Welten kombiniert.

Wer wie ich aus der Oracle-Welt kommt und gerne in die Welt der PostgreSQL-Datenbank schauen möchte, ist bei unserem Seminar „PostgreSQL für Oracle DBAs“ herzlich willkommen.

Seminarempfehlung