/ Artikel

Predefined Roles

PostgreSQL stellt eine Reihe vorgefertigter Rollen bereit: pg_read_all_data, pg_write_all_data, pg_monitor, pg_signal_backend und mehr. Damit lassen sich häufige Aufgaben (Read-Only, Monitoring, Backup) ohne Boilerplate lösen.

PostgreSQL bringt seit Version 14 eine wachsende Sammlung vorgefertigter Rollen mit, an die man User per GRANT hängen kann — ohne lange GRANT SELECT ON ALL TABLES IN SCHEMA …-Listen. Sie decken die häufigsten administrativen Bedürfnisse ab und sparen viel Boilerplate. Dieser Artikel listet sie und zeigt, wofür man welche braucht.

01 · Abschnitt

Übersicht aller Predefined Roles

Rolle	Erlaubt
`pg_read_all_data`	Lesezugriff auf alle Daten in allen Schemas der Datenbank (auch System-Tabellen, soweit normal lesbar)
`pg_write_all_data`	Schreibzugriff (INSERT/UPDATE/DELETE) auf alle Daten — ohne SELECT!
`pg_read_all_settings`	Liest auch sonst eingeschränkte Konfigurations-Parameter (z. B. solche mit `GUC_SUPERUSER_ONLY`)
`pg_read_all_stats`	Vollzugriff auf `pg_stat_*`-Views (auch Statistiken, die normal nur Eigentümer sehen)
`pg_stat_scan_tables`	Darf `pg_stat_user_tables` in vollem Umfang scannen, inkl. Funktionen, die ACCESS-SHARE-Locks setzen
`pg_monitor`	Sammel-Rolle: Mitglied von `pg_read_all_settings`, `pg_read_all_stats`, `pg_stat_scan_tables`
`pg_signal_backend`	Darf andere Sessions signalisieren (`pg_cancel_backend`, `pg_terminate_backend`) — ohne Superuser zu sein
`pg_read_server_files`	Darf Dateien vom Server-Filesystem lesen (z. B. via `COPY FROM '/path/...'`)
`pg_write_server_files`	Darf Dateien aufs Server-Filesystem schreiben (z. B. `COPY TO '/path/...'`)
`pg_execute_server_program`	Darf via `COPY … FROM PROGRAM …` Server-Programme ausführen
`pg_checkpoint` (ab PG 15)	Darf manuell `CHECKPOINT;` ausführen, ohne Superuser zu sein
`pg_database_owner` (ab PG 14)	Stellvertreter für „der jeweilige Datenbank-Owner” — wirkt in Default-Privileges-Konstrukten
`pg_use_reserved_connections` (ab PG 16)	Darf reservierte Connections (`reserved_connections`) belegen
`pg_create_subscription` (ab PG 16)	Darf logische Replikations-Subscriptions anlegen, ohne Superuser zu sein
`pg_maintain` (ab PG 17)	Darf Wartungsoperationen (`VACUUM`, `ANALYZE`, `REINDEX`, `REFRESH MATERIALIZED VIEW`) auf alle Objekte ausführen

02 · Abschnitt

Verwendung

Predefined Roles sind ganz normale Rollen — du machst User per GRANT zum Mitglied:

SQL Read-Only-User in einer Zeile

CREATE ROLE reader WITH LOGIN PASSWORD 'changeme';
GRANT pg_read_all_data TO reader;

Damit darf reader jede Tabelle in jedem Schema lesen — ohne dass man durch alle Schemas iterieren und GRANT SELECT setzen muss. Auch ALTER DEFAULT PRIVILEGES ist nicht nötig: pg_read_all_data umfasst per Definition alles, was später dazukommt.

03 · Abschnitt

Typische Patterns

Read-Only-Reporting-User

SQL

CREATE ROLE reporting LOGIN PASSWORD 'changeme'
    CONNECTION LIMIT 5;
GRANT pg_read_all_data TO reporting;

Ein User für BI-Tools oder Ad-hoc-Reporting. CONNECTION LIMIT schützt davor, dass eine schief laufende Auswertung den ganzen Pool blockiert.

Backup-User

SQL

CREATE ROLE backup_user LOGIN PASSWORD 'changeme'
    REPLICATION;
GRANT pg_read_all_data TO backup_user;

Damit kann der User pg_dump (braucht SELECT auf alles) und Streaming-Replikation für pg_basebackup. Kein Superuser.

Monitoring

SQL

CREATE ROLE monitor LOGIN PASSWORD 'changeme'
    CONNECTION LIMIT 3;
GRANT pg_monitor TO monitor;

pg_monitor ist ideal für Tools wie pgwatch, datadog-agent, Prometheus-Exporter. Erlaubt Vollzugriff auf alle relevanten pg_stat_*-Views, ohne dass das Tool Daten lesen oder Konfiguration ändern kann.

Eingeschränkte Admin-Aktionen

SQL

GRANT pg_signal_backend  TO oncall;     -- darf Sessions cancel'n
GRANT pg_checkpoint      TO oncall;     -- darf CHECKPOINT triggern
GRANT pg_maintain        TO oncall;     -- darf VACUUM/ANALYZE/REINDEX

Praktisch für Oncall-Rollen, die im Notfall Operationen ausführen sollen, ohne dass jemand Superuser-Rechte verteilt.

04 · Abschnitt

pg_database_owner — der Stellvertreter

pg_database_owner ist eine besondere Pseudo-Rolle: sie repräsentiert den jeweiligen Owner einer Datenbank, ohne dass man weiß, wer das gerade ist. Hauptanwendung: in Default-Privileges-Setups oder bei Templates.

SQL

ALTER DEFAULT PRIVILEGES IN SCHEMA public
    GRANT ALL ON TABLES TO pg_database_owner;

Vorteil: das Setup funktioniert auch in geclonten/gerenamten Datenbanken, wo der Owner ein anderer sein könnte.

05 · Abschnitt

Was Predefined Roles NICHT tun

Wichtig zur Abgrenzung:

Sie ersetzen keinen Superuser. Auch pg_read_all_data darf keine Tabellen droppen oder Konfiguration ändern.
Sie umgehen keine Authentifizierung. Wer sich nicht via pg_hba.conf verbinden darf, kommt auch mit pg_read_all_data nicht rein.
Sie greifen nicht auf Cluster-Ebene. pg_read_all_data wirkt pro Datenbank — nicht über alle Datenbanken im Cluster hinweg.

In der Praxis bedeutet das: für den klassischen Backup-User reicht pg_read_all_data plus REPLICATION; aber wer Cluster-weit lesen will, muss in jeder Datenbank die Mitgliedschaft separat einrichten oder mit pg_dumpall arbeiten.

06 · Abschnitt

Interessantes

pg_write_all_data ist seltener nuetzlich, als es klingt.

Schreibrechte ohne Leserechte sind ein ungewöhnlicher Use Case — die meisten Anwendungen wollen RW. Wer wirklich nur reines Insert (z. B. Audit-Logger) baut, kann das mit dieser Rolle modellieren. Ansonsten lieber explizit per GRANT INSERT, UPDATE, DELETE.

pg_monitor ist der Default fuer alle Monitoring-Tools.

Datadog, New Relic, Prometheus-Postgres-Exporter, pganalyze — alle dokumentieren pg_monitor als bevorzugte Rolle. Wer ein Monitoring-Setup neu macht, sollte erst pg_monitor versuchen, bevor er einzelne pg_stat_*-Privilegien grantet.

In Cloud-Postgres sind manche Rollen nicht direkt vergebbar.

Auf RDS und Cloud SQL sind Rollen wie pg_read_server_files, pg_write_server_files und pg_execute_server_program deaktiviert oder nur über die Cloud-Admin-Rolle erreichbar — der Anbieter hat keine Lust, dir Filesystem-Zugriff zu geben. Im Anbieter-Doku nachschlagen, was wirklich verfügbar ist.

Mitgliedschaft kann transitiv vergeben werden.

Wenn du eine Gruppe analysts machst und GRANT pg_read_all_data TO analysts; setzt, erben alle Mitglieder von analysts automatisch die Lese-Rechte. Das ist sauberer, als jedem User einzeln die Rolle zu geben.

pg_maintain ist neu in PG 17 — vorher war VACUUM-Delegation knifflig.

Bis PG 16 musste man entweder Owner sein oder Superuser, um eine Tabelle zu vacuumen. Routine-Wartung außerhalb von Autovacuum war damit ein Sonderfall. Seit PG 17 reicht GRANT pg_maintain TO maintenance_user; für eine dedizierte Wartungs-Rolle.

07 · Abschnitt

Weiterführende Ressourcen

Externe Quellen

/ Weiter

Zurück zu Server-Administration

Zur Übersicht