PostgreSQL hat sich durchgesetzt. Vor sechs Jahren konnte man noch ernsthafte Unternehmen finden, die MySQL, MS SQL oder Oracle als primäre OLTP-Datenbank betrieben. 2026 ist die Standardantwort für nahezu jedes neue System – managed, selbst gehostet oder in einen Serverless-Stack eingebettet – Postgres.
Diese Allgegenwart hat ein Problem geschaffen, das die meisten Teams noch nicht verinnerlicht haben: Sie überwachen Postgres immer noch wie jede andere Datenbank. Connection-Counts. CPU. Festplatte. Dasselbe Dashboard wie 2019, nur mit anderem Logo.
Dann bricht etwas um 3 Uhr morgens. Autovacuum bleibt auf einer stark beanspruchten Tabelle stehen. Eine lang laufende Transaktion blockiert zwanzig Minuten lang jeden Schreibvorgang. Das Transaction-ID-Alter klettert über 1,8 Milliarden, und Postgres lehnt neue Schreibvorgänge ab, bis ein Notfall-Vacuum durchgelaufen ist. Nichts davon erscheint in einem generischen Datenbank-Dashboard. Alles davon ist sichtbar – wenn Sie wissen, welche Postgres-spezifischen Metriken Sie beobachten müssen.
Genau das bedeutet PostgreSQL-Monitoring im Jahr 2026.
Was PostgreSQL-Monitoring ist – und was die meisten Teams falsch machen
PostgreSQL-Monitoring ist die Praxis, den Laufzeitzustand einer Postgres-Instanz zu beobachten: die ausgeführten Queries, die verbrauchten Ressourcen, die Replikationstopologie, in die sie eingebettet ist, und die internen Wartungsprozesse – Autovacuum, WAL-Flushing, Statistik-Erfassung – die sie stabil halten.
Richtig gemacht, fängt es Probleme Stunden oder Tage ab, bevor Nutzer etwas merken. Als Nachgedanke betrieben – an ein generisches Infrastruktur-Dashboard angeflanscht – fängt es kaum etwas Postgres-spezifisches ab, bis die Produktion bereits brennt.
Der Fehler, den die meisten Teams machen, ist, Postgres als Black Box zu behandeln: CPU, Speicher, Festplatte und Uptime überwachen – und davon ausgehen, dass alles Interne in einer dieser vier Größen sichtbar wird. Das wird es nicht. Postgres ist ein System mit eigenständigen Eigenheiten, die in MySQL oder generischen „Datenbank-Health"-Dashboards keine Entsprechung haben: MVCC, Autovacuum, das WAL, die Lebensdauer von Transaktions-IDs und die Art, wie sich Locks über abhängige Transaktionen fortpflanzen.
Wenn Ihr Monitoring diese Sprache nicht spricht, werden Sie sich wundern – und die Überraschungen kommen fast immer um 3 Uhr morgens.
Die fünf Postgres-spezifischen Failure Modes, auf die sich ein Alarm lohnt
Diese Fälle reißen die Produktion runter. Generisches Infrastruktur-Monitoring sieht keinen davon.
1. Autovacuum und Tabellen-Bloat
Postgres nutzt MVCC: Wenn Sie ein UPDATE oder DELETE auf einer Zeile ausführen, bleibt die alte Version auf der Festplatte, bis Autovacuum sie aufräumt. Das ist so gewollt – so liefert Postgres Snapshot-Isolation, ohne Leser zu blockieren.
Der Haken: Wenn Autovacuum mit der Änderungsrate nicht mithält, sammeln sich Dead Tuples an. Tabellen und Indizes wachsen unkontrolliert. Die Statistiken des Planers veralten. Sequential Scans werden langsamer, weil mehr Pages für dieselbe Anzahl an Live-Zeilen gelesen werden müssen. Die I/O steigt. p99-Latenzen kriechen nach oben – langsam genug, dass kein Alarm anschlägt, schnell genug, um ein Quartal zu ruinieren.
Was Sie überwachen sollten:
pg_stat_user_tables.n_dead_tupund das Verhältnis zun_live_tup, pro Tabellelast_autovacuum- undlast_autoanalyze-Zeitstempel- Aktive Autovacuum-Worker im Verhältnis zu
autovacuum_max_workers - Index-Bloat – über
pgstattupleoder Community-Queries
Das typische Symptom sind „Queries, die über Monate hinweg ohne Code-Änderung langsamer geworden sind". Wenn Ihr Dashboard die Frage „Welche Tabellen wurden in der letzten Woche nicht autovacuumed?" nicht beantworten kann, können Sie das Problem nicht erkennen.
Tunen Sie autovacuum_vacuum_scale_factor pro Tabelle für Tabellen mit hoher Änderungsrate – der Standardwert von 0.2 (20 % Dead Tuples) ist für Tabellen mit Hunderten Millionen Zeilen zu lasch.
2. WAL und Replication Lag
Streaming-Replikation überträgt Write-Ahead-Log-Records vom Primary zu den Replicas. Zwei Dinge gehen schief, wenn Sie das nicht beobachten: Read Replicas liefern veraltete Daten, und Ihr RPO bei einem Failover beträgt genau so viel Lag, wie zum Zeitpunkt des Primary-Ausfalls bestand.
Was Sie überwachen sollten:
pg_stat_replication.write_lag,flush_lag,replay_lagpro Replica- LSN-Diff zwischen Primary und jeder Replica:
pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) - WAL-Erzeugungsrate (Bytes pro Sekunde) auf dem Primary
- Fehlerzähler von
archive_command, falls Sie WAL-Archiving für PITR nutzen
Ein häufiger stiller Ausfall: archive_command fängt an zu scheitern – S3-Credentials wurden rotiert, das Archive-Ziel hat keinen Plattenplatz mehr –, niemand bemerkt es, das WAL stapelt sich auf dem Primary, und Ihr Point-in-Time-Recovery-Fenster ist defekt, obwohl die Replikation noch gesund aussieht.
Replication Lag sollte in Sekunden alarmieren, nicht in Minuten. Sobald Sie minutenlangen Lag sehen, liefert die Anwendung bereits veraltete Reads, oder Ihr Failover-RPO ist bereits kompromittiert. Der „Wir merken es schon, wenn es wichtig wird"-Ansatz beim Lag ist genau die Art, wie Sie erfahren, dass es gestern wichtig gewesen wäre.
3. Transaction-ID-Wraparound
Jede Transaktion in Postgres erhält eine 32-Bit-Transaktions-ID. Das ergibt rund vier Milliarden, bevor der Zähler überläuft. Um Korruption zu verhindern, vacuumed Postgres alte Daten aggressiv, um XIDs mit zunehmendem Alter zu „freezen". Wenn Freeze-Vacuum nicht hinterherkommt und die älteste XID sich dem Wraparound-Horizont nähert, geht Postgres in den Notfall-Vacuum-Modus – und am Limit lehnt es neue Schreib-Transaktionen vollständig ab, bis Vacuum aufgeholt hat.
Das ist der Failure Mode, der eine Site stundenlang lahmlegt. Und er ist vollständig vermeidbar.
Was Sie überwachen sollten:
age(datfrozenxid)für jede Datenbankage(relfrozenxid)speziell für schreiblastige Tabellen- Warning bei 1 Milliarde, Critical bei 1,5 Milliarden – reichlich Vorlauf zum Handeln, aber nur, wenn Sie hinschauen
Die Teams, die der Wraparound erwischt, sind meist nicht die mit den höchsten Schreibraten. Es sind die mit ein oder zwei schreiblastigen Tabellen, die Autovacuum immer wieder überspringt – oft, weil eine lang laufende Transaktion das Freeze blockiert. Das Dashboard sieht in Ordnung aus. Dann nimmt die Datenbank keine Schreibvorgänge mehr an.
Wenn Sie 2026 nur einen Postgres-spezifischen Alarm einrichten, dann diesen.
4. Lock-Chains und blockierte Queries
Eine einzelne lang laufende Transaktion, die einen Row- oder Tabellen-Lock hält, kann jede abhängige Query blockieren. Die Anwendung sieht Timeouts. Das Dashboard sieht „alles ist langsam" bei normaler CPU und normalem Speicher. Standard-Infrastruktur-Monitoring ist hier nutzlos.
Was Sie überwachen sollten:
pg_stat_activitygefiltert aufstate = 'idle in transaction'mit Dauer über fünf Minuten- Blockierte Queries via
pg_blocking_pids()zusammen mitpg_stat_activity - Anzahl von
wait_event_type = 'Lock'über die Zeit - Deadlock-Anzahl aus
pg_stat_database.deadlocks
Idle-in-Transaction-Sessions sind der übliche Verursacher. Sie kommen fast immer von Anwendungsfehlern: Eine Connection eröffnet eine Transaktion und wartet dann auf etwas Externes – einen HTTP-Call, eine Queue, einen Menschen in einem UI – ohne zu committen oder zurückzurollen. Solange sie idle ist, werden ihre Locks nicht freigegeben.
Alarmieren Sie auf jede Idle-in-Transaction-Session, die länger als fünf Minuten dauert. Ihre Anwendung hat keinen legitimen Grund, eine Transaktion so lange offen zu halten – die Alternative ist, davon zu erfahren, wenn die Produktion ins Stocken gerät.
5. Buffer-Cache-Hit-Ratio – mit Vorbehalten
In vielen älteren Postgres-Ratschlägen heißt es: „Strebe eine Buffer-Cache-Hit-Ratio von 99 % an". 2026 ist diese Faustregel irreführend.
Die Buffer-Cache-Hit-Ratio – blks_hit / (blks_hit + blks_read) aus pg_stat_database – sagt Ihnen, welcher Anteil der Block-Reads aus shared_buffers bedient wurde, statt in den OS-Page-Cache oder auf die Festplatte zu gehen. Mit NVMe-Storage und Maschinen mit Hunderten Gigabyte RAM sind „Disk"-Reads ohnehin häufig OS-Page-Cache-Hits – schnell genug, dass eine Buffer-Cache-Hit-Ratio von 95 % völlig in Ordnung ist und ein 99-%-Ziel nur eine Ausrede dafür, shared_buffers zu groß zu dimensionieren.
Was Sie überwachen sollten:
- Buffer-Cache-Hit-Ratio als Trend über die Zeit, nicht als statisches SLA
- Plötzliche Einbrüche, die meist auf eine Working-Set-Änderung oder eine Query-Plan-Regression hinweisen
- Kombiniert mit Checkpoint-Frequenz und
bgwriter-Statistiken, um zu erkennen, ob Sie unterdimensioniert sind
Nutzen Sie sie, um Veränderungen zu erkennen. Setzen Sie sie nicht als absoluten Zielwert.
Die langweiligen Metriken zählen weiterhin
Die Postgres-spezifischen Failure Modes kommen zu den klassischen Infrastruktur-Metriken hinzu, nicht an deren Stelle. Sie brauchen weiterhin:
- Connection-Count – gesamt, idle, aktiv und das Verhältnis zu
max_connections. Erschöpfung des Connection-Pools ist einer der häufigsten Produktions-Vorfälle. - Slow Queries – über
pg_stat_statements. Tracken Siemean_exec_time,total_exec_timeund Call-Counts für die Top-N-Queries. - Host-Metriken – CPU, Speicher, Disk-I/O, Festplattenplatz und speziell freier Platz auf dem WAL-Volume.
- Deadlocks pro Minute – eine ungleich-null Rate, die im Zeitverlauf wächst, ist ein Code-Problem, das behoben werden sollte, bevor es kaskadiert.
Lassen Sie diese aus, fangen Sie die exotischen Ausfälle ab, übersehen aber die offensichtlichen.
Tools, denen Sie in der Praxis begegnen
| Tool | Am besten für | Trade-off |
|---|---|---|
pg_stat_statements |
Grundlage für Query-Level-Metriken | Eingebaut. Aktivieren Sie es ab Tag eins. |
| pgBadger | Periodische Tiefenanalysen von Postgres-Logs | Kostenlos, aber Offline-Reports – kein Live-Monitoring. |
| pganalyze | Tiefes, Postgres-spezifisches SaaS | Best-in-Class für Postgres; teurer pro Instanz. |
| Datadog DBM | Postgres neben dem Rest Ihres Datadog-Stacks | Weniger Postgres-tief als pganalyze; bei Skalierung teuer. |
Prometheus + postgres_exporter |
Teams, die bereits Prometheus betreiben | Open Source. Erfordert Aufbau und Dashboard-Arbeit. |
| Xitoring | Postgres neben Servern, Uptime, SSL und Synthetics | All-in-One-Plattform; ideal, wenn Postgres ein Teil eines breiteren Bildes ist. |
Die richtige Wahl hängt weniger an der Feature-Liste als an dem, was Sie sonst noch überwachen. Wenn Postgres das einzige System ist, das Sie wirklich interessiert, und Sie eine oder zwei Produktionsdatenbanken haben, ist pganalyze schwer zu schlagen. Wenn Sie vierzig Server, zehn Datenbanken, öffentliche Endpunkte und Zertifikatsablauf überwachen, ist eine integrierte Plattform, die den Rest bereits abdeckt, meist besser als ein zusätzliches Postgres-Spezialtool obendrauf.
So richten Sie Postgres-Monitoring ein, ohne es zu überfrachten
Eine pragmatische Baseline für 2026:
pg_stat_statementsauf jeder Postgres-Instanz aktivieren. Kostenlos, geringer Overhead, Grundlage fast jeder weiteren Prüfung.- Auf Transaction-ID-Alter alarmieren. Warning bei 1 Milliarde, Critical bei 1,5 Milliarden. Dieser eine Alarm verhindert den schlimmsten Postgres-Ausfall.
- Autovacuum-Aktivität pro Tabelle tracken, nicht nur „läuft er global". Tunen Sie Scale Factors für Tabellen mit hoher Änderungsrate.
- Auf Replication Lag in Sekunden alarmieren, nicht in Minuten. Tracken Sie alle drei Lag-Spalten – write, flush, replay – sie scheitern unterschiedlich.
- Auf Idle-in-Transaction-Sessions über fünf Minuten alarmieren. Fast immer ein Anwendungsfehler, der behoben werden sollte.
- Nicht auf absolute Buffer-Cache-Hit-Ratio alarmieren. Alarmieren Sie auf plötzliche Einbrüche.
- Erfolg von
archive_commandüberwachen, falls Sie WAL-Archiving für Backups nutzen. Stilles Versagen hier zerstört PITR. - p99-Query-Latenz aus
pg_stat_statementstracken, nicht den Durchschnitt. Durchschnitte verbergen die Queries, die Nutzer wirklich treffen.
Das ist eine vertretbare Baseline. Sie können immer mehr hinzufügen – Sie sollten nie weniger haben.
Postgres hat gewonnen. Überwachen Sie es entsprechend.
Die Failure Modes, die Postgres niederreißen – Autovacuum-Hunger, Transaction-ID-Wraparound, Lock-Chains, Archive-Fehler – sind vorhersehbar, beobachtbar und vollständig sichtbar, wenn Ihr Monitoring Postgres spricht. Für ein generisches Datenbank-Dashboard sind sie unsichtbar.
Wählen Sie einen Stack, der die Postgres-spezifischen Signale sichtbar macht, alarmieren Sie auf die obigen Metriken – und Sie verbringen deutlich weniger Sonntagnachmittage damit, herauszufinden, warum die Produktion keine Schreibvorgänge mehr annimmt.
Wenn Sie Ihre Postgres-Instanzen lieber gemeinsam mit Ihren Servern, öffentlichen Endpunkten und SSL-Zertifikaten an einem Ort überwachen wollen – statt vier Tools zusammenzustückeln – ist Xitoring genau dafür gebaut. Kostenlos starten und Ihren ersten Alarm in wenigen Minuten sehen.