Die deutsche PostgreSQL-Konferenz (PGConf.DE) fand in diesem Jahr bereits zum zehnten Mal statt. Die Jubiläumsausgabe wurde am 21. und 22. April 2026 im Haus der Technik in Essen ausgerichtet. Mit über 308 Registrierungen war dies eine der größeren Veranstaltung dieser Reihe und unterstreicht die kontinuierlich wachsende Entwicklung der PostgreSQL-Community im deutschsprachigen Raum. Die Konferenz bringt jährlich Entwickler, Administrator und Entscheidungsträger zusammen und dient als zentrale Plattform für fachlichen Austausch, Networking und aktuelle Einblicke in die Weiterentwicklung von PostgreSQL. (mehr …)

Irgendwo zwischen „eigentlich müsste ich mich mal um die Datenbankmigrationen kümmern“ und „keine Zeit, kein Plan, wo anfangen“ – kennen Sie das? Dann haben wir genau das Richtige für Sie.

Nach dem Erfolg unseres ersten Business-Frühstücks rund um Proxmox laden wir Sie zur nächsten Runde ein. Diesmal dreht sich alles um PostgreSQL – von der live vorgeführten Migration bis zu den Basics, die jeder DBA (und jeder, der unfreiwillig zum DBA geworden ist) kennen sollte.

Damit möglichst viele dabei sein können, bieten wir das Frühstück gleich dreimal an – selbe Themen, selber Ort, unterschiedliche Speaker:

Kommen Sie an dem Termin, der bei Ihnen in den Kalender passt. Ganz ohne Vertriebsdruck, ganz ohne Folien-Overkill.

Was Sie erwartet

09:30 Uhr | Ankommen & Koffein-Check Erstmal durchatmen, Kaffee holen, Leute kennenlernen.
10:00 Uhr | Demo 1: credativ-pg-migrator – Live Migration, kein Zauberwerk Datenbankmigrationen klingen nach schlafloser Nacht und Schweißausbrüchen? Wir zeigen Ihnen live, wie das auch entspannt geht – mit unserem eigenen Open-Source-Tool credativ-pg-migrator. 15 Minuten, echter Betrieb, keine Magie.
10:20 Uhr | Demo 2: CNPG & Postgres – DBA Essentials CloudNativePG ist das Thema, wenn Postgres in den Kubernetes-Betrieb soll. Wir zeigen, was Sie wissen müssen – verständlich auch für alle, die sich bisher um Datenbanken eher herumgedrückt haben.
10:40 – 12:00 Uhr | Offene Runde & Diskussion Fragen, Fachsimpeln, Mettbrötchen. Der Rest des Vormittags gehört Ihnen.

Das Buffet: Bewährt und rheinisch

Frisch gebrühter Kaffee & Kaltgetränke
Eine Auswahl frischer Brötchen
Das Highlight: Echter „Rheinischer Kaviar“ – sprich: Mettbrötchen mit Zwiebeln. Für alle, die kein Fleisch mögen: vegetarische Alternativen sind selbstverständlich dabei.

Alle Eckdaten auf einen Blick

🕤 Wann: 09:30 – 12:00 Uhr (Ihr Wunschtermin: 25.08., 03.09. oder 09.09.)
📍 Wo: credativ GmbH, Hennes-Weisweiler-Allee 23, 41179 Mönchengladbach
👥 Für wen: IT-Entscheider, neugierige Einsteiger, unfreiwillige DBAs – alle willkommen.

Anmeldung & Details

Damit die Mett-Logistik stimmt, melden Sie sich bitte über unsere Event-Seite an – und wählen Sie dabei direkt Ihren Wunschtermin:

👉 Hier anmelden:

Wir freuen uns auf einen lockeren Vormittag mit echten Gesprächen – und echtem Mett.

Symbolbild für einen Frühstückstisch in einem Konferenzraum, mit AI generiert.

CERN PGDay 2026 fand am Freitag, dem 6. Februar 2026, auf dem CERN-Campus in Genf, Schweiz, statt. Es war der zweite jährliche PostgreSQL Day am CERN, gemeinsam organisiert vom CERN und der Swiss PostgreSQL Users Group. Die Konferenz bot ein Single-Track-Programm mit sieben Sessions (alle auf Englisch), gefolgt von einem Social Event vor Ort zum weiteren Networking in der inspirierenden Umgebung des CERN. Mit rund 100 Teilnehmenden ist dies bereits ein sehr großes PostgreSQL-Event für die Schweiz. Was dieses Event jedoch absolut besonders machte, war sein Veranstaltungsort. Eine Datenbankkonferenz am CERN – einem der führenden Wissenschaftslabore der Welt – auszurichten, bot für alle ein einzigartiges Erlebnis.

(mehr …)

Mönchengladbach (DE) / Naarden (NL) — 4. Februar 2026

Splendid Data und die credativ GmbH geben eine strategische Partnerschaft zur Beschleunigung der Oracle-to-PostgreSQL-Migration für Unternehmen bekannt.

Splendid Data und die credativ GmbH gaben heute eine strategische Partnerschaft bekannt, um Unternehmen bei der Modernisierung komplexer Oracle-Datenbankumgebungen zu unterstützen, indem sie auf vorhersehbare, skalierbare und zukunftssichere Weise zu nativem PostgreSQL migrieren.

Die Partnerschaft begegnet der wachsenden Nachfrage von Unternehmen, die eskalierenden Datenbanklizenzkosten zu senken, die Autonomie zurückzugewinnen, die digitale Souveränität zu gewährleisten und Datenplattformen für KI-gestützte Anwendungsfälle vorzubereiten. PostgreSQL wird aufgrund seiner offenen Architektur, seines starken Ökosystems und seiner Eignung für moderne, datenintensive Workloads zunehmend als strategische Datenbankgrundlage ausgewählt.

Splendid Data steuert seine Cortex-Automatisierungsplattform bei, die für die Industrialisierung von Oracle-to-PostgreSQL-Migrationen in großem Maßstab entwickelt wurde und das Risiko über komplexe Datenbankbestände hinweg reduziert. credativ ergänzt dies durch fundiertes PostgreSQL-Know-how, die Bereitstellung von Plattformen auf Enterprise-Niveau und einen 24×7-Betriebssupport für unternehmenskritische Umgebungen. Gemeinsam stimmen sich die Partner auch auf PostgresPURE ab, einer produktionsreifen, reinen Open-Source-PostgreSQL-Plattform ohne proprietäre Erweiterungen oder Vendor Lock-in.

„Unternehmen treffen langfristige Entscheidungen in Bezug auf Lizenzrisiken, Autonomie und KI-Bereitschaft“, sagte Michel Schöpgens, CEO von Splendid Data. „Diese Partnerschaft kombiniert Migrationsautomatisierung mit vertrauenswürdigem PostgreSQL-Betrieb.“

David Brauner, Geschäftsführer bei credativ, fügte hinzu: „Gemeinsam ermöglichen wir es Kunden, schneller zu modernisieren und gleichzeitig Kontrolle, Transparenz und betriebliche Zuverlässigkeit zu erhalten.“

Der anfängliche geografische Fokus der Partnerschaft liegt auf Deutschland, wo credativ über einen starken Kundenstamm verfügt. Das Modell ist darauf ausgelegt, im Laufe der Zeit auf internationale Unternehmenskunden skaliert zu werden. Zu den gemeinsamen Aktivitäten gehören koordinierte Go-to-Market-Bemühungen, die Befähigung der credativ-Teams auf Cortex und die Durchführung erster Pilotprojekte mit gemeinsamen Kunden.

Beide Unternehmen betrachten die Partnerschaft als langfristige Zusammenarbeit, die darauf abzielt, einen neuen Standard für die groß angelegte Open-Source-Datenbankmodernisierung in Europa zu setzen.

Über credativ

Die credativ GmbH ist ein unabhängiges Beratungs- und Dienstleistungsunternehmen mit Fokus auf Open-Source-Software. Nach der Ausgliederung aus NetApp im Frühjahr 2025 kombiniert credativ jahrzehntelange Community-Expertise mit professionellen Enterprise-Standards, um IT-Infrastrukturen sicher, souverän und zukunftssicher zu machen, ohne die Verbindung zu ihrer rund 25-jährigen Geschichte der Arbeit in und mit der Open-Source-Community zu verlieren.

Über Splendid Data

Splendid Data ist ein PostgreSQL-Spezialist, der sich auf groß angelegte Oracle-to-PostgreSQL-Migrationen für Unternehmen mit komplexen Datenbankbeständen konzentriert. Seine Cortex-Plattform ermöglicht automatisierte, wiederholbare Migrationen, während PostgresPURE eine produktionsreife Open-Source-PostgreSQL-Plattform ohne Vendor Lock-in bietet.

Kontakt credativ:

Peter Dreuw, Head of Sales & Marketing (peter.dreuw@credativ.de)

Kontakt Splendid Data:

Michel Schöpgens, CEO (michel.schopgens@splendiddata.com)

PostgreSQL-Datenbanken richtig zu sichern, erfordert einen mehrschichtigen Ansatz mit robusten Authentifizierungsverfahren, regelmäßigen Backups und kontinuierlicher Überwachung. Effektive Sicherheit kombiniert Verschlüsselung auf Transport- und Speicherebene mit strengen Zugriffskontrollen und proaktivem Monitoring. Diese umfassende Anleitung beantwortet die wichtigsten Fragen zur PostgreSQL-Sicherheit für Unternehmen.

Was sind die größten Sicherheitsrisiken für PostgreSQL-Datenbanken?

Die größten Sicherheitsrisiken für PostgreSQL-Datenbanken umfassen schwache Authentifizierung, unverschlüsselte Datenübertragung, mangelhaft konfigurierte Zugriffsrechte und fehlende Sicherheitsupdates. Zusätzlich stellen SQL-Injection-Angriffe, ungesicherte Netzwerkverbindungen und unzureichende Überwachung ernsthafte Bedrohungen dar.

Unzureichende Authentifizierung entsteht häufig durch schwache Passwort-Richtlinien oder die Verwendung von Standard-Anmeldedaten. Viele Installationen verwenden noch immer einfache Passwörter oder lassen Benutzerkonten ohne angemessene Berechtigung zu. Dies öffnet Angreifern direkten Zugang zu sensiblen Unternehmensdaten. PostgreSQL 18 bietet heute schon moderne und sichere Möglichkeiten zur Benutzerauthentifizierung mit OAuth2.

Fehlende Verschlüsselung bei der Datenübertragung ermöglicht es Angreifern, die Kommunikation zwischen Anwendungen und der Datenbank abzufangen, denn ohne SSL/TLS-Verschlüsselung werden Anmeldedaten und Geschäftsdaten im Klartext übertragen. Unverschlüsselte Datenübertragung ist heute auch in-house in den allermeisten Szenarien ein klares No-Go. Wenn man in einer Cloud-Umgebung im weitesten Sinne arbeitet, also auch bei Nutzung von Hosting- oder Service-Providern, ist eine starke Verschlüsselung der Transportschicht ein absolutes Must-Have. Gleichzeitig gefährden unverschlüsselte Datenspeicher die Sicherheit bei physischem Zugriff auf Server.

Fehlende oder falsche Anpassungen der pg_hba.conf-Datei führen zu ungewollten oder weitreichenderen Zugriffen als vorgesehen. Hierbei geht es weniger um die Berechtigungen auf die Daten innerhalb der Datenbank, sondern um die Möglichkeit sich überhaupt mit der Datenbank verbinden zu können. Zusätzlich sind oft auch die Berechtigungen auf die eigentlichen Daten innerhalb der Datenbank, teils aus Bequemlichkeit oder Historie, breiter Konfiguriert als es nötig wäre. Diese potentiellen Probleme verstärken sich zusätzlich durch veraltete PostgreSQL-Versionen ohne aktuelle Sicherheitspatches.

Wie richtet man sichere Authentifizierung und Zugriffskontrolle ein?

Ein oft anzutreffendes Pattern in Anwendungen ist auch heute immer noch leider der Fakt, dass die Software nur einen generischen Datenbank-User nutzt, der oft mehr Rechte in der Datenbank bekommt als er eigentlich benötigt. Gerade bei vorinstallierten Systemen wird dieser mit öffentlich bekannten Standard-Passwörtern konfiguriert. Das hat mit Sicherheit leider nichts zu tun.
Anmerkung: In der Praxis wird der Datenbankuser gerne so universell eingerichtet, um nicht in Limitierungen von Verbindungen zu laufen und/oder von Connection-Pooling und ähnlichen Techniken zu profitieren.

Grundsätzlich sollten die Berechtigungen (Autorisierung) so wenig wie möglich in der Anwendung abgehandelt werden, sondern durch die Datenbank. Die Applikation kann sich damit viel Code ersparen und nur auf einen verweigerten Zugriff reagieren. Das Gegenteil ist heute "üblich", was effektiven Schutz der Daten aushebelt

Sichere PostgreSQL-Authentifizierung basiert auf starken Passwort-Richtlinien, rollenbasierten Zugriffskontrollen und dem Prinzip der minimalen Berechtigung. Konfigurieren Sie die pg_hba.conf-Datei restriktiv und implementieren Sie mehrstufige Authentifizierung für administrative Zugriffe. Jeder Benutzer sollte nur die minimal notwendigen Rechte erhalten.

Beginnen Sie mit der Erstellung spezifischer Datenbankrollen für verschiedene Anwendungsbereiche. Verwenden Sie CREATE ROLE-Befehle, um funktionsspezifische Rollen zu definieren. Beispielsweise benötigen Reporting-Anwendungen nur Lesezugriff, während Backup-Prozesse spezielle Systemrechte erfordern. Vermeiden Sie die Verwendung des Superuser-Kontos für Routineoperationen.

Die pg_hba.conf-Datei steuert Client-Authentifizierung und Verbindungsmethoden. Konfigurieren Sie diese Datei so, dass sie nur spezifische IP-Adressen und Subnetze zulässt. Verwenden Sie scram-sha-256 anstelle von md5 und verbieten Sie trust für Produktionsumgebungen. Beschränken Sie lokale Verbindungen auf notwendige Systembenutzer.

Implementieren Sie starke Passwort-Richtlinien mit Extensions wie passwordcheck zur Durchsetzung komplexer Passwörter. Regelmäßige Prüfung und die Deaktivierung ungenutzter Rollen erhöhen die Sicherheit zusätzlich.

Passwort-Rotationen dagegen helfen bei Passwörtern, die ein Mensch eingeben muss, erwiesenermaßen nicht. Hier hat sich das BSI und auch das NIST in den aktuellen Richtlinien gegen eine regelmäßige Rotation ausgesprochen. Hier wird klar empfohlen, auf andere Systeme wie Passkeys über OAuth2, Zwei-Faktor-Authentifizierung oder kryptographisch sichere Passwörter und Passphrases zu setzen.

Für automatisch generierte, kurzlebige Zugänge um zum Beispiel Automatisierungen anzubinden besteht auch die Möglichkeit temporäre Nutzer mit dazugehörigen Passwörtern via Hashicorp Vault und der "PostgreSQL database secrets engine" anzulegen. Hierbei sind die Berechtigungen und die Verfügbarkeit der Accounts im Vault definiert und werden nur bei Bedarf angelegt sowie automatisch auch wieder entfernt. Diese Technik ist besonders im Umfeld von Kubernetes oft zu sehen. Hierzu berät Sie unser Cloud-Infra-Team gerne.

Welche Backup-Strategien garantieren vollständige Datenwiederherstellung?

Vollständige PostgreSQL-Datenwiederherstellung erfordert mindestens logische, im Optimalfall jedoch physische Backups mit kontinuierlicher Archivierung der Write-Ahead-Logs (WAL). Implementieren Sie automatisierte tägliche Vollsicherungen, ergänzt durch kontinuierliche WAL-Archivierung für Point-in-Time-Recovery. Testen Sie Wiederherstellungsverfahren regelmäßig in isolierten Umgebungen.

Grundsätzlich gilt bei der Backup von PostgreSQL Datenbanken wie immer die 3-2-1-Regel. Das bedeutet, dass Sie 3 Kopien auf 2 unterschiedlichen Medien und davon 1 Offsite-Sicherung erzeugen. Dabei ist es ein fataler Fehler, wenn Backup und Datenbank auf dem selben Medium liegen. So etwas wäre ein Fest für einen Angriff mit Ransomware. Grundsätzlich sollten Backup-Medien entweder nicht dauerhaft im Netz verfügbar sein oder es sollten sog. "immutable" Backupmedien eingesetzt werden, also Speichermedien, die nur einmal beschreibbar sind. Dabei muss man nicht zwangsläufig an optische Speicher denken, auch organisatorische Locks wie ein S3 Object Lock ist durchaus eine Lösung. Hier gibt es gute Ansätze zur Lösung durch Open-Source-Software, aber auch Hersteller hochwertiger Storage-Lösungen wie NetApp haben entsprechende Angebote.

Auch sollten Backups nicht ohne Einbindung in das Monitoring erfolgen. Es sollte mindestens überwacht werden dass die Backups wie konfiguriert durchgeführt werden können. Aber auch ein Backup, das "erfolgreich" durchläuft, aber hinterher nur 0 - weniger 100 Bytes beinhaltet, ist wertlos. Regelmäßige Restore-Tests bestätigen diesen Zustand dann in Stichproben.

Backup-Methoden

Logische Backups mit pg_dump eignen sich hervorragend für einfache Datensicherung und -wiederherstellung sowie plattformübergreifende Kompatibilität. Diese Methode erstellt SQL-Befehle zur Rekonstruktion von Datenbankstrukturen und -inhalten. Für große Datenbanken bietet pg_dump parallele Verarbeitung durch den Parameter --jobs, wodurch sich Backup-Zeiten, abhängig von der Struktur der Datenbank, erheblich reduzieren können. Auch ist es damit einfach möglich eine komplette Instanz, einzelne Datenbanken, nur Schemadaten oder nur Inhalte zu sichern. Allerdings gilt auch: Der Restore erfolgt über das Ausführen der einzelnen SQL-Kommandos. Was, wieder je nach Aufbau und Größe der Datenbank, sehr viel Zeit in Anspruch nehmen kann.

Physische Backups durch pg_basebackup kopieren die gesamte Datenbank-Clusterstruktur auf Dateisystemebene. Diese Methode ermöglicht schnellere Wiederherstellung großer Datenbanken und unterstützt kontinuierliche Archivierung. Allerdings gibt es hier keine Möglichkeit zur Selektierung welche Daten gesichert werden sollen. Es ist immer die gesamte Instanz inkl. auch Indexdaten und anderen Binärdaten im Datenverzeichnis enthalten.
Kombinieren Sie Base-Backups mit WAL-Archivierung für die Option von Point-in-Time-Recovery welches sekundengenaue Restores ermöglicht. Die Base-Backups können auch mit Checksummen die Integrität der gesicherten Daten prüfen. Dies funktioniert jedoch nur, wenn auch die jeweilige Instanz entsprechend initialisiert wurde.

Kontinuierliche Archivierung der WAL-Dateien gewährleistet minimalen Datenverlust bei Systemausfällen. Konfigurieren Sie archive_mode und archive_command in der postgresql.conf für automatische WAL-Übertragung an sichere Speicherorte. Überwachen Sie Archivierungsprozesse kontinuierlich und implementieren Sie Alarme bei Fehlern oder Verzögerungen. Sollten Sie in der Dokumentation Ihrer Umgebung noch eine recovery.conf Datei beschrieben haben, lohnt es sich ggf. die Installation und Dokumentation von Experten prüfen zu lassen. Diese Datei war bis einschließlich PostgreSQL 11 Teil von PostgreSQL und wurde mit PostgreSQL 12 in die postgresql.conf verschmolzen.

Eine weitere Methode wäre der Einsatz von pgBackRest. Hierbei handelt es sich um ein ausgereiftes Backup- und Restore-Framework für PostgreSQL, das gegenüber Bordmitteln vor allem auch bei großen Clustern punktet. Dieses System kann auch die Einhaltung von RPO/RTO-Vorgaben umsetzen. Es unterstützt vollständige, differentielle und inkrementelle Backups, Parallelisierung, Block‑Delta, WAL-Archivierung, Verschlüsselung, Kompression (zstd/lz4), Integritätsprüfungen und Remote/Cloud-Repositories (z. B. S3, Azure Blob, GCS).

In Kubernetes-Umgebungen setzt man heute oft auf Operatoren wie CloudNativePG oder den Zalando Postgres Operator. Diese nutzen ebenfalls Tools wie Wal-E oder Barman Cloud für Backup und Recovery und bringen bereits hohe Integration als auch Monitoring mit.

Wie verschlüsselt man PostgreSQL-Daten richtig?

PostgreSQL-Datenverschlüsselung erfolgt auf drei Ebenen: Transportverschlüsselung mit SSL/TLS für Netzwerkverbindungen, Verschlüsselung ruhender Daten auf Speicherebene und feldbasierte Verschlüsselung für besonders sensitive Informationen. Konfigurieren Sie SSL-Zertifikate für sichere Client-Server-Kommunikation und nutzen Sie Dateisystem- bzw. Partitionsverschlüsselung, etwa LUKS, für Datenbankdateien.

SSL/TLS-Transportverschlüsselung schützt Daten während der Übertragung zwischen Clients und Server. Aktivieren Sie SSL durch Setzen von ssl = on in der postgresql.conf und konfigurieren Sie entsprechende Zertifikatsdateien. Verwenden Sie selbstsignierte Zertifikate für Entwicklungsumgebungen und CA-signierte Zertifikate für Produktionssysteme. Die pg_hba.conf sollte hostssl-Verbindungen für kritische Anwendungen vorschreiben.

Verschlüsselung ruhender Daten erfolgt typischerweise auf Dateisystem- oder Speicherebene durch Tools wie LUKS unter Linux, BitLocker unter Windows oder Cloud-Provider-Verschlüsselung. PostgreSQL selbst ohne Zusätze bietet keine integrierte Verschlüsselung für Datenbankdateien, daher implementieren Sie Verschlüsselung unterhalb der Datenbankschicht. Dies schützt vor physischem Zugriff auf Speichermedien und Datendiebstahl bei Serverkompromittierung.

Feldbasierte Verschlüsselung für hochsensible Daten bietet z.B. die PostgreSQL-Erweiterungen pgcrypto. Diese Extension bietet Funktionen für symmetrische und asymmetrische Verschlüsselung einzelner Datenbankfelder. Nutzen Sie diese für Zahlungsdaten, persönliche Identifikatoren oder Geschäftsgeheimnisse, wobei Sie Leistungsauswirkungen bei Such- und Sortieroperationen berücksichtigen müssen. pgcrypto bietet aber auch Unterstützung für allerlei andere kryptographische Operationen wie z.B. Hashing oder Salting.

Welche Monitoring-Tools erkennen Sicherheitsvorfälle frühzeitig?

Effektive PostgreSQL-Sicherheitsüberwachung kombiniert integrierte Logging-Funktionen mit spezialisierten Monitoring-Tools für Anomalieerkennung. Aktivieren Sie detaillierte Protokollierung in der postgresql.conf und nutzen Sie Tools wie pgAudit für umfassendes Audit-Logging. Implementieren Sie automatisierte Alerting-Systeme für verdächtige Aktivitäten und Performance-Anomalien.

Die integrierten Logging-Funktionen von PostgreSQL bieten umfassende Überwachungsmöglichkeiten durch Konfiguration der log_*-Parameter. Aktivieren Sie log_connections, log_disconnections und log_statement für detaillierte Verbindungs- und Abfrageprotokollierung. Die Konfiguration von log_line_prefix sollte Zeitstempel, Benutzer, Datenbank und Prozess-IDs enthalten, um effektive Forensik-Analysen zu ermöglichen.

Spezialisierte Tools wie pgAudit erweitern die Standard-Logging-Funktionen um granulare Audit-Trails für Compliance-Anforderungen. Diese Extension protokolliert Datenbankzugriffe auf Objekt- und Rollenebene und ermöglicht die Verfolgung von Datenmodifikationen. Kombinieren Sie pgAudit mit log_statement_stats für Performance-Monitoring und die Erkennung ressourcenintensiver Angriffe.

Automatisierte Monitoring-Systeme wie Prometheus mit PostgreSQL-Exporter oder spezialisierte Datenbank-Monitoring-Tools erkennen Anomalien in Echtzeit. Überwachen Sie Metriken wie Verbindungsanzahl, Abfrageperformance, Speicherverbrauch und ungewöhnliche Zugriffsmuster. Implementieren Sie schwellenwertbasierte Alarme für kritische Ereignisse wie fehlgeschlagene Authentifizierungsversuche oder unerwartete Datenbankzugriffe außerhalb der Geschäftszeiten.

Bitte beachten Sie aber auch, das mit jeder Erweiterung des Loggings auch die Anforderungen an den Storage in Bezug auf Performance und besonder Platzbedarf steigen. Prüfen Sie daher sehr genau welche Konfiguration in der Produktion für Sie essentiell sind und welche nur z.B. in der Entwicklungsumgebung einen Mehrwert bieten. Hier unterstützen und beraten wir Sie gerne.

Wie führt man regelmäßige Sicherheitsupdates und Wartung durch?

Regelmäßige PostgreSQL-Sicherheitswartung umfasst systematische Update-Zyklen, kontinuierliche Vulnerability-Assessments und proaktive Konfigurationsüberprüfungen. Etablieren Sie monatliche Minor-Updates für Patches und planen Sie Major-Updates jährlich nach gründlichen Tests. Auch hat PostgreSQL einen vergleichsweise stabilen und gut dokumentierten Release-Zyklus welche die Arbeiten auch über Monate im Voraus gut planbar machen.

Sicherheitspatches für PostgreSQL erscheinen regelmäßig und adressieren kritische Schwachstellen. Abonnieren Sie die PostgreSQL-Accounce-Mailingliste für zeitnahe Benachrichtigungen über verfügbare Minor-Updates und prüfen Sie die Updates der von Ihnen verwendeten Repositories für die dazu passenden Pakete. Testen Sie Patches zunächst in Entwicklungs- und Staging-Umgebungen, bevor Sie diese in Produktionssystemen implementieren. Nutzen Sie Wartungsfenster für planbare Updates und halten Sie Rollback-Strategien bereit.

Kontinuierliche Konfigurationsüberprüfungen identifizieren Sicherheitslücken durch veränderte Anforderungen oder Konfigurationsdrift. Verwenden Sie wenn möglich Automatisierungen wie z.B. Ansible oder ähnliche Systeme zur Sicherstellung des gewünschten Status und zur Erkennung von lokalen Abweichungen. Alternativ sollten mindestens die Konfigurationsdateien versioniert gepflegt und überwacht werden. Tools zur Optimierung der Konfiguration in Bezug auf Performance und Sicherheit sind verfügbar, sollten aber mit entsprechender Vorsicht eingesetzt werden, da die meisten Systeme individuelle Anforderungen haben.

Umfassende Sicherheitsaudits sollten quartalsweise externe Penetrationstests, Vulnerability-Scans und Compliance-Überprüfungen umfassen. Professioneller PostgreSQL-Support kann dabei helfen, komplexe Sicherheitsanforderungen zu erfüllen und kritische Systeme optimal zu schützen. Führen Sie regelmäßige Disaster-Recovery-Tests durch und aktualisieren Sie Incident-Response-Pläne basierend auf neuen Bedrohungslagen und Geschäftsanforderungen.

Wie credativ bei der PostgreSQL-Sicherheit hilft

credativ bietet umfassende PostgreSQL-Sicherheitslösungen, die alle kritischen Aspekte der Datenbankabsicherung abdecken. Unsere Experten unterstützen Sie bei der Implementierung robuster Sicherheitsstrategien und gewährleisten den optimalen Schutz Ihrer Unternehmensdaten:

• Sicherheitsaudits und Penetrationstests: Umfassende Analyse Ihrer PostgreSQL-Infrastruktur zur Identifikation von Schwachstellen und Compliance-Lücken
• Backup- und Recovery-Strategien: Entwicklung und Implementierung maßgeschneiderter Backup-Konzepte mit automatisierter Überwachung und regelmäßigen Recovery-Tests
• Verschlüsselungsimplementierung: Konfiguration von SSL/TLS, Dateisystemverschlüsselung und spaltenbasierter Verschlüsselung nach Industriestandards
• Monitoring und Alerting: Einrichtung professioneller Überwachungssysteme mit 24/7-Support für kritische Sicherheitsvorfälle
• Compliance-Unterstützung: Beratung bei der Erfüllung von DSGVO, ISO 27001 und branchenspezifischen Sicherheitsanforderungen

Sichern Sie Ihre PostgreSQL-Datenbanken mit professioneller Expertise ab. Kontaktieren Sie uns für eine kostenlose Erstberatung und erfahren Sie, wie wir Ihre Datenbankinfrastruktur optimal schützen können.

Die Sicherung von PostgreSQL-Datenbanken erfordert einen systematischen Ansatz mit mehreren Schutzebenen. Durch die Implementierung robuster Authentifizierung, umfassender Backup-Strategien und kontinuierlicher Überwachung schaffen Sie eine solide Grundlage für den Schutz Ihrer Unternehmensdaten. Regelmäßige Wartung und proaktive Sicherheitsmaßnahmen gewährleisten langfristig sichere und zuverlässige Datenbankoperationen.

PostgreSQL ist ein wichtiger Baustein zur digitalen Souveränität. Aber auch dieser Baustein erfordert ein wenig Mühe und Aufmerksamkeit, um ihn sinnvoll einzusetzen. Hier unterstützen wir Sie gerne bei der Umsetzung ebenso wie beim Training Ihres IT-Teams.

Gerne Beraten wir sie auch zu anderen Themen rund um Linux-Hardening, etwa mittels AppArmor.

Was sind PostgreSQL-Datentypen und warum sind sie wichtig?

PostgreSQL-Datentypen definieren, welche Art von Daten in einer Spalte gespeichert werden kann und wie diese Daten interpretiert werden. Sie bestimmen den Speicherbedarf, die Validierungsregeln und die verfügbaren Operationen für jeden Datenwert. Die korrekte Auswahl der Datentypen ist entscheidend für Datenbankperformance und Datenintegrität.

Datentypen optimieren den Speicherplatz durch die präzise Definition des benötigten Speicherbedarfs. Ein INTEGER benötigt beispielsweise 4 Bytes, während ein BIGINT 8 Bytes verwendet. Bei Millionen von Datensätzen hat dieser Unterschied erhebliche Auswirkungen auf die Speichernutzung und Abfragegeschwindigkeit.

PostgreSQL organisiert Datentypen in verschiedene Kategorien: numerische Typen für Zahlen, Zeichenketten-Typen für Text, Datums- und Zeit-Typen für temporale Daten sowie erweiterte Typen wie JSON, Arrays und geometrische Datenstrukturen. Jede Kategorie bietet spezifische Funktionen und Optimierungen für unterschiedliche Anwendungsfälle.

Welche numerischen Datentypen bietet PostgreSQL?

PostgreSQL stellt mehrere numerische Datentypen zur Verfügung: INTEGER, BIGINT, SMALLINT für Ganzzahlen sowie DECIMAL, NUMERIC, REAL und DOUBLE PRECISION für Fließkommazahlen. Ganzzahl-Datentypen unterscheiden sich durch ihren Wertebereich und Speicherbedarf, während Fließkomma-Typen verschiedene Präzisionsstufen bieten.

SMALLINT verwendet 2 Bytes und speichert Werte von -32.768 bis 32.767. INTEGER benötigt 4 Bytes für Werte zwischen -2.147.483.648 und 2.147.483.647. BIGINT verwendet 8 Bytes und unterstützt extrem große Zahlen bis zu 9.223.372.036.854.775.807.

Für Dezimalzahlen bietet DECIMAL (synonym zu NUMERIC) exakte Präzision ohne Rundungsfehler, ideal für Finanzberechnungen. REAL verwendet 4 Bytes für einfache Fließkomma-Präzision, während DOUBLE PRECISION 8 Bytes für doppelte Präzision verwendet. Bei der PostgreSQL-Entwicklung ist die Wahl zwischen exakter und approximativer Arithmetik entscheidend für die Datenqualität.

Wie funktionieren Text- und Zeichenketten-Datentypen in PostgreSQL?

PostgreSQL bietet vier Haupttypen für Textdaten: CHAR für feste Länge, VARCHAR für variable Länge mit Maximum, TEXT für unbegrenzte Länge und CITEXT für case-insensitive Vergleiche. VARCHAR und TEXT sind die am häufigsten verwendeten Optionen für die meisten Anwendungen.

CHAR(n) reserviert immer n Zeichen Speicherplatz und füllt kürzere Werte mit Leerzeichen auf. VARCHAR(n) speichert nur die tatsächlich verwendeten Zeichen plus ein Byte für die Längeninformation. TEXT hat keine Längenbegrenzung und bietet maximale Flexibilität für große Textmengen.

Performance-Überlegungen zeigen, dass VARCHAR und TEXT praktisch identische Leistung bieten. PostgreSQL optimiert beide Typen gleich effizient. Die Wahl zwischen VARCHAR mit Längenlimit und TEXT ohne Begrenzung hängt von den Validierungsanforderungen ab. PostgreSQL unterstützt vollständig Unicode (UTF-8) und ermöglicht internationale Zeichensätze ohne zusätzliche Konfiguration.

Welche Datums- und Zeit-Datentypen gibt es in PostgreSQL?

PostgreSQL stellt fünf temporale Datentypen bereit: DATE für Kalenderdaten, TIME für Tageszeiten, TIMESTAMP für Datum und Zeit, TIMESTAMPTZ für zeitzonenbewusste Zeitstempel und INTERVAL für Zeitspannen. TIMESTAMPTZ wird für die meisten Anwendungen empfohlen, da es Zeitzonen korrekt verwaltet.

DATE speichert nur Kalenderdaten ohne Zeitinformation (YYYY-MM-DD). TIME erfasst Tageszeiten mit optionaler Mikrosekundengenauigkeit. TIMESTAMP kombiniert beides ohne Zeitzonenbezug, während TIMESTAMPTZ Zeitstempel in UTC speichert und bei Abfragen in die Session-Zeitzone konvertiert.

INTERVAL ermöglicht Berechnungen mit Zeitspannen wie „3 Monate 2 Tage 14 Stunden“. PostgreSQL bietet umfangreiche Funktionen für Datumsarithmetik, Formatierung und Zeitzonenkonvertierung. Best Practices empfehlen die konsistente Verwendung von TIMESTAMPTZ für alle zeitbezogenen Daten in internationalen Anwendungen.

Was sind spezielle PostgreSQL-Datentypen und wann verwendet man sie?

PostgreSQL bietet erweiterte Datentypen für moderne Anwendungsanforderungen: BOOLEAN für Wahrheitswerte, UUID für eindeutige Identifikatoren, JSON/JSONB für strukturierte Dokumente, ARRAY für Listen und geometrische Typen für räumliche Daten. JSONB und ARRAY ermöglichen flexible Datenstrukturen ohne separate Tabellen.

BOOLEAN speichert die Wahrheitswerte true, false oder null effizient. UUID generiert global eindeutige 128-Bit-Identifikatoren, ideal für verteilte Systeme. JSON speichert Dokumente als Text, während JSONB eine binäre, indizierbare Version mit besserer Performance bietet.

ARRAY ermöglicht die Speicherung mehrerer Werte desselben Typs in einer Spalte, beispielsweise INTEGER[] für Zahlenlisten. Geometrische Typen wie POINT, LINE und POLYGON unterstützen räumliche Anwendungen. Diese erweiterten Datentypen integrieren sich nahtlos in moderne Anwendungsarchitekturen und reduzieren die Komplexität von Datenmodellen durch die native Unterstützung komplexer Strukturen.

Wie credativ® bei der optimalen Nutzung von PostgreSQL-Datentypen hilft

credativ® unterstützt Unternehmen bei der strategischen Auswahl und Implementierung der richtigen PostgreSQL-Datentypen für maximale Performance und Datenintegrität. Unsere PostgreSQL-Lösungen analysieren Ihre spezifischen Anforderungen und entwickeln maßgeschneiderte Datenbankstrukturen:

Performance-Analyse: Bewertung bestehender Datenstrukturen und Identifikation von Optimierungspotenzialen
Datenmodellierung: Entwicklung effizienter Schemas mit optimal gewählten Datentypen
Migration und Modernisierung: Sichere Überführung veralteter Datenstrukturen in moderne PostgreSQL-Implementierungen
Schulungen und Beratung: Wissensvermittlung für Ihre Entwicklungsteams zu Best Practices bei Datentypen
24/7 Support: Kontinuierliche Betreuung und Optimierung Ihrer PostgreSQL-Umgebungen

Kontaktieren Sie uns für eine kostenlose Erstberatung und erfahren Sie, wie die richtige Datentyp-Strategie Ihre Datenbankperformance revolutionieren kann.

Was ist die PostgreSQL-Lizenz und warum ist sie so beliebt?

Die PostgreSQL-Lizenz ist eine BSD-ähnliche Open-Source-Lizenz, die maximale Freiheit bei der Nutzung der Datenbank gewährt. Sie wurde speziell entwickelt, um sowohl Entwicklern als auch Unternehmen größtmögliche Flexibilität zu bieten, ohne die rechtlichen Komplexitäten anderer Lizenzmodelle.

Diese Lizenz ist besonders bei Unternehmen beliebt, weil sie keine Copyleft-Bestimmungen enthält. Das bedeutet, Sie können PostgreSQL in proprietäre Software integrieren, ohne den Quellcode Ihrer eigenen Anwendung offenlegen zu müssen. Die Lizenz stammt aus dem Jahr 1996 und hat sich seitdem als stabiles, vertrauenswürdiges Lizenzmodell etabliert.

Die grundlegenden Eigenschaften machen PostgreSQL für kommerzielle Projekte attraktiv: keine Lizenzgebühren, keine Beschränkungen bei der Anzahl der Nutzer oder Installationen und vollständige Kontrolle über Modifikationen. Unternehmen schätzen besonders die Rechtssicherheit und die Möglichkeit, PostgreSQL ohne langfristige Vertragsbindungen zu nutzen.

Welche Rechte und Pflichten haben Unternehmen bei der PostgreSQL-Nutzung?

Die Rechte umfassen konkret: unbegrenzte kommerzielle Nutzung in jedem Geschäftsbereich, Modifikation des Quellcodes nach eigenen Anforderungen, Weitergabe sowohl der ursprünglichen als auch modifizierter Versionen sowie die Einbindung in geschlossene, proprietäre Softwarelösungen ohne Offenlegungspflicht.

Unternehmen erhalten mit PostgreSQL umfassende Nutzungsrechte ohne wesentliche Einschränkungen. Sie dürfen die Datenbank kommerziell nutzen, den Quellcode modifizieren, eigene Versionen erstellen und diese sogar verkaufen. Die Integration in proprietäre Software ist ausdrücklich erlaubt.

Die Pflichten sind minimal und beschränken sich auf wenige Punkte: Der ursprüngliche Urheberrechtshinweis muss in allen Kopien oder wesentlichen Teilen der Software enthalten bleiben. Außerdem müssen Sie den Haftungsausschluss der ursprünglichen Entwickler respektieren. Eine Namensnennung in der Dokumentation oder in About-Dialogen ist nicht zwingend erforderlich, wird aber geschätzt.

Unbegrenzte Nutzung: Kommerziell in jedem Geschäftsbereich.
Modifikation: Quellcode darf beliebig angepasst werden.
Weitergabe: Auch in geschlossenen, proprietären Produkten.

Wie unterscheidet sich PostgreSQL von anderen Datenbank-Lizenzen?

PostgreSQL unterscheidet sich erheblich von anderen Datenbank-Lizenzmodellen durch seine permissive Struktur. Während MySQL® unter der GPL steht, Oracle® proprietäre Lizenzen verwendet und MongoDB® die restriktive SSPL eingeführt hat, bleibt PostgreSQL konsequent offen und unternehmerfreundlich.

Der Vergleich zeigt deutliche Unterschiede: MySQL mit GPL-Lizenz erfordert bei kommerzieller Nutzung in proprietärer Software häufig kostenpflichtige Lizenzen. Oracle Database verlangt grundsätzlich Lizenzgebühren und bietet nur eingeschränkte kostenlose Versionen. MongoDB hat mit der SSPL eine Lizenz eingeführt, die Cloud-Anbieter zur Offenlegung ihrer gesamten Service-Software verpflichtet.

Für Unternehmen bietet PostgreSQL klare Vorteile: keine Lizenzkosten, keine rechtlichen Fallstricke bei der Integration in kommerzielle Produkte und keine Verpflichtung zur Offenlegung eigener Entwicklungen. PostgreSQL-Support ist zudem von verschiedenen Anbietern verfügbar, ohne Vendor-Lock-in-Effekte.

Die PostgreSQL Lizenz ist mit fast allen anderen Open-Source-Lizenzen kompatibel. So kann man beispielsweise PostgreSQL-Code problemlos in ein unter GPL stehendes Projekt einbauen.

Gegenüberstellung der GNU General Public License (GPL), der GNU Affero General Public License (AGPL) und der PostgreSQL-Lizenz.

Diese Tabelle verdeutlicht insbesondere die Unterschiede bei der Pflicht zur Quellcode-Offenlegung, was für die kommerzielle Nutzung und proprietäre Softwareentwicklung entscheidend ist:

Merkmal	GPL (v2 / v3)	AGPL (v3)	PostgreSQL-Lizenz
Lizenztyp	Strenges Copyleft („viraler Effekt“)	Strenges Copyleft („viraler Effekt“)	Permissiv (freizügig)
Quellcode-Offenlegung bei Vertrieb/Weitergabe	Ja. Werden abgeleitete Werke (oder Kombinationen) vertrieben, muss der gesamte Quellcode unter der GPL offengelegt werden	Ja. Wie bei der GPL muss der Quellcode bei Weitergabe offengelegt werden	Nein. Es gibt keine Pflicht zur Offenlegung des eigenen Quellcodes
Quellcode-Offenlegung bei Netzwerk- / SaaS-Nutzung (ASP)	Nein. Solange die Software nur über ein Netzwerk bereitgestellt wird (ohne Kopien an den Client zu senden), muss der Quellcode nicht offengelegt werden	Ja. Die AGPL schließt das sogenannte „ASP-Schlupfloch“. Nutzer, die über ein Netzwerk mit der Software interagieren, müssen Zugang zum Quellcode erhalten	Nein. Weder bei Weitergabe noch bei Netzwerknutzung muss Quellcode offengelegt werden
Kombination mit proprietärer Software (Business-Vorteil)	Nicht erlaubt/Risikoreich. Proprietäre Systeme dürfen GPL-Code nicht integrieren, ohne selbst vollständig unter die GPL gestellt zu werden (Offenlegungspflicht)	Nicht erlaubt/Risikoreich. Analog zur GPL, aber mit noch strikteren Auflagen bei reiner Netzwerknutzung	Erlaubt. Die Software darf für jeden Zweck (auch kommerziell) ohne Lizenzgebühren und ohne schriftlichen Vertrag genutzt, kopiert, modifiziert und vertrieben werden

Der entscheidende Business-Vorteil der PostgreSQL-Lizenz

Wie die Tabelle zeigt, liegt der größte Unterschied im Umgang mit abgeleiteten Werken und der Integration in proprietäre Software.

Die GPL und AGPL sind starke Copyleft-Lizenzen. Das bedeutet: Wenn Sie Software (wie beispielsweise eine Datenbank unter GPL) in Ihre eigene Software integrieren und diese kombinierte Lösung vertreiben, greift der „virale Effekt“. Ihre eigene Software wird rechtlich als erweitertes Werk der GPL-Software betrachtet und muss zwingend ebenfalls unter der GPL (mitsamt offen gelegtem Quellcode) veröffentlicht werden. Die AGPL geht sogar noch weiter und verlangt die Quellcode-Herausgabe bereits dann, wenn Sie die modifizierte Datenbank lediglich als Service (SaaS/Cloud) über ein Netzwerk anbieten.

Die PostgreSQL-Lizenz hingegen ist eine sehr freizügige Lizenz (ähnlich wie MIT oder BSD). Sie gewährt ausdrücklich die Erlaubnis, die Software und deren Dokumentation für jeden Zweck zu nutzen, zu kopieren, zu modifizieren und zu vertreiben, ohne dass dafür Gebühren anfallen oder ein schriftlicher Vertrag nötig wäre. Die einzige Bedingung ist, dass der Copyright-Vermerk sowie die beiden Absätze zum Haftungsausschluss in allen Kopien enthalten bleiben. Für ein Unternehmen bedeutet dies einen massiven geschäftlichen Vorteil: Sie können eine PostgreSQL-Datenbank problemlos in ein kommerzielles, geschlossenes (proprietäres) Softwareprodukt einbauen und dieses verkaufen, ohne jemals gezwungen zu sein, den Quellcode Ihres eigenen Produkts offenzulegen.

Bitte beachten Sie, dass diese Hinweise nur den Stand unserer Recherchen und keine Rechtsberatung darstellen. Für eine konkrete Einschätzung einer speziellen Anwendung empfehlen wir, individuelle Rechtsberatung für den jeweiligen Fall und mit Bezug zum jeweiligen Rechtsraum zu suchen.

Was müssen Sie bei der kommerziellen PostgreSQL-Nutzung beachten?

Bei der kommerziellen PostgreSQL-Nutzung sollten Sie grundlegende Compliance-Regeln befolgen, um rechtliche Sicherheit zu gewährleisten. Dokumentieren Sie die PostgreSQL-Nutzung in Ihrem Projekt, bewahren Sie Urheberrechtshinweise auf und etablieren Sie interne Richtlinien für den Umgang mit Open-Source-Komponenten.

Praktische Leitlinien für die rechtssichere Nutzung umfassen: Führen Sie eine Software-Inventarliste mit allen verwendeten Open-Source-Komponenten, stellen Sie sicher, dass Entwicklungsteams über Lizenzbestimmungen informiert sind, und bewahren Sie alle relevanten Lizenztexte und Urheberrechtshinweise in einem zentralen Repository auf.

Zur Risikominimierung empfiehlt sich professioneller Support, besonders bei geschäftskritischen Anwendungen. Regelmäßige Updates und Sicherheitspatches sollten eingeplant werden. Professioneller PostgreSQL-Support kann dabei helfen, sowohl technische als auch rechtliche Aspekte optimal zu handhaben und die Vorteile der freien Lizenz voll auszuschöpfen. Für eine rechtliche Bewertung der Lizenzsituation sprechen Sie bitte mit Ihrem Anwalt.

Haftung

Mit der PostgreSQL Lizenz geht auch ein Haftungsausschluss (Warranty Disclaimer) einher. Die Software steht. so wie sie ist („AS IS“) zur Verfügung. Ein Rückgriff im Falle eines Fehlers auf die Autoren oder das Projekt ist damit aus unserer Sicht im Wesentlichen ausgeschlossen. Daher sollte man im geschäftlichen Umfeld immer den PostgreSQL-Betrieb durch einen qualifizierten Dienstleister wie beispielsweise das PostgreSQL Competence Center der credativ GmbH absichern. Je nach Compliance-Anforderungen kann dies sogar zwingend erforderlich sein.

Wie credativ® bei PostgreSQL-Implementierung unterstützt

credativ® bietet als ISO 9001 und ISO 27001 zertifiziertes Dienstleistungsunternehmen umfassende Beratung und Unterstützung bei der optimalen Nutzung von PostgreSQL. Unser Expertenteam hilft Ihnen dabei, die Vorteile der PostgreSQL-Lizenz voll auszuschöpfen und gleichzeitig alle Compliance-Anforderungen zu erfüllen.

Unsere Leistungen umfassen:

Compliance-Beratung: Integration von PostgreSQL in Ihre kommerzielle Software
Technische Implementierung: Professionelle PostgreSQL-Installation und -Konfiguration
24/7-Support: Kontinuierliche Betreuung Ihrer PostgreSQL-Umgebung
Migration und Updates: Sichere Datenübernahme und regelmäßige Aktualisierungen
Schulungen: Weiterbildung Ihrer Teams zu PostgreSQL-Best-Practices

Kontaktieren Sie uns noch heute für eine kostenlose Beratung und erfahren Sie, wie Sie PostgreSQL optimal und sicher in Ihrem Unternehmen einsetzen können.

Transparenzhinweis:

Oracle® und MySQL® sind Marken der Oracle Corp. MongoDB® ist eine Marke der MongoDB Inc. PostgreSQL® ist eine Marke der PostgreSQL Association, Kanada. Die Nennung der Marken dient ausschließlich der sachlichen Beschreibung von Migrationsszenarien und Dienstleistungen der credativ GmbH. Es besteht keine geschäftliche Verbindung zu den genannten Markeninhabern im Bezug auf die genannten Produkte.

Was ist PostgreSQL und warum nutzen es so viele Unternehmen?

Slonik, the PostgreSQL mascot.

PostgreSQL ist ein objektrelationales Datenbankmanagementsystem, das als Open-Source-Software kostenlos verfügbar ist. Die Datenbank entstand aus dem POSTGRES-Projekt der University of California und wird seit 1986 kontinuierlich weiterentwickelt. PostgreSQL unterstützt sowohl relationale als auch nicht relationale Datenstrukturen und gilt als eine der fortschrittlichsten Open-Source-Datenbanken weltweit.

Die wichtigsten Merkmale von PostgreSQL umfassen ACID-Compliance für Transaktionssicherheit, Multi-Version Concurrency Control (MVCC) für gleichzeitige Zugriffe und umfassende SQL-Unterstützung. Die Datenbanksoftware bietet außerdem erweiterte Datentypen wie JSON, XML und Arrays sowie die Möglichkeit, eigene Funktionen und Datentypen zu definieren.

Unternehmen verschiedener Größen setzen auf PostgreSQL, weil es eine stabile und skalierbare Lösung für komplexe Anwendungen bietet. Die aktive Entwicklergemeinschaft sorgt für regelmäßige Updates und Sicherheitspatches. Zusätzlich ermöglicht die freie Lizenz den Einsatz ohne Lizenzkosten, was besonders für wachsende Unternehmen attraktiv ist.

Wie unterscheidet sich PostgreSQL von anderen Datenbanken wie MySQL?

PostgreSQL und MySQL unterscheiden sich in mehreren wichtigen Bereichen, wobei beide ihre spezifischen Stärken haben. PostgreSQL bietet erweiterte Datentypen wie JSON, JSONB, Arrays und geometrische Typen, während MySQL sich auf grundlegende SQL-Datentypen konzentriert. Bei komplexen Abfragen und Joins zeigt PostgreSQL oft eine bessere Performance, MySQL hingegen ist bei einfachen Leseoperationen häufig schneller.

Die Lizenzierung unterscheidet sich ebenfalls: PostgreSQL steht unter der PostgreSQL-Lizenz, die ähnlich der BSD-Lizenz sehr permissiv ist. MySQL verwendet eine duale Lizenzierung mit GPL für Open-Source-Projekte und kommerziellen Lizenzen für proprietäre Software. Dies kann bei der Entscheidung für kommerzielle Anwendungen relevant werden.

PostgreSQL eignet sich besonders für Anwendungen mit komplexen Datenstrukturen, analytischen Workloads und wenn strikte ACID-Compliance erforderlich ist. PostgreSQL unterstützt beispielsweise mit der Erweiterung PostGIS nativ Geo-Daten und Operationen auf geometrischen Strukturen.
MySQL wird oft für Webanwendungen, Content-Management-Systeme und Situationen gewählt, in denen einfache Konfiguration und hohe Leseperformance im Vordergrund stehen.

Beide Datenbanken haben starke Communities und professionellen Support verfügbar.

Welche Vorteile bietet PostgreSQL für Unternehmen?

PostgreSQL bietet Unternehmen erhebliche Kostenvorteile durch die Open-Source-Lizenz, da keine Lizenzgebühren anfallen. Dies ermöglicht es auch kleinen und mittleren Unternehmen, eine professionelle Datenbankinfrastruktur aufzubauen. Die eingesparten Lizenzkosten können in Hardware, Entwicklung oder professionellen Support investiert werden.

Die Sicherheitsstandards von PostgreSQL entsprechen Enterprise-Anforderungen mit Features wie Row-Level-Security, SSL-Verschlüsselung und umfassenden Authentifizierungsmöglichkeiten. Die Datenbank unterstützt verschiedene Compliance-Standards und bietet detaillierte Audit-Funktionen für regulierte Branchen.

PostgreSQL skaliert sowohl vertikal als auch horizontal und wächst mit den Anforderungen Ihres Unternehmens mit. Die Unabhängigkeit von einzelnen Herstellern verhindert Vendor-Lock-in und gibt Ihnen die Flexibilität, Support und Services von verschiedenen Anbietern zu beziehen. Die große Community und das offene Entwicklungsmodell sorgen für kontinuierliche Innovation und langfristige Verfügbarkeit.

Wie installiert und konfiguriert man PostgreSQL richtig? Einfaches Beispiel:

Die PostgreSQL-Installation erfolgt je nach Betriebssystem auf verschiedenen Wegen. Unter Ubuntu/Debian verwenden Sie beispielsweise den Befehl sudo apt-get install postgresql postgresql-contrib. Für Windows laden Sie den offiziellen Installer von postgresql.org herunter. macOS-Nutzer können PostgreSQL über Homebrew mit brew install postgresql installieren.

Nach der Installation müssen Sie den PostgreSQL-Dienst starten und einen Datenbankbenutzer anlegen. Unter Linux erfolgt dies mit sudo systemctl start postgresql und sudo -u postgres createuser --interactive. Die grundlegende Konfiguration erfolgt über die Dateien postgresql.conf für allgemeine Einstellungen und pg_hba.conf für die Authentifizierung.

Damit ist man auf den meisten Linux-Distributionen bereits sofort für einen Test einsatzbereit. Für anspruchsvollere Anwendungen sollte man natürlich weitere Überlegungen treffen, etwa, ob man sich auf die mit der jeweiligen Distribution gelieferten Pakete und Versionen verlassen möchte oder ob man sich auf die Pakete von PostgreSQL.org konzentriert. Auch gehören zu einem performanten Datenbankserver Überlegungen zum darunter liegenden Dateisystem sowie dessen Optimierung.

Für den produktiven Einsatz sollten Sie ferner wichtige Sicherheitseinstellungen vornehmen:

Ändern Sie das Standardpasswort des postgres-Benutzers, falls eines vergeben wurde
Konfigurieren Sie SSL-Verschlüsselung für Netzwerkverbindungen
Beschränken Sie Zugriffe über pg_hba.conf auf notwendige IP-Bereiche
Aktivieren Sie Logging für Audit-Zwecke
Richten Sie regelmäßige Backups ein

Wie credativ® bei PostgreSQL-Projekten unterstützt

credativ® bietet umfassenden PostgreSQL-Support für Unternehmen, die eine professionelle Betreuung ihrer Datenbankinfrastruktur benötigen. Unser Service umfasst 24/7-Support durch erfahrene PostgreSQL-Spezialisten, die bei kritischen Problemen sofort verfügbar sind. Sie erhalten direkten Zugang zu unserem deutschen Support-Team ohne Umwege über internationale Callcenter. Wir sind gerne für Sie da und unterstützen schon bei der Auswahl von Open-Source Tools.

Unsere PostgreSQL-Services im Detail:

Migration von anderen Datenbanksystemen zu PostgreSQL
Installationsberatung und Audit einer bestehenden Installation
Performance-Optimierung und Tuning bestehender Installationen
Hochverfügbarkeits-Setups mit Replikation und Clustering
Backup- und Recovery-Strategien für maximale Datensicherheit
Monitoring und proaktive Wartung Ihrer PostgreSQL-Umgebung
Long Term Support, der Ihnen Zeit gibt, die Upgrades abzuschließen.

Als PostgreSQL-Experten mit über 20 Jahren Erfahrung helfen wir Ihnen dabei, das volle Potenzial Ihrer Datenbank auszuschöpfen. Kontaktieren Sie uns für eine unverbindliche Beratung zu Ihrem PostgreSQL-Projekt und erfahren Sie, wie wir Ihre Datenbankinfrastruktur optimieren können.

KI-generiertes Bild, das eine asynchron laufende Datenbank symbolisiert PostgreSQL 17 führte Streaming-E/A ein – das Gruppieren mehrerer Seitenlesevorgänge in einen einzigen Systemaufruf und die Verwendung intelligenterer posix_fadvise()-Hinweise. Allein das führte in einigen Workloads zu bis zu ~30 % schnelleren sequenziellen Scans, aber es war immer noch strikt synchron: Jeder Backend-Prozess führte einen Lesevorgang aus und wartete dann darauf, dass der Kernel Daten zurückgab, bevor er fortfuhr. Vor PG17 las PostgreSQL typischerweise eine 8-kB-Seite gleichzeitig.

PostgreSQL 18 geht den nächsten logischen Schritt: ein vollständiges asynchrones E/A-Subsystem (AIO), das mehrere Lesevorgänge gleichzeitig ausführen kann, während die Backends weiterhin nützliche Arbeit leisten. Lesevorgänge werden überlappend statt nur serialisiert. Das AIO-Subsystem ist gezielt auf Operationen ausgerichtet, die ihre zukünftigen Blocknummern im Voraus kennen und mehrere Lesevorgänge im Voraus ausführen können:

Sequenzielle Heap-Scans, wie einfache SELECT- und COPY-Operationen, die viele Daten streamen
VACUUM auf großen Tabellen und Indizes
ANALYZE-Stichproben
Bitmap-Heap-Scans

Autovacuum profitiert ebenfalls von dieser Änderung, da seine Worker dieselben VACUUM/ANALYZE-Codepfade verwenden. Andere Operationen bleiben vorerst synchron:

B‑Baum-Indexscans / Index‑Only-Scans
Wiederherstellung & Replikation
Alle Schreiboperationen INSERT, UPDATE, DELETE, WAL-Schreibvorgänge
Kleine OLTP-Lookups, die eine einzelne Heap-Seite berühren

Es wird erwartet, dass zukünftige Arbeiten die Abdeckung erweitern, insbesondere Index‑Only-Scans und einige Optimierungen des Schreibpfads.

Signifikante Verbesserungen für Cloud-Volumes

Community-Benchmarks zeigen, dass PostgreSQL 18 AIO die Kaltcache-Datenlesevorgänge in Cloud-Setups mit netzwerkgebundenem Speicher, bei denen die Latenz hoch ist, deutlich verbessert. Die AWS-Dokumentation besagt, dass die durchschnittliche Latenz von Block Express-Volumes „unter 500 Mikrosekunden für 16 KiB E/A-Größe“ liegt, während die Latenz von General Purpose-Volumes 800 Mikrosekunden überschreiten kann. Einige Artikel legen nahe, dass unter hoher Last jeder physische Block, der von der Festplatte gelesen wird, etwa 1 ms kosten kann, während die Seitenverarbeitung in PostgreSQL viel günstiger ist. Indem wir viele Seiten in einem Lesevorgang kombinieren, kosten alle diese Seiten zusammen jetzt etwa 1 ms. Und indem wir mehrere Leseanforderungen gleichzeitig parallel ausführen, zahlen wir diese 1 ms Latenz effektiv nur einmal pro Batch.

Asynchrone E/A-Methoden

Das neue Subsystem kann in einem von drei Modi ausgeführt werden, die über den Parameter io_method mit den möglichen Werten „worker“ (Standard), „io_uring“ und „sync“ konfiguriert werden. Wir werden erläutern, wie die einzelnen Modi funktionieren, und dann zeigen, wie die asynchrone E/A in unserer Umgebung überwacht werden kann.

io_method = sync

Dieser Modus schaltet AIO effektiv aus. Lesevorgänge werden über dieselbe AIO-API, aber synchron ausgeführt, wobei reguläre preadv- oder pwritev-Methoden auf dem Backend-Prozess verwendet werden, der die E/A ausgegeben hat. Diese Methode verwendet keinen zusätzlichen gemeinsam genutzten Speicher und ist hauptsächlich für Regressionstests gedacht oder wenn wir vermuten, dass sich AIO falsch verhält. Sie wird auch intern als Fallback auf die synchrone E/A für Operationen verwendet, die keine asynchrone E/A verwenden können. PostgreSQL-Kernfunktionen geben einen Fehler aus, wenn eine Erweiterung versuchen würde, die asynchrone E/A über die AIO-API zu erzwingen, wenn die globale io_method auf „sync“ gesetzt ist. Verfügbare Benchmarks zeigen, dass dieser PostgreSQL 18-Modus ähnlich wie die Streaming-E/A von PostgreSQL 17 funktioniert.

io_method = io_uring (Linux only)

Auf modernen Linux-Systemen (Kernel-Version 5.1 oder höher) kann PostgreSQL direkt mit der io_uring-Schnittstelle des Kernels kommunizieren. Die Verwendung erfordert, dass PostgreSQL mit liburing-Unterstützung gebaut wird – wir können dies in PostgreSQL mit der Funktion select from pg_config() überprüfen:

SELECT pg_config FROM pg_config() where pg_config::text ilike ’%liburing%’;

Asynchrone E/A-Operationen von PostgreSQL (sowohl io_uring als auch Worker) verwenden gemeinsam genutzte Speicherstrukturen, um die Anforderungen auszugeben und Informationen über deren Abschluss oder Fehler zu empfangen. Auf diese Weise kann der PostgreSQL AIO-Code Batching und Parallelität verwalten, ohne direkt von einer bestimmten AIO-Methode abhängig zu sein. Der PostgreSQL-Code verwaltet eine separate io_uring-Instanz für jedes Backend, einschließlich Hilfsprozesse. Die Ringe werden jedoch im Postmaster erstellt, sodass sie gemeinsam genutzten Speicher verwenden können und es keine Konflikte oder Blockierungen zwischen den Backends gibt.

Das Verarbeitungsszenario ist sehr einfach:

Backends schreiben Anforderungen über die API in einen Submission-Ring im gemeinsam genutzten Speicher
Der Kernel führt E/A asynchron aus und schreibt Ergebnisse in einen Completion-Ring
Der Inhalt des Completion-Rings wird vom Backend mit weniger Kontextwechseln verarbeitet

Die Ausführung erfolgt weiterhin im selben Prozess wie bei der Methode „sync„, aber es werden Kernel-Worker-Threads für die parallele Verarbeitung verwendet. Dies ist typischerweise bei sehr schnellen NVMe-SSDs von Vorteil.

Die io_uring-Linux-Funktion hatte jedoch auch eine schwierige Sicherheitshistorie. Sie umgeht traditionelle Syscall-Audit-Pfade und war daher an einem großen Teil der Linux-Kernel-Exploits beteiligt. Google berichtete, dass 60 % der Linux-Kernel-Schwachstellen im Jahr 2022 io_uring betrafen und einige Sicherheitstools diese Art von Angriffen nicht aufdecken konnten. Daher deaktivieren einige Containerumgebungen io_uring vollständig.

io_method = worker

Dies ist die plattformübergreifende, „sichere“ Implementierung und der Standard in PostgreSQL 18. Der Mechanismus ist dem bestehenden parallelen Abfrageverarbeitung sehr ähnlich. Der Hauptunterschied besteht darin, dass Hintergrund-E/A-Worker langlebige, unabhängige Prozesse sind, die beim Serverstart erstellt werden, nicht kurzlebige Prozesse, die pro Abfrage erzeugt werden.

Typischer Ablauf:

Beim Serverstart erstellt der Postmaster einen Pool von E/A-Worker-Prozessen. Die Anzahl wird durch den Parameter io_workers mit einem Standardwert von 3 gesteuert. Benchmarks legen jedoch nahe, dass diese Zahl auf vielen Kernmaschinen höher sein sollte, typischerweise zwischen ¼ und ½ der verfügbaren CPU-Threads. Der beste Wert hängt von der Workload und der Speicherlatenz ab.
Backends übermitteln Leseanforderungen in eine gemeinsam genutzte Speicher-Submission-Queue. Diese Submission-Queue ist im Allgemeinen ein Ringpuffer, in den mehrere Backends gleichzeitig schreiben können. Sie enthält nur Metadaten über die Anforderung – Handle-Indizes, nicht den vollständigen Anforderungsdatensatz. Es gibt nur eine Submission-Queue für den gesamten Cluster, nicht pro Datenbank oder pro Backend. Die tatsächlichen Details der Anforderung werden in einer separaten Speicherstruktur gespeichert.
Es wird geprüft, ob die Anforderung synchron ausgeführt werden muss oder asynchron verarbeitet werden kann. Die synchrone Ausführung kann auch gewählt werden, wenn die Submission-Queue voll ist. Dies vermeidet Probleme mit der gemeinsam genutzten Speichernutzung unter extremer Last. Im Falle einer synchronen Ausführung verwendet der Code den Pfad für die oben beschriebene „sync“-Methode.
Die Anforderungsübermittlung im gemeinsam genutzten Speicher weckt einen E/A-Worker auf, der die Anforderung abruft und traditionelle blockierende read() / pread()-Aufrufe ausführt. Wenn die Queue noch nicht leer ist, kann der aufgeweckte Worker 2 zusätzliche Worker aufwecken, um sie parallel zu verarbeiten. Im Code wird erwähnt, dass dies in Zukunft auf konfigurierbare N Worker erweitert werden kann. Dieses Limit hilft, das sogenannte „Thundering Herd Problem“ zu vermeiden, bei dem ein einzelner Submitter zu viele Worker aufwecken würde, was zu Chaos und Sperren für andere Backends führen würde.
Eine Einschränkung für die asynchrone E/A ist die Tatsache, dass Worker nicht einfach von Backends geöffnete Dateideskriptoren wiederverwenden können, sondern Dateien in ihrem eigenen Kontext neu öffnen müssen. Wenn dies für einige Arten von Operationen nicht möglich ist, wird für diese spezifische Anforderung der synchrone E/A-Pfad verwendet.
Wenn Worker eine Anforderung ohne Fehler abschließen, schreiben sie Datenblöcke in gemeinsam genutzte Puffer, legen das Ergebnis in eine Completion-Queue und signalisieren das Backend.
Aus der Perspektive des Backends wird die E/A „asynchron“, da das „Warten“ in Worker-Prozessen stattfindet, nicht im Abfrageprozess selbst.

Vorteile dieses Ansatzes:

Funktioniert auf allen unterstützten Betriebssystemen
Einfache Fehlerbehandlung: Wenn ein Worker abstürzt, werden Anforderungen als fehlgeschlagen markiert, der Worker beendet und ein neuer Worker vom Postmaster erzeugt
Vermeidet die Sicherheitsbedenken bezüglich der Linux io_uring-Schnittstelle
Der Nachteil sind zusätzliche Kontextwechsel und mögliche Konflikte in der gemeinsam genutzten Speicher-Queue, aber für viele Workloads macht die Möglichkeit, Lesevorgänge einfach zu überlappen, das leicht wett.
Diese Methode verbessert die Leistung auch dann, wenn alle Blöcke nur aus dem lokalen Linux-Speichercache kopiert werden, da dies jetzt parallel erfolgt

Tuning der neuen E/A-Parameter

PostgreSQL 18 fügt mehrere Parameter im Zusammenhang mit Festplatten-E/A hinzu oder aktualisiert sie. Wir haben bereits io_method und io_workers behandelt; sehen wir uns die anderen an. Weitere neue Parameter sind io_combine_limit und io_max_combine_limit. Sie steuern, wie viele Datenseiten PostgreSQL in einer einzigen AIO-Anforderung gruppiert. Größere Anforderungen führen typischerweise zu einem besseren Durchsatz, können aber auch die Latenz und die Speichernutzung erhöhen. Werte ohne Einheiten werden in 8-kB-Datenblöcken interpretiert. Mit Einheiten (kB, MB) stellen sie direkt die Größe dar – sollten jedoch Vielfache von 8 kB sein.

Der Parameter io_max_combine_limit ist eine feste Obergrenze beim Serverstart, io_combine_limit ist der vom Benutzer einstellbare Wert, der zur Laufzeit geändert werden kann, aber das Maximum nicht überschreiten darf. Die Standardwerte für beide sind 128 kB (16 Datenseiten). Die Dokumentation empfiehlt jedoch, unter Unix bis zu 1 MB (128 Datenseiten) und unter Windows 128 kB (16 Datenseiten – aufgrund von Einschränkungen in internen Windows-Puffern) einzustellen. Wir können mit höheren Werten experimentieren, aber basierend auf HW- und OS-Limits erreichen die AIO-Vorteile nach einer bestimmten Chunk-Größe ein Plateau; ein zu hohes Einstellen hilft nicht und kann sogar die Latenz erhöhen.

PostgreSQL 18 führt auch die Einstellung io_max_concurrency ein, die die maximale Anzahl von E/As steuert, die ein Prozess gleichzeitig ausführen kann. Die Standardeinstellung -1 bedeutet, dass der Wert automatisch basierend auf anderen Einstellungen ausgewählt wird, aber er darf 64 nicht überschreiten.

Ein weiterer verwandter Parameter ist effective_io_concurrency – die Anzahl der gleichzeitigen E/A-Operationen, die gleichzeitig auf dem Speicher ausgeführt werden können. Der Wertebereich liegt zwischen 1 und 1000, der Wert 0 deaktiviert asynchrone E/A-Anforderungen. Der Standardwert ist jetzt 16, einige Community-Artikel empfehlen, auf modernen SSDs bis zu 200 zu gehen. Die beste Einstellung hängt von der spezifischen Hardware und dem Betriebssystem ab, einige Artikel warnen jedoch auch davor, dass ein zu hoher Wert die E/A-Latenz für alle Abfragen erheblich erhöhen kann.

So überwachen Sie asynchrone E/A

pg_stat_activity

Für io_method = worker sind Hintergrund-E/A-Worker in pg_stat_activity als backend_type = ‚io worker‘ sichtbar. Sie zeigen die Werte wait_event_type / wait_event Activity / IoWorkerMain an, wenn sie im Leerlauf sind, oder typischerweise IO / DataFileRead, wenn sie mit der Arbeit beschäftigt sind.

SELECT pid, backend_start, wait_event_type, wait_event, backend_type
FROM pg_stat_activity
WHERE backend_type = 'io worker';


  pid | backend_start.                | wait_event_type | wait_event   | backend_type
------+-------------------------------+-----------------+--------------+--------------
   34 | 2025-12-09 11:44:23.852461+00 | Activity        | IoWorkerMain | io worker
   35 | 2025-12-09 11:44:23.852832+00 | Activity        | IoWorkerMain | io worker
   36 | 2025-12-09 11:44:23.853119+00 | IO              | DataFileRead | io worker
   37 | 2025-12-09 11:44:23.8534+00   | IO              | DataFileRead | io worker

Wir können pg_stat_io mit pg_stat_activity kombinieren, um zu sehen, welche Backends AIO-Anforderungen ausgeben, welche Abfragen sie ausführen und wie ihr aktueller AIO-Status ist:

SELECT a.pid, a.usename, a.application_name, a.backend_type, a.state, a.query,
ai.operation, ai.state AS aio_state, ai.length AS aio_bytes, ai.target_desc
FROM pg_aios ai
JOIN pg_stat_activity a ON a.pid = ai.pid
ORDER BY a.backend_type, a.pid, ai.io_id;


 -[ RECORD 1 ]----+------------------------------------------------------------------------
 pid              | 58
 usename          | postgres
 application_name | psql
 backend_type     | client backend
 state            | active
 query.           | explain analyze SELECT ........
 operation        | readv
 aio_state        | SUBMITTED
 aio_bytes        | 704512
 target_desc      | blocks 539820..539905 in file "pg_tblspc/16647/PG_18_202506291/5/16716"
 -[ RECORD 2 ]----+------------------------------------------------------------------------
 pid              | 159
 usename          | postgres
 application_name | psql
 backend_type     | parallel worker
 state            | active
 query            | explain analyze SELECT ........
 operation        | readv
 aio_state        | SUBMITTED
 aio_bytes        | 704512
 target_desc      | blocks 536326..536411 in file "pg_tblspc/16647/PG_18_202506291/5/16716"

pg_aios: Current AIO handles

PostgreSQL 18 führt mehrere neue Beobachtungsfunktionen ein, die uns helfen, die asynchrone E/A in Aktion zu überwachen. Die neue Systemansicht pg_aios listet aktuell verwendete asynchrone E/A-Handles auf – im Wesentlichen „E/A-Anforderungen, die vorbereitet, ausgeführt oder abgeschlossen werden“.

Die wichtigsten Spalten für jedes Handle sind:

pid: Backend, das die E/A ausgibt
io_id, io_generation: identifizieren ein Handle über die Wiederverwendung hinweg
state: HANDED_OUT, DEFINED, STAGED, SUBMITTED, COMPLETED_IO, COMPLETED_SHARED, COMPLETED_LOCAL
operation: invalid, readv (vektorisierter Lesevorgang) oder writev (vektorisierter Schreibvorgang)
off, length: Offset und Größe der E/A-Operation
target, target_desc: was wir lesen/schreiben (typischerweise Relationen)
result: UNKNOWN, OK, PARTIAL, WARNING, ERROR

Wir können einige einfache Statistiken aller aktuell laufenden E/As generieren, gruppiert nach Status und Ergebnis:

-- Zusammenfassung der aktuellen AIO-Handles nach Status und Ergebnis
SELECT state, result, count(*) AS cnt, pg_size_pretty(sum(length)) AS total_size
FROM pg_aios GROUP BY state, result ORDER BY state, result;

 state            | result  | cnt | total_size
------------------+---------+-----+------------
 COMPLETED_SHARED | OK      | 1   | 688 kB
 SUBMITTED        | UNKNOWN | 6   | 728 kB

-- In-flight async I/O handles
SELECT COUNT(*) AS aio_handles, SUM(length) AS aio_bytes FROM pg_aios;

 aio_handles | aio_bytes
-------------+-----------
   7         | 57344

-- Sessions currently waiting on I/O
SELECT COUNT(*) AS sessions_waiting_on_io FROM pg_stat_activity WHERE wait_event_type = 'IO';

 sessions_waiting_on_io
------------------------
  9

Oder wir können es verwenden, um Details zu aktuellen AIO-Anforderungen anzuzeigen:

SELECT pid, state, operation, pg_size_pretty(length) AS io_size, target_desc, result
FROM pg_aios ORDER BY pid, io_id;

 pid | state     | operation | io_size    | target_desc                                                             | result
-----+-----------+-----------+------------+-------------------------------------------------------------------------+---------
  51 | SUBMITTED | readv     | 688 kB     | blocks 670470..670555 in file "pg_tblspc/16647/PG_18_202506291/5/16716" | UNKNOWN
  63 | SUBMITTED | readv     | 8192 bytes | block 1347556 in file "pg_tblspc/16647/PG_18_202506291/5/16719"         | UNKNOWN
  65 | SUBMITTED | readv     | 688 kB     | blocks 671236..671321 in file "pg_tblspc/16647/PG_18_202506291/5/16716" | UNKNOWN
  66 | SUBMITTED | readv     | 8192 bytes | block 1344674 in file "pg_tblspc/16647/PG_18_202506291/5/16719"         | UNKNOWN
  67 | SUBMITTED | readv     | 8192 bytes | block 1337819 in file "pg_tblspc/16647/PG_18_202506291/5/16719"         | UNKNOWN
  68 | SUBMITTED | readv     | 688 kB     | blocks 672002..672087 in file "pg_tblspc/16647/PG_18_202506291/5/16716" | UNKNOWN
  69 | SUBMITTED | readv     | 688 kB     | blocks 673964..674049 in file "pg_tblspc/16647/PG_18_202506291/5/16716" | UNKNOWN

pg_stat_io: Cumulative I/O stats

Die Katalogansicht pg_stat_io wurde in PostgreSQL 16 eingeführt, aber PostgreSQL 18 erweitert sie um Byte-Zähler (read_bytes, write_bytes, extend_bytes) und eine bessere Abdeckung von WAL- und Bulk-I/O-Kontexten. Die Timing-Spalten werden jedoch nur gefüllt, wenn wir die Timing-Parameter aktivieren – track_io_timing – Standard ist aus.

Eine praktische, clientseitige Ansicht der Beziehungs-I/O:

SELECT backend_type, context, sum(reads) AS reads, 
pg_size_pretty(sum(read_bytes)) AS read_bytes, 
round(sum(read_time)::numeric, 2) AS read_ms, sum(writes) AS writes, 
pg_size_pretty(sum(write_bytes)) AS write_bytes,
round(sum(write_time)::numeric, 2) AS write_ms, sum(extends) AS extends,
pg_size_pretty(sum(extend_bytes)) AS extend_bytes
FROM pg_stat_io
WHERE object = 'relation' AND backend_type IN ('client backend')
GROUP BY backend_type, context
ORDER BY backend_type, context;

 backend_type   | context   | reads   | read_bytes | read_ms   | writes | write_bytes | write_ms | extends | extend_bytes
----------------+-----------+---------+------------+-----------+--------+-------------+----------+---------+--------------
 client backend | bulkread  | 13833   | 9062 MB    | 124773.28 | 0      | 0 bytes     | 0.00     |         |
 client backend | bulkwrite | 0       | 0 bytes    | 0.00      | 0      | 0 bytes     | 0.00     | 0       | 0 bytes
 client backend | init      | 0       | 0 bytes    | 0.00      | 0      | 0 bytes     | 0.00     | 0       | 0 bytes
 client backend | normal    | 2265214 | 17 GB      | 553940.57 | 0      | 0 bytes     | 0.00     | 0       | 0 bytes
 client backend | vacuum    | 0       | 0 bytes    | 0.00      | 0      | 0 bytes     | 0.00     | 0       | 0 bytes


-- Top-Tabellen nach gelesenen Heap-Blöcken und Cache-Trefferrate

SELECT relid::regclass AS table_name, heap_blks_read, heap_blks_hit,
ROUND( CASE WHEN heap_blks_read + heap_blks_hit = 0 THEN 0
ELSE heap_blks_hit::numeric / (heap_blks_read + heap_blks_hit) * 100 END, 2) AS cache_hit_pct
FROM pg_statio_user_tables
ORDER BY heap_blks_read DESC LIMIT 20;

 table_name           | heap_blks_read | heap_blks_hit | cache_hit_pct
----------------------+----------------+---------------+---------------
 table1               | 18551282       | 3676632       | 16.54
 table2               | 1513673        | 102222970     | 98.54
 table3               | 19713          | 1034435       | 98.13
 ...


-- Top-Indizes nach gelesenen Indexblöcken und Cache-Trefferrate

SELECT relid::regclass AS table_name, indexrelid::regclass AS index_name,
idx_blks_read, idx_blks_hit 
FROM pg_statio_user_indexes
ORDER BY idx_blks_read DESC LIMIT 20;

 table_name | index_name      | idx_blks_read | idx_blks_hit
------------+-----------------+---------------+--------------
 table1     | idx_table1_date | 209289        | 141
 table2     | table2_pkey     | 37221         | 1223747
 table3     | table3_pkey     | 9825          | 3143947
...

Um eine Baseline vor/nach einem Testlauf zu erstellen, können wir die Statistiken zurücksetzen (als Superuser):

SELECT pg_stat_reset_shared(‚io‘);

Führen Sie dann unsere Arbeitslast aus und fragen Sie

pg_stat_io

erneut ab, um zu sehen, wie viele Bytes gelesen/geschrieben wurden und wie viel Zeit für das Warten auf E/A aufgewendet wurde.

Fazit

Das neue asynchrone I/O-Subsystem von PostgreSQL 18 ist ein bedeutender Schritt zur Verbesserung der I/O-Leistung für große Scans und Wartungsarbeiten. Durch die Überlappung von Lesevorgängen und die Möglichkeit, mehrere Anfragen gleichzeitig zu bearbeiten, können moderne Speichersysteme besser genutzt und die Abfragezeiten für datenintensive Workloads verkürzt werden. Mit den neuen Beobachtungsfunktionen in pg_aios und pg_stat_io können DBAs und Entwickler die AIO-Aktivität überwachen und Parameter optimieren, um die Leistung für ihre spezifischen Workloads zu optimieren. Da sich PostgreSQL ständig weiterentwickelt, können wir weitere Verbesserungen am AIO-Subsystem und eine breitere Abdeckung von Operationen erwarten, die von asynchronem I/O profitieren können.

PostgreSQL ist ein eingetragenes Warenzeichen der PostgreSQL Community Association of Canada.

In der Vergangenheit gab es viele Diskussionen über die Verwendung von UUID als Primärschlüssel in PostgreSQL. Für einige Anwendungen reicht selbst eine BIGINT-Spalte nicht aus: Es handelt sich um eine vorzeichenbehaftete 8-Byte-Ganzzahl mit einem Bereich von −9.223.372.036.854.775.808 bis +9.223.372.036.854.775.807. Obwohl diese Werte groß genug erscheinen, wird diese Zahl weniger beeindruckend, wenn wir an Webdienste denken, die täglich Milliarden oder mehr Datensätze sammeln. Einfache Ganzzahlwerte können auch zu Wertkonflikten in verteilten Systemen, in Data Lakehouses beim kombinieren von Daten aus mehreren Quelldatenbanken usw. führen.

Das Hauptproblem bei UUIDv4 als Primärschlüssel in PostgreSQL war jedoch nicht der fehlende Bereich, sondern die vollständige Zufälligkeit der Werte. Diese Zufälligkeit führt zu häufigen B-Baum-Seitenaufteilungen, einem stark fragmentierten Primärschlüsselindex und somit zu vielen zufälligen Festplatten-I/Os. Es gab bereits viele Artikel und Konferenzvorträge, die dieses Problem beschrieben haben. Was viele dieser Ressourcen jedoch nicht taten, war, tief in die On-Disk-Strukturen einzutauchen. Das wollte ich hier untersuchen.

Was sind UUIDs

UUID (Universally Unique Identifier) ist ein 16-Byte-Ganzzahlwert (128 Bit), der 2^128 mögliche Kombinationen aufweist (ungefähr 3,4 × 10^38). Dieser Bereich ist so groß, dass für die meisten Anwendungen die Wahrscheinlichkeit einer doppelten UUID praktisch null ist. Wikipedia zeigt eine Berechnung, die demonstriert, dass die Wahrscheinlichkeit, ein Duplikat innerhalb von 103 Billionen Version-4-UUIDs zu finden, etwa eins zu einer Milliarde beträgt. Eine weitere oft zitierte Faustregel besagt, dass man, um eine 50%ige Chance auf eine Kollision zu haben, etwa 1 Milliarde UUIDs pro Sekunde über etwa 86 Jahre generieren müsste.

Werte werden üblicherweise als 36-stelliger String mit Hexadezimalziffern und Bindestrichen dargestellt, zum Beispiel: f47ac10b-58cc-4372-a567-0e02b2c3d479. Das kanonische Layout ist 8-4-4-4-12 Zeichen. Das erste Zeichen im dritten Block und das erste Zeichen im vierten Block haben eine besondere Bedeutung: xxxxxxxx-xxxx-Vxxx-Wxxx-xxxxxxxxxxxx – V kennzeichnet die UUID-Version (4 für UUIDv4, 7 für UUIDv7 usw.), W kodiert die Variante in ihren oberen 2 oder 3 Bits (die Layout-Familie der UUID).

Bis PostgreSQL 18 war die gängige Methode zur Generierung von UUIDs in PostgreSQL die Verwendung von Version 4 (zum Beispiel über gen_random_uuid() oder uuid_generate_v4() aus Erweiterungen). PostgreSQL 18 führt native Unterstützung für die neue zeitlich geordnete UUIDv7 über die Funktion uuidv7() ein und fügt auch uuidv4() als integrierten Alias für die ältere Funktion gen_random_uuid() hinzu. UUID Version 4 wird vollständig zufällig generiert (abgesehen von den festen Versions- und Variantenbits), sodass es keine inhärente Reihenfolge in den Werten gibt. UUID Version 7 generiert Werte, die zeitlich geordnet sind, da die ersten 48 Bits einen Big-Endian Unix-Epoch-Zeitstempel mit ungefähr Millisekunden-Granularität enthalten, gefolgt von zusätzlichen Sub-Millisekunden-Bits und Zufälligkeit.

Testaufbau in PostgreSQL 18

Ich werde konkrete Ergebnisse anhand eines einfachen Testaufbaus zeigen – 2 verschiedene Tabellen mit der Spalte „id“, die einen generierten UUID-Wert (entweder v4 oder v7) enthält, der als Primärschlüssel verwendet wird, und der Spalte „ord“ mit sequenziell generiertem Bigint, wobei die Reihenfolge der Zeilenerstellung beibehalten wird.

-- UUIDv4 (completely random keys)
CREATE TABLE uuidv4_demo (
    id uuid PRIMARY KEY DEFAULT uuidv4(), -- alias of gen_random_uuid()
    ord bigint GENERATED ALWAYS AS IDENTITY
);

-- UUIDv7 (time-ordered keys)
CREATE TABLE uuidv7_demo (
    id uuid PRIMARY KEY DEFAULT uuidv7(),
    ord bigint GENERATED ALWAYS AS IDENTITY
);

-- 1M rows with UUIDv4
INSERT INTO uuidv4_demo (id) SELECT uuidv4() FROM generate_series(1, 1000000);

-- 1M rows with UUIDv7
INSERT INTO uuidv7_demo (id) SELECT uuidv7() FROM generate_series(1, 1000000);

VACUUM ANALYZE uuidv4_demo;
VACUUM ANALYZE uuidv7_demo;

Performance auf Abfrageebene: EXPLAIN ANALYZE

Als ersten Schritt vergleichen wir die Kosten der Sortierung nach UUID für die beiden Tabellen:

-- UUIDv4
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM uuidv4_demo ORDER BY id;

Index Scan using uuidv4_demo_pkey on uuidv4_demo (cost=0.42..60024.31 rows=1000000 width=24) (actual time=0.031..301.163 rows=1000000.00 loops=1)
Index Searches: 1
Buffers: shared hit=1004700 read=30
Planning Time: 0.109 ms
Execution Time: 318.005 ms

-- UUIDv7
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM uuidv7_demo ORDER BY id;

Index Scan using uuidv7_demo_pkey on uuidv7_demo (cost=0.42..36785.43 rows=1000000 width=24) (actual time=0.013..96.177 rows=1000000.00 loops=1)
Index Searches: 1
Buffers: shared hit=2821 read=7383
Planning Time: 0.040 ms
Execution Time: 113.305 ms

Die genauen Pufferzahlen hängen von Cache-Effekten ab, aber eines ist in diesem Durchlauf klar: Der Index-Scan über UUIDv7 benötigt etwa 100-mal weniger Puffer-Treffer und ist etwa dreimal schneller (113 ms vs. 318 ms) für dieselbe Million-Zeilen-ORDER BY id. Dies ist das erste Anzeichen dafür, dass UUIDv7 eine sehr praktikable Lösung für einen Primärschlüssel ist, wenn wir eine BIGINT-Spalte durch etwas ersetzen müssen, das einen viel größeren Speicherplatz und eine höhere Einzigartigkeit bietet, während es sich aus Sicht des Index immer noch wie ein sequenzieller Schlüssel verhält.

Einfügegeschwindigkeit – einfaches Benchmarking

Ursprünglich wollte ich ausgefeiltere Tests durchführen, aber selbst ein sehr einfacher, naiver Benchmark zeigte einen enormen Unterschied in der Einfügegeschwindigkeit. Ich verglich die Zeit, die benötigt wurde, um 50 Millionen Zeilen in eine leere Tabelle einzufügen, und dann noch einmal in eine Tabelle mit 50 Millionen vorhandenen Zeilen.

INSERT INTO uuidv4_demo (id) SELECT uuidv4() FROM generate_series(1, 50000000);
INSERT INTO uuidv7_demo (id) SELECT uuidv7() FROM generate_series(1, 50000000);

-- UUID v4 -- UUID v7
Empty table
Insert time: 1239839.702 ms (20:39.840) Insert time: 106343.314 ms (01:46.343)
Table size: 2489 MB Table size: 2489 MB
Index size: 1981 MB Index size: 1504 MB

Table with 50M rows
Insert time: 2776880.790 ms (46:16.881) Insert time: 100354.087 ms (01:40.354)
Table size: 4978 MB Table size: 4978 MB
Index size: 3956 MB Index size: 3008 MB

Wie wir sehen können, ist die Einfügegeschwindigkeit radikal unterschiedlich. Das Einfügen der ersten 50 Millionen Zeilen in eine leere Tabelle dauerte für UUIDv7 nur 1:46 Minuten, aber bereits 20 Minuten für UUIDv4. Die zweite Charge zeigte sogar einen 2-mal größeren Unterschied.

Wie Werte in der Tabelle verteilt sind

Diese Ergebnisse deuten auf enorme Unterschiede in den Indizes hin. Lassen Sie uns dies analysieren. Zuerst werden wir überprüfen, wie die Werte in der Tabelle verteilt sind. Ich verwende die folgende Abfrage für beide Tabellen (nur den Tabellennamen wechseln):

SELECT
row_number() OVER () AS seq_in_uuid_order,
id,
ord,
ctid
FROM uuidv4_demo
ORDER BY id
LIMIT 20;

Die Spalte seq_in_uuid_order ist lediglich die Zeilennummer in UUID-Reihenfolge, ord ist die Einfügereihenfolge, ctid zeigt den physischen Speicherort jedes Tupels im Heap an: (block_number, offset_in_block).

UUIDv4: random UUID order ⇒ random heap access

Wie sehen die Ergebnisse für UUIDv4 aus?

 seq_in_uuid_order | id                                   | ord    | ctid 
-------------------+--------------------------------------+--------+------------
                 1 | 00000abf-cc8e-4cb2-a91a-701a3c96bd36 | 673969 | (4292,125)
                 2 | 00001827-16fe-4aee-9bce-d30ca49ceb1d | 477118 | (3038,152)
                 3 | 00001a84-6d30-492f-866d-72c3b4e1edff | 815025 | (5191,38)
                 4 | 00002759-21d1-4889-9874-4a0099c75286 | 879671 | (5602,157)
                 5 | 00002b44-b1b5-473f-b63f-7554fa88018d | 729197 | (4644,89)
                 6 | 00002ceb-5332-44f4-a83b-fb8e9ba73599 | 797950 | (5082,76)
                 7 | 000040e2-f6ac-4b5e-870a-63ab04a5fa39 | 160314 | (1021,17)
                 8 | 000053d7-8450-4255-b320-fee8d6246c5b | 369644 | (2354,66)
                 9 | 00009c78-6eac-4210-baa9-45b835749838 | 463430 | (2951,123)
                10 | 0000a118-f98e-4e4a-acb3-392006bcabb8 | 96325  | (613,84)
                11 | 0000be99-344b-4529-aa4c-579104439b38 | 454804 | (2896,132)
                12 | 00010300-fcc1-4ec4-ae16-110f93023068 | 52423  | (333,142)
                13 | 00010c33-a4c9-4612-ba9a-6c5612fe44e6 | 82935  | (528,39)
                14 | 00011fa2-32ce-4ee0-904a-13991d451934 | 988370 | (6295,55)
                15 | 00012920-38c7-4371-bd15-72e2996af84d | 960556 | (6118,30)
                16 | 00014240-7228-4998-87c1-e8b23b01194a | 66048  | (420,108)
                17 | 00014423-15fc-42ca-89bd-1d0acf3e5ad2 | 250698 | (1596,126)
                18 | 000160b9-a1d8-4ef0-8979-8640025c0406 | 106463 | (678,17)
                19 | 0001711a-9656-4628-9d0c-1fb40620ba41 | 920459 | (5862,125)
                20 | 000181d5-ee13-42c7-a9e7-0f2c52faeadb | 513817 | (3272,113)

Die Werte sind vollständig zufällig verteilt. Das Lesen von Zeilen in UUID-Reihenfolge ist hier praktisch sinnlos und führt direkt zu zufälligen Heap-Zugriffen bei Abfragen, die den Primärschlüsselindex verwenden.

UUIDv7: UUID-Reihenfolge folgt der Einfügereihenfolge

Andererseits werden UUIDv7-Werte in einer klaren Reihenfolge generiert:

 seq_in_uuid_order | id                                   | ord | ctid  
-------------------+--------------------------------------+-----+--------
                 1 | 019ad94d-0127-7aba-b9f6-18620afdea4a |   1 | (0,1)
                 2 | 019ad94d-0131-72b9-823e-89e41d1fad73 |   2 | (0,2)
                 3 | 019ad94d-0131-7384-b03d-8820be60f88e |   3 | (0,3)
                 4 | 019ad94d-0131-738b-b3c0-3f91a0b223a8 |   4 | (0,4)
                 5 | 019ad94d-0131-7391-ab84-a719ca98accf |   5 | (0,5)
                 6 | 019ad94d-0131-7396-b41d-7f9f27a179c4 |   6 | (0,6)
                 7 | 019ad94d-0131-739b-bdb3-4659aeaafbdd |   7 | (0,7)
                 8 | 019ad94d-0131-73a0-b271-7dba06512231 |   8 | (0,8)
                 9 | 019ad94d-0131-73a5-8911-5ec5d446c8a9 |   9 | (0,9)
                10 | 019ad94d-0131-73aa-a4a3-0e5c14f09374 |  10 | (0,10)
                11 | 019ad94d-0131-73af-ac4b-3710e221390e |  11 | (0,11)
                12 | 019ad94d-0131-73b4-85d6-ed575d11e9cf |  12 | (0,12)
                13 | 019ad94d-0131-73b9-b802-d5695f5bf781 |  13 | (0,13)
                14 | 019ad94d-0131-73be-bcb0-b0775dab6dd4 |  14 | (0,14)
                15 | 019ad94d-0131-73c3-9ec8-c7400b5c8983 |  15 | (0,15)
                16 | 019ad94d-0131-73c8-b067-435258087b3a |  16 | (0,16)
                17 | 019ad94d-0131-73cd-a03f-a28092604fb1 |  17 | (0,17)
                18 | 019ad94d-0131-73d3-b4d5-02516d5667b5 |  18 | (0,18)
                19 | 019ad94d-0131-73d8-9c41-86fa79f74673 |  19 | (0,19)
                20 | 019ad94d-0131-73dd-b9f1-dcd07598c35d |  20 | (0,20)

Hier folgen seq_in_uuid_order, ord und ctid alle schön aufeinander – ord erhöht sich für jede Zeile um 1, ctid bewegt sich sequenziell durch die erste Heap-Seite, und die UUIDs selbst sind aufgrund des Zeitstempelpräfixes monoton. Für Index-Scans auf dem Primärschlüssel bedeutet dies, dass Postgres den Heap viel sequenzieller durchlaufen kann als mit UUIDv4.

Wie sequenziell sind diese Werte statistisch?

Nach VACUUM ANALYZE frage ich den Planer, was er über die Korrelation zwischen ID und der physischen Reihenfolge denkt:

SELECT
  tablename,
  attname,
  correlation
FROM pg_stats
WHERE tablename IN ('uuidv4_demo', 'uuidv7_demo')
AND attname = 'id'
ORDER BY tablename, attname;

Ergebnis:

 tablename   | attname | correlation 
-------------+---------+---------------
uuidv4_demo  | id      | -0.0024808696
uuidv7_demo  | id      | 1

Die Statistiken bestätigen, was wir gerade gesehen haben:

Für uuidv4_demo.id ist die Korrelation im Wesentlichen 0 ⇒ Werte sind zufällig in Bezug auf die Heap-Reihenfolge.
Für uuidv7_demo.id ist die Korrelation 1 ⇒ perfekte Übereinstimmung zwischen UUID-Reihenfolge und physischer Zeilenreihenfolge in diesem Testlauf.

Diese hohe Korrelation ist genau der Grund, warum UUIDv7 als Primärschlüssel für B-Baum-Indizes so attraktiv ist.

Primärschlüsselindizes: Größe, Leaf Pages, Dichte, Fragmentierung

Als Nächstes betrachte ich die Primärschlüsselindizes – ihre Größe, Anzahl der Leaf Pages, Dichte und Fragmentierung – mithilfe von pgstatindex:

SELECT 'uuidv4_demo_pkey' AS index_name, (pgstatindex('uuidv4_demo_pkey')).*;

 index_name         | uuidv4_demo_pkey
 version            | 4
 tree_level         | 2
 index_size         | 40026112
 root_block_no.     | 295
 internal_pages     | 24
 leaf_pages.        | 4861
 empty_pages        | 0
 deleted_pages      | 0
 avg_leaf_density   | 71 
 leaf_fragmentation | 49.99 

SELECT 'uuidv7_demo_pkey' AS index_name, (pgstatindex('uuidv7_demo_pkey')).*;

 index_name         | uuidv7_demo_pkey
 version            | 4
 tree_level         | 2
 index_size         | 31563776
 root_block_no      | 295
 internal_pages.    | 20
 leaf_pages         | 3832
 empty_pages        | 0
 deleted_pages      | 0
 avg_leaf_density   | 89.98 -- i.e. standard 90% fillfactor
 leaf_fragmentation | 0

Wir können sofort erkennen, dass der Primärschlüsselindex auf UUIDv4 etwa 26–27 % größer ist:

index_size beträgt ~40 MB vs. ~31,6 MB
leaf_pages sind 4861 vs. 3832 (wiederum etwa 26–27 % mehr)
Leaf Pages im v4-Index haben eine geringere durchschnittliche Dichte (71 vs. ~90)
leaf_fragmentation für v4 beträgt etwa 50 %, während sie für v7 0 ist

UUIDv4 zwingt den B-Baum also dazu, mehr Pages zu allozieren und diese weniger voll zu halten, und fragmentiert die Blattebene wesentlich stärker.

Tiefere Indexanalyse mit bt_multi_page_stats

Um tiefer einzusteigen, habe ich die B-Baum-Indizes Seite für Seite untersucht und einige Statistiken erstellt. Ich habe die folgende Abfrage für beide Indizes verwendet (nur den Indexnamen im CTE ändern). Die Abfrage berechnet die minimale, maximale und durchschnittliche Anzahl von Tupeln pro Index-Pages und überprüft auch, wie sequenziell Pages in der Indexdatei gespeichert sind:

WITH leaf AS (
 SELECT *
 FROM bt_multi_page_stats('uuidv4_demo_pkey', 1, -1) -- from block 1 to end
 WHERE type = 'l'
)
SELECT
 count(*) AS leaf_pages,
 min(blkno) AS first_leaf_blk,
 max(blkno) AS last_leaf_blk,
 max(blkno) - min(blkno) + 1 AS leaf_span,
 round( count(*)::numeric / (max(blkno) - min(blkno) + 1), 3) AS leaf_density_by_span,
 min(live_items) AS min_tuples_per_page,
 max(live_items) AS max_tuples_per_page,
 avg(live_items)::numeric(10,2) AS avg_tuples_per_page,
 sum(CASE WHEN btpo_next = blkno + 1 THEN 1 ELSE 0 END) AS contiguous_links,
 sum(CASE WHEN btpo_next  0 AND btpo_next  blkno + 1 THEN 1 ELSE 0 END) AS non_contiguous_links
FROM leaf;

Ergebnisse für UUIDv4:

-- uuidv4_demo_pkey
leaf_pages           | 4861
first_leaf_blk       | 1
last_leaf_blk        | 4885
leaf_span            | 4885
leaf_density_by_span | 0.995
min_tuples_per_page  | 146
max_tuples_per_page  | 291
avg_tuples_per_page  | 206.72
contiguous_links     | 0
non_contiguous_links | 4860

Ergebnisse für UUIDv7:

-- uuidv7_demo_pkey
leaf_pages           | 3832
first_leaf_blk       | 1
last_leaf_blk        | 3852
leaf_span            | 3852
leaf_density_by_span | 0.995
min_tuples_per_page  | 109
max_tuples_per_page  | 262
avg_tuples_per_page  | 261.96
contiguous_links     | 3812
non_contiguous_links | 19

Wie wir sehen können, hat der UUIDv4-Index mehr Pages, die sich über einen größeren Bereich von Blöcken verteilen, und obwohl er eine höhere minimale und maximale Anzahl von Tupeln pro Seite aufweist, ist seine durchschnittliche Anzahl von Tupeln pro Page (206,72) signifikant niedriger als für UUIDv7 (261,96).

Diese Zahlen können jedoch das Gesamtbild verschleiern. Schauen wir uns also Histogramme an, die die Anzahl der Tupel in Pages visualisieren. Dafür werde ich die folgende Abfrage mit Buckets zwischen 100 und 300 verwenden und nur nicht-leere Ergebnisse auflisten:

WITH leaf AS (
 SELECT live_items
 FROM bt_multi_page_stats('uuidv4_demo_pkey', 1, -1)
  WHERE type = 'l'
),
buckets AS (
 -- bucket lower bounds: 100, 110, ..., 290
 SELECT generate_series(100, 290, 10) AS bucket_min
)
SELECT
 b.bucket_min AS bucket_from,
 b.bucket_min + 9 AS bucket_to,
 COUNT(l.live_items) AS page_count
FROM buckets b
LEFT JOIN leaf l
 ON l.live_items BETWEEN b.bucket_min AND b.bucket_min + 9
GROUP BY b.bucket_min HAVING count(l.live_items) > 0
ORDER BY b.bucket_min;

Ergebnis für UUIDv4:

 bucket_from | bucket_to | page_count 
-------------+-----------+------------
         140 |       149 |    159
         150 |       159 |    435
         160 |       169 |    388
         170 |       179 |    390
         180 |       189 |    427
         190 |       199 |    466
         200 |       209 |    430
         210 |       219 |    387
         220 |       229 |    416
         230 |       239 |    293
         240 |       249 |    296
         250 |       259 |    228
         260 |       269 |    214
         270 |       279 |    171
         280 |       289 |    140
         290 |       299 |     21

Ergebnis für UUIDv7:

 bucket_from | bucket_to | page_count 
-------------+-----------+------------
         100 |       109 |     1
         260 |       269 |  3831

Diese Ergebnisse demonstrieren eindrucksvoll die enorme Fragmentierung des UUIDv4-Index und die stabile, kompakte Struktur des UUIDv7-Index. Die niedrigsten Buckets im UUIDv4-Histogramm zeigen Fälle von halb leeren Blattindexseiten (leaf index pages), andererseits überschreiten Seiten mit mehr als 270 Tupeln den 90 % Füllfaktor, da PostgreSQL den verbleibenden freien Speicherplatz nutzt, um Splits zu vermeiden. Im UUIDv7-Index sind alle Pages bis auf eine (die allerletzte im Baum) bis zum 90 % Standard-Füllfaktor gefüllt.

Ein weiteres wichtiges Ergebnis findet sich in den letzten beiden Spalten der Indexstatistiken:

Für UUIDv4: contiguous_links = 0, non_contiguous_links = 4860
Für UUIDv7: contiguous_links = 3812, non_contiguous_links = 19

btpo_next = blkno + 1 bedeutet, dass die nächste Page in der logischen B-Baum-Reihenfolge auch der nächste physische Block ist. Bei UUIDv4 geschieht dies in diesem Test nie – die Page sind vollständig fragmentiert und zufällig über die Indexstruktur verteilt. Bei UUIDv7 sind fast alle Pages zusammenhängend, d.h. sie folgen schön aufeinander.

Wenn wir den tatsächlichen Inhalt der Pages untersuchen, können wir sofort die Zufälligkeit von UUIDv4 im Vergleich zum sequenziellen Verhalten von UUIDv7 erkennen: UUIDv4-Pages verweisen auf Heap-Tupel, die über die gesamte Tabelle verstreut sind, während UUIDv7-Pages dazu neigen, auf enge Bereiche von Heap-Seiten zu verweisen. Das Ergebnis ist dasselbe Muster, das wir zuvor beim direkten Betrachten von ctid aus der Tabelle gesehen haben, daher werde ich die Roh-Dumps hier nicht wiederholen.

Ein kleiner Haken: eingebetteter Zeitstempel in UUIDv7

Es gibt einen kleinen Haken bei UUIDv7-Werten: Sie legen einen Zeitstempel der Erstellung offen. PostgreSQL 18 macht dies explizit über uuid_extract_timestamp():

SELECT 
   id,
   uuid_extract_timestamp(id) AS created_at_from_uuid
FROM uuidv7_demo 
ORDER BY ord
LIMIT 5;

Beispielergebnisse:

 id                                   | created_at_from_uuid 
--------------------------------------+----------------------------
019ad94d-0127-7aba-b9f6-18620afdea4a  | 2025-12-01 09:44:53.799+00
019ad94d-0131-72b9-823e-89e41d1fad73  | 2025-12-01 09:44:53.809+00
019ad94d-0131-7384-b03d-8820be60f88e  | 2025-12-01 09:44:53.809+00
019ad94d-0131-738b-b3c0-3f91a0b223a8  | 2025-12-01 09:44:53.809+00
019ad94d-0131-7391-ab84-a719ca98accf  | 2025-12-01 09:44:53.809+00

Betrachten wir die gesamte Wertefolge, können wir die Zeitdifferenzen zwischen den Datensatz-Erstellungen direkt aus den UUIDs analysieren, ohne eine separate Zeitstempelspalte. Für einige Anwendungen könnte dies als potenzielles Informationsleck angesehen werden (z. B. die Offenlegung ungefährer Erstellungszeiten oder Anfrageraten), während es vielen anderen höchstwahrscheinlich egal sein wird.

Zusammenfassung

UUIDs bieten einen enormen Bezeichnerraum (128 Bit, ~3,4 × 10^38 Werte), bei dem die Wahrscheinlichkeit einer Kollision für reale Workloads vernachlässigbar ist.
Traditionelle UUIDv4-Schlüssel sind vollständig zufällig. Wenn sie als Primärschlüssel in PostgreSQL verwendet werden, neigen sie dazu:
- B-Baum-Indizes zu fragmentieren
- die Dichte der Pages zu verringern
- stark zufällige Heap-Zugriffsmuster und mehr zufällige I/O zu verursachen
UUIDv7, nativ in PostgreSQL 18 als uuidv7() eingeführt, behält den 128-Bit-Raum bei, ordnet die Bits jedoch so neu an, dass:
- die höchstwertigen Bits einen Unix-Zeitstempel mit Millisekundenpräzision (plus Sub-Millisekunden-Bruchteil) enthalten
- die restlichen Bits zufällig bleiben
In praktischen Tests mit 1 Million Zeilen pro Tabelle:
- Der UUIDv7-Primärschlüsselindex war etwa 26–27 % kleiner, mit weniger Pages und einer viel höheren durchschnittlichen Blattdichte
- Pages im UUIDv7-Index waren überwiegend physisch zusammenhängend, während die UUIDv4-Pages vollständig fragmentiert waren
- Eine ORDER BY id-Abfrage über UUIDv7 war in meinem Durchlauf etwa dreimal schneller als dieselbe Abfrage über UUIDv4, dank besserer Indexlokalität und sequenziellerem Heap-Zugriff

Der Kompromiss besteht darin, dass UUIDv7 einen Zeitstempel einbettet, der ungefähre Erstellungszeiten offenlegen könnte, aber für die meisten Anwendungsfälle ist dies akzeptabel oder sogar nützlich. UUIDv7 verbessert also die Leistung und das physische Layout von UUID-Primärschlüsseln in PostgreSQL erheblich, nicht indem es die Zufälligkeit aufgibt, sondern indem es ein zeitlich geordnetes Präfix hinzufügt. In PostgreSQL 18 bietet uns das das Beste aus beiden Welten: den riesigen Bezeichnerraum und die Vorteile der verteilten Generierung von UUIDs, mit einem Indexverhalten, das einem klassischen sequenziellen BIGINT-Primärschlüssel viel näher kommt.

PostgreSQL ist eine Open-Source-Datenbank, die von den PostgreSQL-Entwicklern bereitgestellt wird. Das PostgreSQL-Elefantenlogo („Slonik“), Postgres und PostgreSQL sind eingetragene Marken der PostgreSQL Community Association.

Wir bei credativ bieten umfassende Support- und Beratungsleistungen für den Betrieb von PostgreSQL und anderen Open-Source-Systemen an.

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.

Wie ich in meinem Vortrag auf der PostgreSQL Conference Europe 2025 erläutert habe, kann Datenbeschädigung unbemerkt in jeder PostgreSQL-Datenbank vorhanden sein und bleibt unentdeckt, bis wir beschädigte Daten physisch lesen. Es kann viele Gründe geben, warum einige Datenblöcke in Tabellen oder anderen Objekten beschädigt werden können. Selbst moderne Speicherhardware ist alles andere als unfehlbar. Binäre Backups, die mit dem pg_basebackup-Tool erstellt wurden – einer sehr gängigen Backup-Strategie in der PostgreSQL-Umgebung – lassen diese Probleme verborgen. Denn sie prüfen keine Daten, sondern kopieren ganze Datendateien so, wie sie sind. Mit der Veröffentlichung von PostgreSQL 18 hat die Community beschlossen, Daten-Checksummen standardmäßig zu aktivieren – ein wichtiger Schritt zur frühzeitigen Erkennung dieser Fehler. Dieser Beitrag untersucht, wie PostgreSQL Checksummen implementiert, wie es Checksummenfehler behandelt und wie wir sie auf bestehenden Clustern aktivieren können.

(mehr …)

Was Sie erwartet

Das Buffet: Bewährt und rheinisch

Alle Eckdaten auf einen Blick

Anmeldung & Details

Über credativ

Über Splendid Data

Was sind die größten Sicherheitsrisiken für PostgreSQL-Datenbanken?

Wie richtet man sichere Authentifizierung und Zugriffskontrolle ein?

Welche Backup-Strategien garantieren vollständige Datenwiederherstellung?

Backup-Methoden

Wie verschlüsselt man PostgreSQL-Daten richtig?

Welche Monitoring-Tools erkennen Sicherheitsvorfälle frühzeitig?

Wie führt man regelmäßige Sicherheitsupdates und Wartung durch?

Wie credativ bei der PostgreSQL-Sicherheit hilft

Ähnliche Artikel

Was sind PostgreSQL-Datentypen und warum sind sie wichtig?

Welche numerischen Datentypen bietet PostgreSQL?

Wie funktionieren Text- und Zeichenketten-Datentypen in PostgreSQL?

Welche Datums- und Zeit-Datentypen gibt es in PostgreSQL?

Was sind spezielle PostgreSQL-Datentypen und wann verwendet man sie?

Wie credativ® bei der optimalen Nutzung von PostgreSQL-Datentypen hilft

Ähnliche Artikel

Was ist die PostgreSQL-Lizenz und warum ist sie so beliebt?

Welche Rechte und Pflichten haben Unternehmen bei der PostgreSQL-Nutzung?

Wie unterscheidet sich PostgreSQL von anderen Datenbank-Lizenzen?

Gegenüberstellung der GNU General Public License (GPL), der GNU Affero General Public License (AGPL) und der PostgreSQL-Lizenz.

Der entscheidende Business-Vorteil der PostgreSQL-Lizenz

Was müssen Sie bei der kommerziellen PostgreSQL-Nutzung beachten?

Haftung

Wie credativ® bei PostgreSQL-Implementierung unterstützt

Transparenzhinweis:

Ähnliche Artikel

Was ist PostgreSQL und warum nutzen es so viele Unternehmen?

Wie unterscheidet sich PostgreSQL von anderen Datenbanken wie MySQL?

Welche Vorteile bietet PostgreSQL für Unternehmen?

Wie installiert und konfiguriert man PostgreSQL richtig? Einfaches Beispiel:

Wie credativ® bei PostgreSQL-Projekten unterstützt

Ähnliche Artikel

Signifikante Verbesserungen für Cloud-Volumes

Asynchrone E/A-Methoden

io_method = sync

io_method = io_uring (Linux only)

io_method = worker

Tuning der neuen E/A-Parameter

So überwachen Sie asynchrone E/A

pg_stat_activity

pg_aios: Current AIO handles

pg_stat_io: Cumulative I/O stats

Fazit

Was sind UUIDs

Testaufbau in PostgreSQL 18

Performance auf Abfrageebene: EXPLAIN ANALYZE

Einfügegeschwindigkeit – einfaches Benchmarking

Wie Werte in der Tabelle verteilt sind

UUIDv4: random UUID order ⇒ random heap access

UUIDv7: UUID-Reihenfolge folgt der Einfügereihenfolge

Wie sequenziell sind diese Werte statistisch?

Primärschlüsselindizes: Größe, Leaf Pages, Dichte, Fragmentierung

Tiefere Indexanalyse mit bt_multi_page_stats

Ein kleiner Haken: eingebetteter Zeitstempel in UUIDv7

Zusammenfassung

Mein Vortrag über Datenbankkorruption

Dienstag: Kubernetes- und KI-Gipfel

Mittwoch: Migrationen, Modellierung und Performance

Donnerstag: Cloud, EXPLAIN und Resilienz

Freitag: Weitere fortgeschrittene Themen

Fazit