credativ auf der PostgreSQL Conference Europe 2025 vertreten

Die European PostgreSQL Conference (PGConf.EU) ist eine der größten PostgreSQL-Veranstaltungen weltweit. Dieses Jahr fand sie vom 21. bis 24. Oktober in Riga, Lettland, statt. Unser Unternehmen, die credativ GmbH, war Bronzesponsor der Konferenz, und ich hatte das Privileg, credativ mit meinem Vortrag „Database in Distress: Testing and Repairing Different Types of Database Corruption“ zu vertreten. Zusätzlich war ich am Donnerstag und Freitag als Session-Host tätig. Die Konferenz selbst deckte ein breites Spektrum an PostgreSQL-Themen ab – von Cloud-nativen Bereitstellungen bis zur KI-Integration, von großen Migrationen bis zur Ausfallsicherheit. Nachfolgend finden Sie Höhepunkte der von mir besuchten Sessions, nach Tagen geordnet.

Mein Vortrag über Datenbankkorruption

Ich präsentierte meinen Vortrag am Freitagnachmittag. Darin tauchte ich in reale Fälle von PostgreSQL-Datenbankkorruption ein, denen ich in den letzten zwei Jahren begegnet bin. Um diese Probleme zu untersuchen, entwickelte ich ein Python-Tool, das Datenbankseiten absichtlich beschädigt, und untersuchte anschließend die Ergebnisse mithilfe der PostgreSQL-Erweiterung pageinspect. Während des Vortrags demonstrierte ich verschiedene Korruptionsszenarien und die von ihnen erzeugten Fehler und erklärte, wie jeder Fall zu diagnostizieren ist. Ein wichtiger Punkt war, dass PostgreSQL 18 Daten-Checksums standardmäßig bei initdb aktiviert. Checksums ermöglichen es, beschädigte Seiten während der Wiederherstellung zu erkennen und sicher „auf Null zu setzen“ (beschädigte Daten zu überspringen). Ohne Checksums können nur Seiten mit eindeutig beschädigten Headern automatisch mit der Einstellung zero_damaged_pages = on entfernt werden. Andere Arten von Korruption erfordern eine sorgfältige manuelle Wiederherstellung. Abschließend schlug ich Verbesserungen (im Code oder in den Einstellungen) vor, um die Wiederherstellung auf Clustern ohne Checksums zu erleichtern.

Dienstag: Kubernetes- und KI-Gipfel

Der Dienstag begann mit zwei halbtägigen Gipfeltreffen. Der PostgreSQL on Kubernetes Summit untersuchte den Betrieb von Postgres in Cloud-nativen Umgebungen. Die Referenten verglichen Kubernetes-Operatoren (CloudNativePG, Crunchy, Zalando usw.), Backup/Recovery in Kubernetes, Skalierungsstrategien, Monitoring und Zero-Downtime-Upgrades. Sie diskutierten Operator-Architekturen und Multi-Tenant-DBaaS-Anwendungsfälle. Die Teilnehmer erhielten praktische Einblicke in die Kompromisse verschiedener Operatoren und wie Kubernetes-basiertes Postgres für Hochverfügbarkeit betrieben werden kann.

Im PostgreSQL & AI Summit untersuchten Experten die Rolle von Postgres in KI-Anwendungen. Zu den Themen gehörten Vektorsuche (z. B. pgvector), hybride Suche, die Nutzung von Postgres als Kontextspeicher für KI-Agenten, konversationelle Abfrageschnittstellen und sogar die Optimierung von Postgres mit maschinellem Lernen. Die Referenten teilten Best Practices und Integrationsstrategien für den Aufbau KI-gesteuerter Lösungen mit Postgres. Kurz gesagt, der Gipfel untersuchte, wie PostgreSQL KI-Workloads dienen kann (und umgekehrt) und welche neuen Funktionen oder Erweiterungen für KI-Anwendungsfälle entstehen.

Mittwoch: Migrationen, Modellierung und Performance

Joaquim Oliveira (European Space Agency) erörterte die Verlagerung von Astronomie-Datensätzen (von den ESA-Missionen Gaia und Euclid) von Greenplum. Das Team erwog sowohl die Skalierung mit Citus als auch den Umzug in das neue Greenplum-basierte Cloud-Warehouse von EDB. Er behandelte die praktischen Vor- und Nachteile jedes Ansatzes sowie die betrieblichen Änderungen, die für die Neugestaltung solcher Exascale-Workloads erforderlich sind. Die wichtigste Erkenntnis war die Notwendigkeit, Architektur, Tools und administrative Änderungen zu planen, bevor eine Petabyte-Skala-Migration durchgeführt wird.

Boriss Mejias (EDB) betonte, dass die Datenmodellierung für Softwareprojekte von grundlegender Bedeutung ist. Anhand einer Schach-Turnier-Anwendung zeigte er, wie PostgreSQL die Datenintegrität durchsetzen kann. Durch die sorgfältige Auswahl von Datentypen und Constraints können Entwickler einen Großteil der Geschäftslogik direkt im Schema einbetten. Der Vortrag demonstrierte, wie man „PostgreSQL die Datenintegrität garantieren lässt“ und Anwendungslogik auf der Datenbankebene aufbaut.

Roberto Mello (Snowflake) beleuchtete die vielen Verbesserungen bei Optimierern und der Ausführung in Postgres 18. Zum Beispiel eliminiert der Planer nun automatisch unnötige Self-Joins, wandelt IN (VALUES…) Klauseln in effizientere Formen um und transformiert OR-Klauseln in Arrays für schnellere Index-Scans. Er beschleunigt auch Mengenoperationen (INTERSECT, EXCEPT), Window-Aggregates und optimiert SELECT DISTINCT und GROUP BY durch Neuanordnung von Schlüsseln und Ignorieren redundanter Spalten. Roberto verglich Query-Benchmarks über Postgres 16, 17 und 18 hinweg, um diese Fortschritte hervorzuheben.

Nelson Calero (Pythian) teilte einen „praktischen Leitfaden“ für die Migration von über 100 PostgreSQL-Datenbanken (von Gigabytes bis zu Multi-Terabytes) in die Cloud. Sein Team migrierte Hunderte von lokalen VM-Datenbanken zu Google Cloud SQL. Er erörterte Planung, Minimierung von Ausfallzeiten, Instanzdimensionierung, Tools und Post-Migrations-Tuning. Insbesondere wies er auf Herausforderungen wie die Handhabung von Upgrades älterer Versionen, Vererbungsschemata, PostGIS-Daten und Änderungen an Dienstkonten hin. Caleros Ratschläge umfassten die Auswahl der richtigen Cloud-Instanztypen, die Optimierung von Massendatenladungen und die Validierung der Performance nach der Migration.

Jan Wieremjewicz (Percona) berichtete über die Implementierung von Transparent Data Encryption (TDE) für Postgres über die pg_tde-Erweiterung. Er führte das Publikum durch die gesamte Reise – von der ersten Idee über Patch-Vorschläge bis hin zu Community-Feedback und Design-Kompromissen. Er erklärte, warum bestehende PostgreSQL-Hooks nicht ausreichten, welche Schwierigkeiten auftraten und wie Kundenfeedback das endgültige Design prägte. Dieser Vortrag diente als „Tagebuch“ darüber, was es braucht, um eine zentrale Verschlüsselungsfunktion durch den PostgreSQL-Entwicklungsprozess zu liefern.

Stefan Fercot (Data Egret) demonstrierte, wie Patroni (für Hochverfügbarkeit) zusammen mit pgBackRest (für Backups) verwendet wird. Er führte durch YAML-Konfigurationsbeispiele, die zeigten, wie pgBackRest in einen Patroni-verwalteten Cluster integriert wird. Stefan zeigte, wie Standby-Replikate aus pgBackRest-Backups wiederhergestellt und Point-in-Time Recovery (PITR) unter der Kontrolle von Patroni durchgeführt werden. Der Vortrag hob praktische operative Erkenntnisse hervor: Die Kombination dieser Tools bietet eine automatisierte, wiederholbare Notfallwiederherstellung für Postgres-Cluster.

Donnerstag: Cloud, EXPLAIN und Resilienz

Maximilian Stefanac und Philipp Thun (SAP SE) erklärten, wie SAP PostgreSQL innerhalb von Cloud Foundry (SAPs Open-Source-PaaS) einsetzt. Sie diskutierten Optimierungen und Skalierungsherausforderungen beim Betrieb von Postgres für die SAP Business Technology Platform. Im Laufe der Jahre hat das Cloud Foundry-Team von SAP Postgres auf AWS, Azure, Google Cloud und Alibaba Cloud bereitgestellt. Die Angebote der einzelnen Anbieter unterscheiden sich, daher ist die Vereinheitlichung von Automatisierung und Monitoring über Clouds hinweg eine große Herausforderung. Der Vortrag hob hervor, wie SAP Postgres-Performance-Verbesserungen an die Community zurückgibt und was es braucht, um große, Cloud-neutrale Postgres-Cluster zu betreiben.

In „EXPLAIN: Make It Make Sense“ half Aivars Kalvāns (Ebury) Entwicklern bei der Interpretation von Abfrageplänen. Er betonte, dass man nach der Identifizierung einer langsamen Abfrage verstehen muss, warum der Planer einen bestimmten Plan gewählt hat und ob dieser optimal ist. Aivars führte durch die EXPLAIN-Ausgabe und teilte Faustregeln zum Erkennen von Ineffizienzen – zum Beispiel das Aufspüren fehlender Indizes oder kostspieliger Operatoren. Er illustrierte gängige Abfrage-Anti-Patterns, die er in der Praxis gesehen hat, und zeigte, wie man sie datenbankfreundlicher umschreibt. Die Session gab praktische Tipps zum Dekodieren von EXPLAIN und zum Optimieren von Abfragen.

Chris Ellis (Nexteam) hob integrierte Postgres-Funktionen hervor, die die Anwendungsentwicklung vereinfachen. Anhand realer Anwendungsfälle – wie Ereignisplanung, Aufgabenwarteschlangen, Suche, Geolocation und die Handhabung heterogener Daten – zeigte er, wie Funktionen wie Bereichstypen, Volltextsuche und JSONB die Anwendungskomplexität reduzieren können. Für jeden Anwendungsfall demonstrierte Chris, welche Postgres-Funktion oder welcher Datentyp das Problem lösen könnte. Diese „Tipps & Tricks“-Tour bekräftigte, dass die Nutzung des reichhaltigen Funktionsumfangs von Postgres oft bedeutet, weniger benutzerdefinierten Code zu schreiben.

Andreas Geppert (Zürcher Kantonalbank) beschrieb ein Cross-Cloud-Replikations-Setup für Katastrophenresilienz. Angesichts der Anforderung, dass bei Ausfall eines Cloud-Anbieters höchstens 15 Minuten Daten verloren gehen dürfen, konnten sie keine physische Replikation verwenden (da ihre Cloud-Anbieter diese nicht unterstützen). Stattdessen bauten sie eine Multi-Cloud-Lösung unter Verwendung logischer Replikation auf. Der Vortrag behandelte, wie sie logische Replikate auch bei Schemaänderungen aktuell halten (wobei angemerkt wurde, dass die logische Replikation DDL nicht automatisch kopiert). Kurz gesagt, die logische Replikation ermöglichte einen resilienten Betrieb mit niedrigem RPO über Anbieter hinweg, trotz Schema-Evolution.

Derk van Veen (Adyen) beleuchtete die tiefere Logik hinter der Tabellenpartitionierung. Er betonte die Bedeutung, den richtigen Partitionsschlüssel zu finden – die „Leitfigur“ in Ihren Daten – und dann Partitionen über alle verwandten Tabellen hinweg auszurichten. Wenn Partitionen einen gemeinsamen Schlüssel und ausgerichtete Grenzen teilen, ergeben sich mehrere Vorteile: gute Performance, vereinfachte Wartung, integrierte Unterstützung für PII-Compliance, einfache Datenbereinigung und sogar transparentes Data Tiering. Derk warnte, dass schlecht geplante Partitionen die Performance erheblich beeinträchtigen können. In seinem Fall führte der Wechsel zu korrekt ausgerichteten Partitionen (und die Aktivierung von enable_partitionwise_join/_aggregate) zu einer 70-fachen Beschleunigung bei über 100 TB großen Finanztabellen. Alle von ihm vorgestellten Strategien wurden in Adyens mehreren Hundert TB großen Produktionsdatenbank erprobt.

Freitag: Weitere fortgeschrittene Themen

Nicholas Meyer (Academia.edu) stellte Thin Cloning vor, eine Technik, die Entwicklern echte Produktionsdaten-Snapshots zum Debuggen zur Verfügung stellt. Mit Tools wie DBLab Engine oder der Klonfunktion von Amazon Aurora erstellt Thin Cloning kostengünstig beschreibbare Kopien von Live-Daten. Dies ermöglicht es Entwicklern, Produktionsprobleme – einschließlich datenabhängiger Fehler – exakt zu reproduzieren, indem sie diese Klone realer Daten debuggen. Nicholas erklärte, wie Academia.edu Thin Clones verwendet, um subtile Fehler frühzeitig zu erkennen, indem Entwicklungs- und QA-Teams mit nahezu produktionsnahen Daten arbeiten.

Dave Pitts (Adyen) erklärte, warum zukünftige Postgres-Anwendungen sowohl B-Baum- als auch LSM-Baum- (log-strukturierte) Indizes verwenden könnten. Er skizzierte die grundlegenden Unterschiede: B-Bäume eignen sich hervorragend für Punktabfragen und ausgewogene Lese-/Schreibvorgänge, während LSM-Bäume einen hohen Schreibdurchsatz und Bereichs-Scans optimieren. Dave diskutierte „Fallstricke“ beim Wechsel von Workloads zwischen Indextypen. Der Vortrag verdeutlichte, wann welche Struktur vorteilhaft ist, und half Entwicklern und DBAs, den richtigen Index für ihre Workload zu wählen.

Ein von Jimmy Angelakos geleitetes Panel befasste sich mit dem Thema „How to Work with Other Postgres People“. Die Diskussion konzentrierte sich auf psychische Gesundheit, Burnout und Neurodiversität in der PostgreSQL-Community. Die Panelisten hoben hervor, dass ungelöste psychische Gesundheitsprobleme Stress und Fluktuation in Open-Source-Projekten verursachen. Sie teilten praktische Strategien für eine unterstützendere Kultur: persönliche „README“-Leitfäden zur Erklärung individueller Kommunikationspräferenzen, respektvolle und empathische Kommunikationspraktiken sowie konkrete Techniken zur Konfliktlösung. Ziel war es, die Postgres-Community einladender und resilienter zu gestalten, indem unterschiedliche Bedürfnisse verstanden und Mitwirkende effektiv unterstützt werden.

Lukas Fittl (pganalyze) präsentierte neue Tools zur Verfolgung von Änderungen an Abfrageplänen über die Zeit. Er zeigte, wie stabile Plan-IDs (analog zu Query-IDs) zugewiesen werden können, damit DBAs überwachen können, welche Abfragen welche Planformen verwenden. Lukas stellte die neue pg_stat_plans-Erweiterung (die die Funktionen von Postgres 18 nutzt) zur ressourcenschonenden Erfassung von Planstatistiken vor. Er erklärte, wie diese Erweiterung funktioniert und verglich sie mit älteren Tools (dem ursprünglichen pg_stat_plans, pg_store_plans usw.) und Cloud-Anbieter-Implementierungen. Dies erleichtert das Erkennen, wenn sich der Ausführungsplan einer Abfrage in der Produktion ändert, und unterstützt die Performance-Fehlerbehebung.

Ahsan Hadi (pgEdge) beschrieb pgEdge Enterprise PostgreSQL, eine zu 100 % Open-Source-verteilte Postgres-Plattform. pgEdge Enterprise Postgres bietet integrierte Hochverfügbarkeit (unter Verwendung von Patroni und Read Replicas) und die Möglichkeit, über globale Regionen hinweg zu skalieren. Ausgehend von einem Single-Node-Postgres können Benutzer zu einem Multi-Region-Cluster mit geo-verteilten Replikaten für extreme Verfügbarkeit und geringe Latenz wachsen. Ahsan demonstrierte, wie pgEdge für Organisationen konzipiert ist, die von einzelnen Instanzen auf große verteilte Bereitstellungen skalieren müssen, alles unter der Standard-Postgres-Lizenz.

Fazit

Die PGConf.EU 2025 war eine ausgezeichnete Veranstaltung zum Wissensaustausch und zum Lernen von der globalen PostgreSQL-Community. Ich war stolz, credativ zu vertreten und als Freiwilliger zu helfen, und ich bin dankbar für die vielen gewonnenen Erkenntnisse. Die oben genannten Sessions stellen nur eine Auswahl der reichhaltigen Inhalte dar, die auf der Konferenz behandelt wurden. Insgesamt machen die starke Community und die schnelle Innovation von PostgreSQL diese Konferenzen weiterhin sehr wertvoll. Ich freue mich darauf, das Gelernte in meiner Arbeit anzuwenden und zukünftige PGConf.EU-Veranstaltungen zu besuchen.