Postgres-MCP: SQL-Da­ten­ban­ken sicher als KI-Kontext anbinden

Mit einem Postgres-MCP-Server können Sie Post­greS­QL-Da­ten­ban­ken als struk­tu­rier­te Da­ten­quel­le für KI-An­wen­dun­gen verfügbar machen. Damit sensible Un­ter­neh­mens­da­ten geschützt bleiben, sollte der Zugriff kon­se­quent auf lesende Abfragen be­schränkt und über einen de­di­zier­ten Da­ten­bank­nut­zer ab­ge­si­chert werden.

Was ist ein Postgres-MCP-Server?

Ein Postgres-MCP-Server ist eine Schnitt­stel­le auf Basis des Model Context Protocol (MCP), die KI-Clients kon­trol­lier­ten Zugriff auf Post­greS­QL-Da­ten­ban­ken be­reit­stellt. Er stellt dafür Werkzeuge zum Lesen von Schema- und Ta­bel­len­da­ten sowie zum Ausführen frei­ge­ge­be­ner SQL-Abfragen bereit und über­mit­telt die Er­geb­nis­se struk­tu­riert an das Sprach­mo­dell zurück.

Über einen Postgres-MCP-Server kann eine KI bei­spiels­wei­se:

• Umsatz- und Ver­kaufs­da­ten abfragen,
• Bestände oder andere Kenn­zah­len auswerten,
• Tabellen und Da­ten­bank­struk­tu­ren un­ter­su­chen und
• aktuelle Daten aus Post­greS­QL als Kontext verwenden.

Die Daten müssen dafür nicht zuvor manuell in den Chat kopiert werden. Der MCP-Server fungiert als tech­ni­sche Brücke zwischen einem MCP-fähigen Client wie Claude Desktop, Cursor oder VS Code und der Post­greS­QL-Datenbank. Wichtig ist die genaue Auf­ga­ben­ver­tei­lung:

• Bei einem typischen MCP-Aufruf in­ter­pre­tiert das Sprach­mo­dell zunächst die Frage des Users und ent­schei­det, welches be­reit­ge­stell­te Tool benötigt wird.
• Bei einer Da­ten­bank­ab­fra­ge erzeugt das Modell bei­spiels­wei­se eine SQL-Anweisung und übergibt diese als Argument an das ent­spre­chen­de MCP-Tool. Der Postgres-MCP-Server führt die erlaubte Abfrage an­schlie­ßend gegen die Datenbank aus und gibt das Ergebnis an den Client zurück.

MCP selbst ist dabei keine Si­cher­heits- oder Da­ten­schutz­schicht. Welche Daten eine KI tat­säch­lich abrufen kann, hängt ins­be­son­de­re von den Post­greS­QL-Rechten des ver­wen­de­ten Da­ten­bank­kon­tos, den Funk­tio­nen des ein­ge­setz­ten MCP-Servers und den Frei­ga­be­re­geln des MCP-Clients ab.

Das Si­cher­heits­kon­zept: De­di­zier­ter Read-only-User

Eine KI sollte niemals mit einem Post­greS­QL-Superuser oder dem Ei­gen­tü­mer pro­duk­ti­ver Tabellen verbunden werden. Ein Post­greS­QL-Superuser kann praktisch sämtliche Be­rech­ti­gungs­prü­fun­gen umgehen. Erhält ein MCP-Server solche Zu­gangs­da­ten, hätte damit grund­sätz­lich auch ein feh­ler­haf­ter, ma­ni­pu­lier­ter oder un­er­war­te­ter Tool-Aufruf ent­spre­chend weit­rei­chen­de Mög­lich­kei­ten.

Statt­des­sen empfiehlt sich ein eigener Da­ten­bank­nut­zer nach dem Least-Privilege-Prinzip. Dieser erhält aus­schließ­lich Zugriff auf die Tabellen oder Views, die tat­säch­lich als KI-Kontext benötigt werden.

Read-only-User für Postgres-MCP anlegen

Post­greS­QL un­ter­schei­det bei­spiels­wei­se zwischen USAGE für ein Schema und SELECT für die darin ent­hal­te­nen Tabellen. Für den MCP-Zugriff lässt sich ein eigenes Nut­zer­kon­to mcp_reader anlegen:

CREATE USER mcp_reader
WITH PASSWORD '<STARKES_PASSWORT>'
NOSUPERUSER
NOCREATEDB
NOCREATEROLE
NOREPLICATION
NOBYPASSRLS;
GRANT CONNECT ON DATABASE sales_db TO mcp_reader;
GRANT USAGE ON SCHEMA reporting TO mcp_reader;
GRANT SELECT
ON reporting.monthly_sales, reporting.products
TO mcp_reader;

Der User mcp_reader darf sich damit an sales_db anmelden und die beiden aus­drück­lich frei­ge­ge­be­nen Objekte lesen. Rechte wie INSERT, UPDATE, DELETE, CREATE oder DROP werden nicht vergeben. Post­greS­QL erzwingt diese Be­rech­ti­gun­gen direkt auf Da­ten­ban­kebe­ne.

Zu­sätz­li­che Ein­stel­lun­gen für den Read-only-User

Ergänzend können Sie neue Trans­ak­tio­nen stan­dard­mä­ßig schreib­ge­schützt starten und die Laufzeit von Abfragen begrenzen:

ALTER ROLE mcp_reader SET default_transaction_read_only = on;
ALTER ROLE mcp_reader SET statement_timeout = '30s';

Diese Ein­stel­lun­gen schützen vor ver­se­hent­li­chen Schrei­b­ope­ra­tio­nen und vor zu lange laufenden Abfragen, stellen aber keine ei­gen­stän­di­ge Si­cher­heits­gren­ze dar. Ent­schei­dend bleiben die zuvor ver­ge­be­nen minimalen Post­greS­QL-Be­rech­ti­gun­gen.

Zugriff auf benötigte Daten begrenzen

Besonders sensible Daten sollten nach Mög­lich­keit nicht dadurch geschützt werden, dass das Sprach­mo­dell an­ge­wie­sen wird, bestimmte Spalten einfach nicht ab­zu­fra­gen. Sicherer ist es, nur geeignete Tabellen be­zie­hungs­wei­se speziell vor­be­rei­te­te Views frei­zu­ge­ben. So können Namen, E-Mail-Adressen oder andere ver­trau­li­che Felder bereits auf Da­ten­ban­kebe­ne aus dem für die KI sicht­ba­ren Da­ten­be­stand aus­ge­schlos­sen werden.

Für größere In­stal­la­tio­nen lässt sich SELECT auch auf alle vor­han­de­nen Tabellen eines be­stimm­ten Schemas vergeben. Sollen au­to­ma­tisch auch zukünftig angelegte Tabellen lesbar sein, können Sie zu­sätz­lich ALTER DEFAULT PRIVILEGES verwenden. Dies sollte jedoch nur dann erfolgen, wenn tat­säch­lich jede neue Tabelle dieses Schemas für den KI-Zugriff vor­ge­se­hen ist.

MCP-Ver­bin­dung zu­sätz­lich absichern

Die Da­ten­bank­rech­te bilden die wich­tigs­te Schutz­schicht, sollten aber durch Si­cher­heits­me­cha­nis­men auf MCP-Ebene ergänzt werden. Die Post­greS­QL-Rolle sollte nur die be­nö­tig­ten Daten lesen dürfen und zu­sätz­lich sollte auch die MCP-Ver­bin­dung selbst als Read-only kon­fi­gu­riert werden.

So entsteht ein mehr­stu­fi­ges Si­cher­heits­mo­dell: Selbst wenn eine Schutz­funk­ti­on auf MCP-Ebene versagt, begrenzen die Post­greS­QL-Be­rech­ti­gun­gen weiterhin, auf welche Daten und Ope­ra­tio­nen der MCP-Server zugreifen kann.

Postgres-MCP-Server kon­fi­gu­rie­ren

Für das folgende Beispiel wird @microsoft/postgres-mcp verwendet. Der Server benötigt Node.js 22 oder neuer und wird über npx gestartet.

Für eine Ver­bin­dung werden folgende Angaben benötigt:

• Host: Der Hostname be­zeich­net den Post­greS­QL-Server.
• Port: Post­greS­QL verwendet stan­dard­mä­ßig Port 5432, sofern die In­stal­la­ti­on nicht anders kon­fi­gu­riert wurde.
• Da­ten­bank­na­me: Der Da­ten­bank­na­me bestimmt, auf welche Datenbank der MCP-Server zugreift.
• User: Hier sollte aus­schließ­lich der zuvor angelegte Read-only-User verwendet werden.
• SSL-Modus: Bei Netz­werk­ver­bin­dun­gen sollte TLS ein­ge­setzt werden. sslmode=require erzwingt eine ver­schlüs­sel­te Ver­bin­dung; verify-full überprüft zu­sätz­lich Zer­ti­fi­kat und Ser­ver­na­men und bietet bei korrekt ein­ge­rich­te­ter Zer­ti­fi­kats­ket­te den stärkeren Schutz.

Bei einer lokalen Desktop-In­stal­la­ti­on empfiehlt es sich, ein Ver­bin­dungs­pro­fil anzulegen und das Passwort an­schlie­ßend im Schlüs­sel­bund des Be­triebs­sys­tems zu speichern:

npx -y @microsoft/postgres-mcp connection add reporting \
    "host=db.example.com port=5432 user=mcp_reader dbname=sales_db sslmode=verify-full" \
    --access-mode ro
npx -y @microsoft/postgres-mcp connection set-password reporting

An­schlie­ßend lässt sich der Server bei­spiels­wei­se in der claude_desktop_config.json re­gis­trie­ren:

{
    "mcpServers": {
        "postgres": {
            "command": "npx",
            "args": [
                "-y",
                "@microsoft/postgres-mcp",
                "run"
            ]
        }
    }
}

Die Da­ten­bank­zu­gangs­da­ten müssen dadurch nicht in der Claude-Kon­fi­gu­ra­ti­on hin­ter­legt werden. Der MCP-Server greift beim Start auf das zuvor ge­spei­cher­te Ver­bin­dungs­pro­fil zurück. Dasselbe mcp­Ser­vers-Format wird auch von mehreren anderen MCP-fähigen Clients un­ter­stützt. VS Code verwendet in .vscode/mcp.json dagegen den Schlüssel servers.

Für Container, CI-Systeme oder andere Um­ge­bun­gen ohne Be­triebs­sys­tem-Keyring un­ter­stützt der Server al­ter­na­tiv die Um­ge­bungs­va­ria­ble POSTGRES_MCP_CONNECTION_STRING. Eine ent­spre­chen­de Ver­bin­dung kann bei­spiels­wei­se folgende Struktur besitzen:

postgresql://mcp_reader:<PASSWORT>@db.example.com:5432/sales_db?sslmode=verify-full

Die Variable sollte dabei durch die Lauf­zeit­um­ge­bung oder ein Secret-Ma­nage­ment-System gesetzt und niemals mit einem echten Passwort in ein Git-Re­po­si­to­ry ein­ge­checkt werden. Für in­ter­ak­ti­ve Desktop-Systeme ist das ge­spei­cher­te Profil die be­vor­zug­te Variante.

Der Read-only-Modus des MCP-Servers ersetzt jedoch nicht den mcp_reader. Der Microsoft-Server ist ein Gateway und keine ei­gen­stän­di­ge Au­to­ri­sie­rungs­in­stanz: Ent­schei­dend ist letztlich, welche Befehle Post­greS­QL dem ver­wen­de­ten Da­ten­bank­kon­to erlaubt.

Pra­xis­bei­spiel: Vom KI-Prompt zur sicheren SQL-Abfrage

An­ge­nom­men, in einer Post­greS­QL-Datenbank liegen Ver­kaufs­da­ten in den für den MCP-User frei­ge­ge­be­nen Tabellen reporting.monthly_sales und reporting.products. Eine Mit­ar­bei­te­rin oder ein Mit­ar­bei­ter könnte nun im KI-Client bei­spiels­wei­se folgende Frage stellen:

„Wie hoch war der Umsatz je Pro­dukt­ka­te­go­rie im September 2026? Zeige nur Ka­te­go­rien mit mehr als 10.000 Euro Umsatz und sortiere das Ergebnis ab­stei­gend.“

Das Sprach­mo­dell erkennt, dass zur Be­ant­wor­tung aktuelle Daten aus Post­greS­QL benötigt werden. Es erzeugt daraufhin eine passende SQL-Abfrage und ruft das vom Postgres-MCP-Server an­ge­bo­te­ne Query-Tool auf. Der aktuelle Microsoft-Server stellt dafür postgres_mcp_query bereit. Dieses Tool ak­zep­tiert eine einzelne Read-only-SQL-Anweisung; mehrere ge­sta­pel­te State­ments werden abgelehnt.

Ein ver­ein­fach­ter Ablauf sieht dabei in etwa so aus:

Dabei sollte nicht davon aus­ge­gan­gen werden, dass jede von einem LLM erzeugte SQL-Abfrage au­to­ma­tisch pa­ra­me­tri­siert wird. Viele Datenbank-MCP-Server erhalten eine voll­stän­di­ge SQL-Anweisung als Tool-Argument. Die Si­cher­heit darf deshalb nicht allein auf einer ver­meint­li­chen Be­rei­ni­gung des vom Modell erzeugten SQL-Texts beruhen.

Genau das zeigte eine Schwach­stel­le des in­zwi­schen ar­chi­vier­ten Post­greS­QL-Re­fe­renz­ser­vers: Dessen Read-only-Trans­ak­ti­on ließ sich durch ge­sta­pel­te SQL-Befehle verlassen, wenn die ver­wen­de­te Da­ten­bank­rol­le selbst Schreib­rech­te besaß. Ein tat­säch­lich schreib­ge­schütz­ter Post­greS­QL-User begrenzt den möglichen Schaden we­sent­lich zu­ver­läs­si­ger.

Der aktuelle Microsoft-Server ergänzt diese Da­ten­bank­rech­te, indem postgres_mcp_query nur einzelne Read-only-Abfragen zulässt und ein Profil mit access_mode: ro die ver­füg­ba­ren Schreib­werk­zeu­ge sperrt. Die Kom­bi­na­ti­on aus ein­ge­schränk­tem MCP-Profil und minimal be­rech­tig­tem Post­greS­QL-User bietet damit zwei von­ein­an­der un­ab­hän­gi­ge Schutz­schich­ten.

Read-only bedeutet al­ler­dings nicht au­to­ma­tisch, dass sämtliche Daten sicher vor Of­fen­le­gung sind. Eine Prompt Injection könnte bei­spiels­wei­se versuchen, das Modell dazu zu bringen, andere In­for­ma­tio­nen aus einer Tabelle abzurufen. Wenn mcp_reader diese Daten lesen darf, kann auch der MCP-Server darauf zugreifen. Deshalb sollten Sie den KI-Nutzenden nur die Tabellen, Views und Spalten freigeben, die für den vor­ge­se­he­nen An­wen­dungs­fall tat­säch­lich benötigt werden.

Fazit

Ein Postgres-MCP-Server er­mög­licht es, Post­greS­QL-Daten direkt als struk­tu­rier­ten Kontext für KI-An­wen­dun­gen nutzbar zu machen. Für einen sicheren Einsatz sollte die Ver­bin­dung jedoch kon­se­quent nach dem Least-Privilege-Prinzip aufgebaut werden. Besonders wichtig ist ein eigener Post­greS­QL-User, der lediglich SELECT-Zugriff auf aus­drück­lich frei­ge­ge­be­ne Tabellen oder Views besitzt.

Zu­sätz­lich sollte der ver­wen­de­te MCP-Server selbst im Read-only-Modus betrieben, die Da­ten­bank­ver­bin­dung ver­schlüs­selt und Zu­gangs­da­ten über einen ge­eig­ne­ten Secret-Speicher statt direkt in Kon­fi­gu­ra­ti­ons­da­tei­en verwaltet werden. Damit bleibt die Datenbank auch dann wirksam geschützt, wenn ein Sprach­mo­dell eine un­er­war­te­te SQL-Anweisung erzeugt oder durch ma­ni­pu­lier­te Inhalte zu einem pro­ble­ma­ti­schen Tool-Aufruf bewegt wird.