--- title: "PostgreSQL-Beratung und Datenbankarchitektur | SKAFFON" description: "PostgreSQL-Beratung: Architektur, Performance, Hochverfügbarkeit und Sicherheit prüfen und umsetzen. Mit Health-Check-Katalog und Replikationshilfe." url: https://skaffon.de/daten/postgresql-datenbanken/ --- ![Draufsicht auf die Hände einer Person an einem Laptop, auf dessen Bildschirm grüner Konsolentext angezeigt wird](/_astro/draufsicht-haende-laptop-dessen.ps1Uidv3_mDqMY.jpg) 1. [Startseite](/) 2. [Daten](/daten/) 3. PostgreSQL-Beratung und Datenbankarchitektur PostgreSQL · Architektur, Performance, Hochverfügbarkeit # PostgreSQL-Beratung und Datenbankarchitektur Ihre Anwendungen hängen an einer Datenbank, deren Zustand niemand sicher kennt. Wir prüfen PostgreSQL nach einem festen Katalog, legen mit Ihnen das tragbare Datenverlust- und Ausfallziel fest und setzen die passende Architektur um. [Health-Check anfragen](/projekt-anfragen/) [Zum Prüfkatalog](/daten/postgresql-datenbanken/#health-check-katalog) - Befundliste statt Pauschalbewertung - Patroni, CloudNativePG, PgBouncer, pgBackRest - Änderungen an der Produktion nur nach Ihrer Freigabe Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 Beratung und Betrieb ## Erst wissen, dann ändern: PostgreSQL-Beratung bei SKAFFON SKAFFON berät zu PostgreSQL und setzt um: Architektur, Performance, Hochverfügbarkeit, Sicherheit und Betriebskonzepte für Datenbanken, von denen Ihre Anwendungen abhängen. Die Seite richtet sich an IT-Leitung und Plattformverantwortliche, die eine bestehende Umgebung prüfen lassen, eine neue Datenbankarchitektur festlegen oder Hochverfügbarkeit einführen wollen. Beratung und laufender Betrieb sind getrennte Leistungen. Hier geht es um Analyse, Entwurf und Umsetzung. Den dauerhaften Betrieb mit Failover, Backup und Wartung beschreibt [Managed PostgreSQL](/managed-services/managed-postgresql/); den Weg auf PostgreSQL oder auf eine neue Version beschreiben [PostgreSQL-Migration](/daten/postgresql-migration/) und [Datenbankmigration](/daten/datenbank-migration/). Was wir zum Start brauchen Lesezugriff auf Statistik- und Konfigurationsdaten genügt für die Analyse. Änderungen an der Produktion erfolgen nur nach Freigabe. Anlässe ## Woran Sie merken, dass die Datenbank geprüft werden sollte - Die Datenbank ist langsam geworden und niemand weiß, welche Abfragen oder welche Konfiguration die Ursache sind. - Ein Ausfall hat gezeigt, dass Failover oder Wiederherstellung nie wirklich getestet wurden. - Eine Anwendung soll hochverfügbar werden, und es ist offen, ob Patroni auf VMs, ein Kubernetes-Operator oder ein Anbieterdienst passt. - Die eingesetzte Hauptversion läuft bald aus dem Support. - Das Wissen über die Datenbank liegt bei einer einzelnen Person. Einstieg: Health-Check ## Zwölf Prüfpunkte, an denen wir eine PostgreSQL-Umgebung messen Der Health-Check ist der Einstieg der meisten Projekte. Er ist ein Katalog konkreter Prüfpunkte mit Prüfmethode; das Ergebnis ist eine priorisierte Befundliste, keine Pauschalbewertung. __PostgreSQL-Health-Check: Prüfpunkt, Prüfmethode und typische Auffälligkeit__ | Prüfpunkt | Womit prüfen | Auffälligkeit | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Version und Support | Servereinstellung server\_version, Abgleich mit der [Supportübersicht](https://www.postgresql.org/support/versioning/) | Hauptversion nahe am Supportende oder bereits ohne Support; veralteter Minor-Stand | | Teure Abfragen | Erweiterung [pg\_stat\_statements](https://www.postgresql.org/docs/current/pgstatstatements.html): Aufrufe, Gesamtlaufzeit, Zeilenzahl je Abfrage | Wenige Abfragen verursachen den Großteil der Laufzeit; Abfragen ohne passenden Index | | Verbindungen | Anzahl aktiver und wartender Verbindungen, Verbindungsmodell der Anwendung | Viele kurzlebige Verbindungen ohne Pooler; Verbindungsgrenze nahe erreicht | | Backup und Wiederherstellung | Letzter erfolgreicher Restore-Test, WAL-Archivierung aktiv | Backup nie wiederhergestellt; Archivierung fehlerhaft; keine Point-in-Time-Recovery | | Replikation | Replikationsverzug, Zustand der Standbys | Standby fehlt oder liegt zurück; Failover nie getestet | | Replikationsslots | Von Slots zurückgehaltene WAL-Menge | Verwaister Slot lässt WAL anwachsen, bis der Datenträger voll ist (laut [Dokumentation](https://www.postgresql.org/docs/current/warm-standby.html) begrenzbar mit max\_slot\_wal\_keep\_size) | | Speicher und Wachstum | Datenträgerfüllstand, Wachstum der größten Tabellen und des WAL | Füllstand steigt ohne Prognose | | Wartung | Vacuum-Aktivität und Aufblähung großer Tabellen | Tabellen mit stark wachsendem toten Anteil | | Rechte und Zugriff | Rollen, Rechte, Authentifizierungsregeln, Verbindungsverschlüsselung | Gemeinsame Superuser-Konten; Anwendungen mit Administratorrechten; unverschlüsselte Verbindungen | | Konfiguration | Abweichungen von Standardwerten und Begründung | Parameter ungeprüft aus einer Anleitung übernommen | | Monitoring | Welche Metriken erfasst werden, wer alarmiert wird | Ausfall würde zuerst von Anwendern bemerkt | | Wissen und Betrieb | Runbooks, Zuständigkeiten, Zugriff im Notfall | Kenntnisse bei einer Person; keine dokumentierte Wiederherstellung | Für die Abfrageanalyse muss pg\_stat\_statements laut Dokumentation in `shared_preload_libraries` geladen sein, was einen Neustart erfordert. Abfrageanalyse ## Erst die Abfragestatistik, dann der Hebel Fehlt pg\_stat\_statements, planen wir es als erste Änderung ein. Mit gemessenen Laufzeiten entscheiden wir danach, ob Index, Parameter, Verbindungsmodell oder die Anwendungsabfrage selbst der richtige Hebel ist. Dazu gehören drei Arbeitsfelder: - **Architektur:** Topologie, Versionsstrategie, Trennung von Datenbanken und Schemata, Verbindungsmodell, Erweiterungen, Kapazität. - **Performance:** Analyse der Abfragen und Konfiguration, Index- und Parameterempfehlungen, Maßnahmen gegen Sperren und Verbindungsprobleme. - **Sicherheit:** Rollen- und Rechtekonzept, verschlüsselte Verbindungen, Absicherung der Konfiguration, Zugriffsprotokolle. ![Laptop im Dunkeln mit Quellcode in einem Editor auf dem Bildschirm](/_astro/laptop-quellcode-editor-bildschirm.37PukO5C_7dKp5.jpg) Replikation ## Asynchron oder synchron: was Sie gegen was tauschen Hochverfügbarkeit ist keine einzelne Einstellung, sondern eine Abwägung zwischen möglichem Datenverlust und Verfügbarkeit. Die [PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/warm-standby.html) beschreibt sie für Streaming-Replikation so: Asynchron kann bei Ausfall des Primary ein Teil bereits bestätigter Transaktionen auf dem Standby fehlen, der Verlust entspricht dem Replikationsverzug zum Zeitpunkt des Ausfalls. Synchron geht Daten nur verloren, wenn Primary und Standby gleichzeitig ausfallen; dafür warten Commits auf die Bestätigung des Standbys und können blockieren, wenn ein synchroner Standby ausfällt. __Entscheidungsmatrix asynchrone und synchrone Replikation__ | Kriterium | Asynchrone Replikation | Synchrone Replikation | | ---------------------------------- | -------------------------------------------------------------------------- | --------------------------------------------------------------------- | | Datenverlust bei Primary-Ausfall | möglich, abhängig vom Verzug | nur bei gleichzeitigem Ausfall mehrerer Knoten | | Einfluss auf Commit-Latenz | gering | höher, Netzwerkabstand zählt | | Verhalten bei Ausfall des Standbys | Primary arbeitet weiter | Commits können warten, abhängig von der Konfiguration | | Geeignet für | Anwendungen, die einen kleinen Datenverlust verkraften; große Entfernungen | Daten, deren Verlust nicht akzeptabel ist; Knoten mit geringer Latenz | Entscheidungsreihenfolge ## Vom Wiederherstellungsziel zum Werkzeug Daraus folgt die Reihenfolge unseres Vorgehens bei der Hochverfügbarkeit: Ohne Ziel keine begründbare Architektur. 1. 01 ### Wiederherstellungsziel festlegen Fachbereich Wie viel Datenverlust ist für Ihren Fachbereich tragbar, wie lange darf der Ausfall dauern? 2. 02 ### Replikationsmodus wählen Abwägung Asynchron oder synchron, nach der Matrix oben. 3. 03 ### Knotenzahl und Verteilung bestimmen Topologie Wie viele Knoten, wo, mit welcher Latenz zueinander. 4. 04 ### Werkzeug wählen Patroni oder CloudNativePG Ein verteilter Konsensspeicher wie etcd entscheidet bei Patroni, welcher Knoten Primary ist; Patroni unterstützt laut [Dokumentation](https://patroni.readthedocs.io/en/latest/) neben etcd auch Consul, ZooKeeper und Kubernetes und bietet synchrone sowie Quorum-Modi. Auf Kubernetes übernimmt [CloudNativePG](https://cloudnative-pg.io/docs/current/) die deklarative Verwaltung des Clusters. Grenze der Replikation ## Replikation ersetzt kein Backup Ein Datenfehler wird mitrepliziert. Backup mit pgBackRest und Point-in-Time-Recovery sind ein eigener Baustein, den wir getrennt entwerfen und per Restore-Test nachweisen. Verbindungsschicht ## PgBouncer: wann der Transaction-Modus Ihre Anwendung trifft PgBouncer bündelt Verbindungen. Im Transaction-Modus wird eine Serververbindung nur für die Dauer einer Transaktion zugewiesen; laut [Dokumentation](https://www.pgbouncer.org/features.html) funktionieren dann einige sitzungsbezogene Funktionen nicht, darunter SET/RESET, LISTEN und Session-Level-Advisory-Locks. Ob Ihre Anwendung diese nutzt, prüfen wir vor der Einführung. ![Türkise und gelbe Glasfaser-Patchkabel in einem Patchfeld im dunklen Serverraum](/_astro/glasfaser-patchfeld.C6TC5KFX_1MRDvu.jpg) Projektablauf ## Von der Befundliste bis zur Übergabe 1. 01 ### Bestandsaufnahme und Health-Check Ergebnis: Befundliste Nach dem Katalog, mit Befundliste und Priorisierung. 2. 02 ### Zielarchitektur Ergebnis: Zielbild Mit Wiederherstellungszielen, Topologie und Begründung der Werkzeugwahl. 3. 03 ### Umsetzung in kleinen Schritten Abnehmbar, jeweils mit Rückfallplan. 4. 04 ### Nachweis Ergebnis: Testprotokolle Failover-Test, Restore-Test, Lasttest für die kritischen Abfragen. 5. 05 ### Übergabe Mit Runbooks an Ihr Team oder Übernahme in den [Managed-Betrieb](/managed-services/managed-postgresql/). Lieferumfang ## Fünf Unterlagen, die nach dem PostgreSQL-Projekt bei Ihnen liegen - ### Health-Check-Bericht Priorisierte Befunde nach dem Katalog. - ### Zielarchitektur Mit Wiederherstellungszielen. - ### Konfiguration als Code Umgesetzt und versioniert. - ### Testprotokolle Failover- und Restore-Tests. - ### Runbooks Für Ihr Team oder den Betrieb. Plattform und Zugriff ## Zugriff und Plattform: auf Ihrer Umgebung, nicht daneben Zugriff erfolgt über personalisierte, befristete Zugänge, Änderungen als Code mit Review, Datenübertragung verschlüsselt. Wir arbeiten auf Ihrer Plattform: STACKIT, AWS, Azure, GCP oder eigene Infrastruktur wie [Proxmox](/infrastruktur/proxmox/). Weitere Absicherung: [Cloud Security](/cybersecurity/cloud-security/). Wie ein Angebot entsteht Aufwand bestimmen Zahl und Größe der Datenbanken, Komplexität der Anwendungen, Hochverfügbarkeits- und Wiederherstellungsziele, die Plattform (VM oder Kubernetes) und ob Beratung allein oder Umsetzung und Betrieb gewünscht sind. Wir starten mit einem Health-Check; sein Ergebnis bestimmt Umfang und Preis des Angebots. Passung ## Für welche PostgreSQL-Vorhaben wir die richtige Adresse sind ### Das passt - PostgreSQL ist Ihre Datenbank und Sie wollen Zustand, Risiken und Zielarchitektur belegt bekommen. - Sie sind bereit, Wiederherstellungsziele mit dem Fachbereich zu definieren. ### Das passt nicht - Ihre Datenbank ist nicht PostgreSQL. - Sie suchen Anwendungsentwicklung oder die Neugestaltung Ihres Datenmodells ohne Beteiligung des Anwendungsteams: Schema und Anwendungsabfragen verantwortet Ihr Team, wir beraten dazu. - Sie wollen eine Hochverfügbarkeitszusage, ohne Wiederherstellungsziele zu definieren: Ohne dieses Ziel ist keine Architektur begründbar. ## Häufige Fragen Wie läuft der Einstieg ab? Wir starten mit einem Health-Check nach dem Katalog. Sie erhalten eine priorisierte Befundliste, bevor irgendetwas geändert wird. Brauchen Sie Zugriff auf die Produktion? Nein, nicht für die Analyse: Dafür genügt Lesezugriff auf Statistik- und Konfigurationsdaten. Schreibende Eingriffe sprechen wir mit Ihnen ab und führen sie erst nach Ihrer Freigabe aus. Ersetzt Replikation das Backup? Nein. Ein Datenfehler wird mitrepliziert. Backup und Point-in-Time-Recovery sind ein eigener Baustein. Betreiben Sie die Datenbank auch dauerhaft? Beratung und Betrieb sind getrennte Leistungen. Den Betrieb beschreibt [Managed PostgreSQL](/managed-services/managed-postgresql/). Health-Check starten ## Beschreiben Sie Version, Umgebung und Ihr Problem Mit diesen drei Angaben können wir einschätzen, ob ein Health-Check der richtige Einstieg ist. Weitere Themen: [Data Engineering](/daten/data-engineering/), Übersicht [Daten](/daten/). [Projekt anfragen](/projekt-anfragen/)