Einführung von PostgreSQL in einer Oracle Company
Warum zahlen wir eigentlich noch 50.000 Franken pro Datenbank-Core?
Diese Frage stellte sich mein Kunde vor rund vier Jahren. Er arbeitete mit einer IT-Infrastruktur, die vollständig auf Oracle ausgerichtet war. Heute ist Oracle intern nur noch "Legacy", während rund 60 PostgreSQL-Datenbanken produktiv im Einsatz sind – hochverfügbar, sicher und vollständig automatisiert. Der Weg dorthin war kein Selbstläufer, aber strategisch absolut sinnvoll. In diesem Beitrag zeige ich, wie wir gemeinsam PostgreSQL eingeführt, professionalisiert und als neuen Standard etabliert haben.
2021 – der Anfang: ein erster Proof of Concept
Alles begann mit einer einfachen Idee: Eine Erweiterung zur Oracle-basierten Kernapplikation sollte erstmals auf PostgreSQL laufen. Für diesen Proof of Concept stand nicht die Infrastruktur, sondern die Applikation im Fokus. Ein Entwickler installierte die gewünschte PostgreSQL-Version direkt aus dem offiziellen Repository, benutzte die Default-Verzeichnisse, jedoch ohne Rücksicht auf Aspekte wie Security, Backup oder Integration ins Monitoring. Die Datenbank war offen zugänglich, unverschlüsselt und nicht in die bestehenden Infrastruktur-Systeme wie Monitoring oder Backup eingebunden, was aus heutiger Sicht kaum vorstellbar ist. Die Datenbank wurde damals nur auf Anforderung gewartet. Patches oder gar Major Updates wurden nicht eingespielt. Seitens der Oracle DBAs wurde dieser Installation keine Beachtung geschenkt. Sicherlich auch aus dem Aspekt, dass diesem Proof of Concept nur wenig Chancen auf ein Produkt gegeben wurden. So “dümpelte” das System so dahin.
2022 – der Wendepunkt: PostgreSQL wird strategisch
PostgreSQL hätte damit keine Rolle bei dem Kunden gespielt - ein wenig erfolgreicher PoC mit einer einzelnen PostgreSQL-Datenbank ohne echtes Interesse der Oracle DBAs.
Es kam jedoch anders: Mitte 2022 fiel die Entscheidung - PostgreSQL wird zur strategischen Plattform, Oracle zur Übergangslösung. In Folge dessen beauftragte man uns mit dem Aufbau einer produktionsreifen Infrastruktur. Unsere Leitlinie: die Professionalität, Robustheit und Integration in die vorhandenen Infrastrukturen resp. dem Neuaufbau derselben, die wir aus Oracle-Projekten kannten, auch auf PostgreSQL übertragen. Wir entwickelten ein umfassendes Detailkonzept auf Basis unseres Oracle Frameworks. Zentrale Punkte waren:
- Security Hardening nach CIS-Benchmark
- Auditing mit pgaudit
- standardisierte Provisionierung
- automatisiertes Deployment der Datenbanken
- Integration von Backup und Monitoring mit Checkmk
- zentrales Management mit pgAdmin4
Von Beginn an war klar, dass eine manuelle Konfiguration keine Option ist. Jede Instanz muss automatisiert, reproduzierbar und auditierbar sein. Dazu gehört auch die automatisierte Bereitstellung mittels Chef. Da im Chef Supermarket damals kein den Anforderungen vom Kunden entsprechendes PostgreSQL Cookbook gefunden wurde, wurde dies von uns selbst entwickelt. Schon die ersten PostgreSQL-Installationen konnten mit dem Cookbook erstellt werden.
Im Bereich Backup mussten wir auch für PostgreSQL eher ungewöhnliche Wege gehen. "Traditionelle" PostgreSQL-Backup-Verfahren, welche die Datenbank zuerst auf ein lokales Filesystem sichern und erst dann in ein zentrales Backup Tool überführten, kamen aufgrund der erwarteten Datenbank-Größen (die größten Oracle-Datenbanken sind ca. 30 TB und 50 TB groß) nicht in Frage. Daher suchten wir andere Wege. So bietet das Backup Tool Commvault die Möglichkeit, mittels Storage Snapshots die PostgreSQL-Datenbank(en) direkt zu sichern. Daher wurden die PostgreSQL-Datenbanken von Anfang an auf dedizierten Logical Volumes vom Linux LVM installiert.
Im Herbst hatten wir dann schon einige Installationen, so dass wir ein zentrales Management für die PostgreSQL-Datenbanken eingeführt haben. Für Oracle-Datenbanken ist der Oracle Cloud Control Enterprise Manager im Einsatz. Wir suchten für PostgreSQL ein äquivalentes Tool und haben uns für pgAdmin4 entschieden. Die Installation von pgAdmin4 erfolgte auf einer zentralen virtuellen Maschine. Es erfolgte der Anschluss an das vorhandene Active Directory sowie die Aktivierung von 2FA. Die persönlichen Einstellungen wurden in einer PostgreSQL-Datenbank gespeichert. Alle PostgreSQL-Datenbanken wurden als Shared Server in definierten Gruppen definiert, so dass diese jedem Administrator sofort zur Verfügung stehen.
2023 – Performance, Patching und Erweiterungen
2023 folgten wichtige nächste Schritte.
In Oracle gibt es das Automatic Workload Repository (kurz AWR), mit dem Performance-Auswertungen und -Analysen auch im Nachhinein gemacht werden können. Auch besteht die Möglichkeit, die gesammelten Performance-Daten über Wochen oder gar Monate aufzubewahren. Wir suchten etwas Äquivalentes für PostgreSQL und führten die beiden Erweiterungen pg_stat_statements und pg_profile ein. Da die Anzahl der PostgreSQL-Datenbanken weiter gestiegen war und für die Zukunft eine erhebliche Steigerung erwartet wurde, musste die Installation und Konfiguration dieser Erweiterungen auch automatisiert erfolgen. Wir erweiterten daher das vorhandene Chef Cookbook. Inzwischen können auch Updates von pg_profile automatisiert erfolgen. Wie bei den Oracle-Datenbanken und den AWR Snapshots erstellen wir auch in PostgreSQL stündlich ein pg_profile Sample. In einem Confluence Space haben wir die Erstellung und das Customizing von pg_profile ausführlich dokumentiert.
Aufgrund der inzwischen großen Anzahl von PostgreSQL-Datenbanken und -Servern gingen wir auch das Thema Patching an. Auch das sollte so einfach wie möglich auf vielen Servern (gleichzeitig) erfolgen. Daher erweiterten wir auch hier das Chef Cookbook um Recipes für das automatisierte Patching. Das Recipe beinhaltet heute das Stoppen der PostgreSQL-Datenbanken, Aktivieren der benötigten Repositories, Updates der PostgreSQL RPMs (und nur dieser) sowie den anschließenden Start der Datenbanken sowie eventuell notwendiger Updates der Extensions.
So konnten wir die PostgreSQL-Umgebung deutlich näher an das gewohnte Niveau aus der Oracle-Welt bringen, bei gleichzeitiger Offenheit, Flexibilität und geringeren Betriebskosten.
2024 – Backup-Duplizierung und zentrales Log Reporting
Anfang 2024 kam ein neues Anliegen auf: Die Produktionsdatenbank sollte täglich auf einen zweiten Server dupliziert werden, als sichere Testumgebung für Problemanalysen. Mit Hilfe unseres Backup Tools und zusätzlicher Scripting-Komponenten wurde diese Anforderung zuverlässig umgesetzt.
Zusätzlich führten wir pgBadger, ein leistungsfähiges Tool zur Log-Auswertung, ein. Auch hier erfolgte die Installation und Konfiguration wieder über ein neues Recipe für das Chef Cookbook. Die Reports werden täglich dezentral erzeugt, auf einen zentralen Server transferiert und dort in den Webserver integriert. So behalten die DBAs jederzeit den Überblick über Anomalien, Query-Verhalten und Lastspitzen.
Aufgrund des Support-Endes von RHEL-7 haben wir in 2024 auch die Umstellung auf das neue RHEL-9 Betriebssystem durchgeführt. Dabei führten wir für die PostgreSQL-Systeme ein “Out of Place”-Update mittels Erzeugen einer neuen RHEL-9-VM und dem Verschieben der PostgreSQL-Datenbank-Disks von der alten zur neuen VM durch. Das PostgreSQL Release wurde dabei aber bewusst nicht geändert.
In der Zwischenzeit sind ca 40 PostgreSQL-Datenbanken beim Kunden im Einsatz.
Status 2025 – standardisiert, stabil, skalierbar
Heute betreibt der Kunde rund 70 PostgreSQL-Datenbankserver, alle:
- vollautomatisiert provisioniert
- mit integriertem Security-, Backup- und Monitoring-Konzept
- mit automatisch aktivierten Erweiterungen
- auf RHEL-9 virtuellen Servern
- mit PostgreSQL Releases von 14 bis 16
Der Unterschied zur Ausgangslage 2021 ist frappant. PostgreSQL ist heute nicht nur akzeptiert, sondern wird von Entwicklern, Betriebsverantwortlichen und Management gleichermaßen geschätzt.
Ausblick: Major Updates stehen bevor
Den nächsten Herausforderungen stellen - unsere Planung:
Die PostgreSQL-Version 14 wird nur noch bis November 2026 unterstützt. Wir evaluieren aktuell die Strategie für ein möglichst reibungsloses Major Upgrade auf Version 18. Interessant werden dabei das Thema AsyncIO und mögliche Auswirkungen auf die Performance.
Immer mal wieder ist in den letzten Jahren das Thema Connection Pooling hervorgetreten. Da wir die Anzahl der PostgreSQL Connections aber bisher noch im Rahmen halten konnten, wurde das Thema noch nicht weiter verfolgt. Wir rechnen jedoch in den nächsten Jahren mit steigenden Connection-Zahlen, so dass wir uns das Thema in 2026 sicherlich anschauen müssen.
Auch stehen aktuell die ersten Datenbank-Migrationen von Oracle auf PostgreSQL an. Erste Versuche mit den Tools der Applikations-Hersteller verliefen nicht erfolgversprechend, so dass wir hier auch auf Tools aus der PostgreSQL-Welt zurückgreifen werden.
Fazit
PostgreSQL kann Oracle nicht nur ergänzen, sondern langfristig ersetzen, wenn man es richtig angeht. Mein wichtigstes Learning aus diesem Projekt: Der Erfolg steht und fällt mit Automatisierung, Security-Standards und konsequenter Integration. Wer diese Faktoren berücksichtigt, kann nicht nur Lizenzkosten sparen, sondern auch eine hochgradig stabile und flexible Datenbanklandschaft etablieren, ganz ohne Vendor Lock-in.
