Integration · PostgreSQL

PostgreSQL mit KI abfragen: DSGVO-konform mit meinGPT

Eine lokale PostgreSQL-Datenbank über Outpost mit ausdrücklich lesendem oder schreibendem Zugriff anbinden.

PostgreSQL kann als Dienst am meinGPT Outpost registriert und mit ausgewählten Assistenten geteilt werden. Der Outpost verbindet sich mit der lokalen Datenbank. Datenbankrolle und gewählter read-only oder read-write Modus bestimmen, was der Assistent ausführen darf.

Ein Admin richtet die PostgreSQL-Verbindung am Outpost ein und teilt den registrierten Dienst in meinGPT. Der Assistent kann das verfügbare Schema prüfen und erlaubte Abfragen ausführen. Eine eigene Datenbankrolle sollte Tabellen, Zeilen und Operationen wirksam begrenzen.

Technischer Rahmen
PostgreSQL
meinGPT
Quelle
PostgreSQL
Fähigkeit
Schema prüfen und freigegebene SQL-Abfragen ausführen
Anbindung
Datenbankzugang bleibt im Outpost; Datenbankrechte bestimmen den wirksamen Umfang
Datenhaltung
Datenbank und Zugangsdaten bleiben im lokalen Netz; Ergebnisse laufen über die Outpost-Verbindung

Quelle, Berechtigung und Datenhaltung werden für jeden Connector separat dokumentiert.

Einrichtung in den Docs

Typische Abläufe

  • Natürlichsprachliche Frage zu read-only SQL
  • Schema erkunden und dokumentieren
  • Ad-hoc-Reports und KPIs erzeugen
  • Komplexe Joins ohne SQL-Kenntnisse
  • Generierte SQL prüfen und erklären lassen
  • Datenbestände auf Plausibilität sichten

Was mit der Integration möglich wird

01

Natürlichsprachliche Frage zu read-only SQL

Fachanwender stellen Fragen wie „Wie viele aktive Verträge haben wir je Region?" — die KI erzeugt aus dem bekannten Schema die passende SELECT-Abfrage und führt sie read-only aus, ohne dass jemand SQL schreiben muss.

02

Schema erkunden und dokumentieren

Weil der Connector schema-aware ist, erklärt die KI Tabellen, Spalten und Beziehungen (Fremdschlüssel) und beantwortet „Welche Tabelle enthält die Bestelldaten?" direkt aus dem gelesenen Schema.

03

Ad-hoc-Reports und KPIs erzeugen

Aus einer Frage wie „Umsatz je Monat im aktuellen Jahr" entsteht eine Aggregations-Abfrage (GROUP BY) und daraus eine fertige Auswertungstabelle für die Freigabe.

04

Komplexe Joins ohne SQL-Kenntnisse

Fragen über mehrere Tabellen hinweg werden anhand der Fremdschlüssel-Beziehungen automatisch zu Joins aufgelöst, statt sie manuell zu verknüpfen.

05

Generierte SQL prüfen und erklären lassen

Die KI zeigt die erzeugte SELECT-Abfrage transparent an und erklärt sie Schritt für Schritt — so lässt sie sich vor produktiver Nutzung kontrollieren und wiederverwenden.

06

Datenbestände auf Plausibilität sichten

Read-only Stichproben und Zählungen (z. B. fehlende Werte, Dubletten, Ausreißer) machen Datenqualitätsprobleme sichtbar, ohne Daten zu verändern.

Prompt und Ergebnis offen prüfen

Prompt

Unsere PostgreSQL-Datenbank enthält unter anderem die Tabellen `orders` und `customers`. Zeig mir den Gesamtumsatz je Kundenregion für das laufende Jahr, absteigend sortiert. Gib zuerst die read-only SQL-Abfrage aus, die du dafür nutzt, und dann das Ergebnis als Tabelle.

Ergebnis

```sql
SELECT c.region, SUM(o.amount) AS umsatz
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.order_date >= date_trunc('year', CURRENT_DATE)
GROUP BY c.region
ORDER BY umsatz DESC;
```

| Region | Umsatz (€) |
|---|---|
| Süd | 412.900 |
| West | 318.450 |
| Nord | 274.100 |
| Ost | 159.700 |

Passt diese Anbindung zu eurem Use Case?

Wir klären am konkreten Use Case, welche Quelle, Rechte und Verbindung nötig sind. Wenn die vorhandene Integration passt, könnt ihr danach direkt mit der Einrichtung beginnen.

Anbindung besprechenKostenlos starten

Sicherheit und Betrieb

Zugangsdaten bleiben im Outpost. Verwendet eine eigene Datenbankrolle mit minimalen Rechten, bevorzugt read-only und stellt sensible Felder über gezielte Views statt über Basistabellen bereit.

Bei der Auswahl prüfen

  • Read-only — ist sichergestellt, dass nur Lesezugriffe möglich sind (Connector + DB-Nutzer)?
  • Datenresidenz — die DB bleibt in eurer Infrastruktur; wo werden Schema und Ergebniszeilen verarbeitet?
  • Datenminimierung — lassen sich sichtbare Tabellen/Spalten begrenzen (z. B. über Views)?
  • Transparenz — wird die generierte SQL-Abfrage angezeigt und ist sie nachvollziehbar?
  • Auditierbarkeit — sind die ausgeführten Abfragen protokolliert?

Bekannte Grenzen

  1. 01Der Connector ist bewusst read-only — Daten ändern (INSERT/UPDATE/DELETE) ist ausgeschlossen; für Schreibvorgänge braucht es einen anderen Weg.
  2. 02Die Antwortqualität hängt von der Schema-Qualität ab: sprechende Tabellen- und Spaltennamen führen zu besseren generierten Abfragen als kryptische Bezeichner.
  3. 03Generierte SQL sollte vor produktiver Verwendung geprüft werden — die KI ersetzt keine fachliche Validierung der Abfragelogik.
  4. 04Sehr große Ergebnismengen sollten über Filter und Aggregation begrenzt werden, statt ganze Tabellen abzurufen.

Häufige Fragen

Ja. PostgreSQL wird über den nativen mcp-database-Connector (read-only, schema-aware) angebunden. Die KI liest das Schema, übersetzt Fragen in read-only SQL und führt sie gegen eure Datenbank aus — ohne Make.com, DataVault oder eigenen Connector-Code.

Weiterlesen