PostgreSQL MCP: Lesezugriff einrichten und prüfen
PostgreSQL per MCP lesen: Rolle, Schema, Rechte und Abfragelimits prüfen. Mit Checkliste für einen begrenzten Datenbankzugriff und typische Fehler.
Noch unsicher beim Zugangsweg? Der Datenbank-Assistent erstellt einen Prüfplan; der Datenbankvergleich ordnet Datei, Rolle und Projekt ein.
Ein PostgreSQL-MCP-Server verbindet einen Client mit Datenbankfunktionen. Ob der Zugriff tatsächlich lesend bleibt, hängt von den Rechten und der konkreten Implementierung ab. „Read-only“ im Namen ist keine ausreichende Prüfung. Beginnen Sie mit einer Testdatenbank oder einem ausdrücklich freigegebenen Ausschnitt. Legen Sie vorher fest, welche Tabellen, Spalten und Ergebnismengen die Aufgabe benötigt.
Den passenden PostgreSQL-Zugang auswählen
Die PostgreSQL-Suche zeigt Registertreffer zu diesem Begriff. Prüfen Sie beim einzelnen Projekt, ob es freie SQL-Abfragen, vorgegebene Operationen oder nur Metadaten anbietet. Ein Schema lesen und beliebige Tabellendaten abfragen sind verschiedene Fähigkeiten. Vergleichen Sie Kandidaten über den Merkmalsvergleich und lesen Sie zusätzlich die Dokumentation der eingesetzten Fassung.
Notieren Sie, wo der MCP-Prozess läuft und wie er die Datenbank erreicht. Bei einem lokalen Prozess, einem Container und einem entfernten Dienst bedeutet „localhost“ jeweils etwas anderes. Eine funktionierende Verbindung aus Ihrem Terminal belegt nicht automatisch denselben Netzwerkweg aus der Serverumgebung. Halten Sie Zielhost, Datenbankname und Rolle fest, ohne das Passwort in den Prüfbericht zu übernehmen.
Rechte in der Datenbank begrenzen
PostgreSQL unterscheidet unter anderem Verbindungsrechte, Schema-Zugriff und Leserechte auf Tabellen. Eine eigens dafür vorgesehene Rolle sollte nur die für Ihre Aufgabe erforderlichen Rechte erhalten. Lassen Sie auch geerbte Rollen und bestehende Freigaben prüfen. Eine neue Rolle ist nicht allein deshalb eingeschränkt, weil sie einen passenden Namen trägt. Vermeiden Sie für diesen Zweck Eigentümer- oder Superuser-Zugänge.
| Ebene | Ihre Entscheidung | Zu prüfen |
|---|---|---|
| Datenbank | Freigegebenes Testziel | Verbindung zur richtigen Instanz |
| Schema | Benötigter Namensraum | Schema-Zugriff der Rolle |
| Daten | Tabellen oder begrenzte Views | Nur erforderliche Leserechte |
| Abfrage | Menge und Zeit begrenzen | Ergebnisumfang und Abbruch |
| Ausgabe | Benötigte Spalten | Keine unnötigen vertraulichen Felder |
Konfiguration und erste Abfrage
Öffnen Sie den Konfigurationsbaukasten für einen Eintrag mit deklarierter Startvorlage. Prüfen Sie die dort genannten Variablen gegen die Projektdokumentation.
Hinterlegen Sie den Datenbankzugang am vorgesehenen Ort. Teilen Sie keine vollständige Verbindungsadresse, wenn sie ein Passwort enthält.
Prüfen Sie mit der vorgesehenen Rolle eine kleine, bekannte Tabelle. Wählen Sie ausdrücklich die benötigten Spalten und begrenzen Sie die Ergebnismenge.
Vergleichen Sie das Ergebnis mit Ihrer Erwartung. Lassen Sie Rechte und einen kontrollierten Ablehnungsfall in einer Testumgebung prüfen, bevor Sie den Zugang für reguläre Aufgaben verwenden.
Read-only und Abfragelimits unterscheiden
Die PostgreSQL-Einstellung default_transaction_read_only legt den anfänglichen Lesemodus neuer Transaktionen fest. Sie ersetzt kein sorgfältig geprüftes Rollenkonzept. Auch ein lesender Zugriff kann vertrauliche Daten offenlegen oder eine aufwendige Abfrage ausführen. PostgreSQL dokumentiert außerdem statement_timeout für die Laufzeitbegrenzung von Anweisungen. Stimmen Sie einen passenden Wert mit dem Datenbankbetrieb ab, statt eine pauschale Einstellung für sämtliche Anwendungen zu übernehmen.
Ein SQL-LIMIT begrenzt die ausgegebene Zeilenzahl, beweist aber für sich allein keine günstige Ausführung. Prüfen Sie deshalb Ergebnismenge und Laufzeit getrennt. Für wiederkehrende Berichte sind klar definierte Views und bekannte Abfragen oft leichter nachzuvollziehen als ständig wechselnde freie Abfragen. Dokumentieren Sie, welche Daten für die Aufgabe absichtlich ausgeschlossen bleiben und wer eine spätere Erweiterung des Zugriffs verantwortet.
- Ist ein Server mit „read-only“ im Namen ausreichend begrenzt?
- Prüfen Sie die effektiven Datenbankrechte und das Verhalten der konkreten Implementierung. Der Name allein ist kein Nachweis.
- Warum scheitert SELECT trotz erfolgreicher Verbindung?
- Verbindung, Schema-Zugriff und Tabellenrechte sind getrennte Ebenen. Prüfen Sie auch das gewählte Schema und die tatsächlich verwendete Rolle.
- Kann ich Produktionszugänge zum ersten Test verwenden?
- Beginnen Sie mit einer dafür vorgesehenen Testumgebung oder einem ausdrücklich freigegebenen Ausschnitt und begrenzten Rechten.
- Was gehört in den Prüfbericht?
- Projektfassung, Zielumgebung, Rolle ohne Geheimnisse, abgefragter Datenbereich, erwartetes Ergebnis, tatsächlicher Befund und offene Grenzen.
Quellen geprüft am 1. Oktober 2026. Die Checklisten sind redaktionelle Vorschläge für Ihre eigene Umgebung.
- PostgreSQL 18: GRANT
Abrufbefehl anzeigen
curl -s https://www.postgresql.org/docs/18/sql-grant.html - PostgreSQL 18: client connection defaults
Abrufbefehl anzeigen
curl -s https://www.postgresql.org/docs/18/runtime-config-client.html