📘 DataGate — Sicherer KI-fähiger Daten-Gateway

DataGate ist ein kopfloses, sicheres, policy-gesteuertes Gateway, das Datenbanken kontrolliert, vorhersehbar und ohne freies SQL für KI-Tools (wie GitHub Copilot) bereitstellt.

DataGate fungiert als Vermittler zwischen einem LLM und einer realen Datenbank: Es erlaubt keinen direkten Datenbankzugriff, setzt keine beliebigen Abfragen aus und gestattet keine Schreiboperationen. Es ist als read-only, schema-aware, multi-database und vollständig LLM-sicher konzipiert.

🎯 Hauptziele

• Sicherer Datenzugriff — read-only garantiert über DB-Rollen, Policy-Engine und kontrollierten Query Builder.

• Datenbankabstraktion — das Modell erzeugt kein SQL: DataGate baut sichere und validierte Abfragen.

• Multi-Datenbank — kann sich mit verschiedenen Datenbanken verschiedener Anwendungen verbinden, wie ein kopfloser DBeaver.

• Policy-Engine — granulare Kontrolle über Tabellen, Spalten, Filter, Limits und Komplexität der Operationen.

• Schema-Bewusstsein — lädt automatisch das Datenbankschema und wendet Sicherheitsregeln an.

• Echte Nebenläufigkeit — asynchrone und sichere Architektur, ideal für parallele Anfragen von Copilot.

• Metriken und Audit — Nachverfolgung von Anfragen, Zeiten, Fehlern und Limits für Debugging und Beobachtbarkeit.

• Leistungsprofilierung — In-Process-Latenzprofil (min/avg/p50/p95/p99/max) für die evolutionäre Leistungsüberwachung.

• Abstraktes Backend — gemeinsames read-only Trait für Datenbank-Backends, mit konkreten Implementierungen für PostgreSQL, MySQL/MariaDB und SQLite.

Related MCP server: DB MCP Gateway

🧩 Hauptfunktionen

• Kontrollierter Query Builder — semantische Operationen wie select, search, aggregate, mit automatischer Validierung.

• Typisiertes MCP select — JSON-Vertrag, read-only Ausführung mit JSON-Zeilen, Policy, Audit und bereinigte Fehler; der MCP-Transport bleibt der nächste Schritt.

• Typisiertes MCP search — semantische Suche mit ILIKE auf erlaubten Spalten, parametrisierte Abfragen, Policy/Rate-Limit/Metriken/Audit und serverseitig begrenzte Ausgabe.

• Typisiertes MCP aggregate — count, sum, avg, min und max auf erlaubten Spalten, mit parametrisierten Filtern und ohne Unterstützung für freies SQL oder GROUP BY.

• Versionierte MCP-API — stabiler Deskriptor für API-Version und verfügbare Tools.

• MCP-stdio-Transport — Handshake, Discovery und Aufrufe von select, search und aggregate über den policy-sicheren Pfad.

• Erweiterte Filter — Unterstützung für Muster (LIKE/ILIKE), Bereiche (BETWEEN) und Volltext (to_tsvector + plainto_tsquery), immer parametrisiert und durch Policy validiert.

• Kontrollierter Schema-Katalog — policy-gefilterte Introspektion von Tabellen, Ansichten, Indizes, Constraints (PK/FK/UNIQUE/CHECK/EXCLUSION), Triggern, Funktionen, Prozeduren und Sequenzen; DDL-Definitionen nur wenn sicher.

• Rate Limiting — Schutz vor Modell-Schleifen und zu schweren Abfragen.

• Ausgabelimits — Antworten immer begrenzt, sicher und strukturiert.

• Deterministische Fehler — kein Schema-Leak, kein exponierter SQL-Code, kein Stack Trace.

• Strukturierte Fehler — stabiler Envelope mit Code, generischer Meldung und retryable-Angabe.

• Externe Konfiguration — TOML-Datei für Policy, Limits und benannte Profile (dev/staging/prod).

• MCP-Input-Härtung — Validierung von request_id, Limits für Text-Payloads und Kardinalität zur Reduzierung von DoS-/Input-Missbrauchsflächen.

• Dynamische Policy — die aktive Policy kann atomar ersetzt werden, auch durch Neuladen aus TOML, ohne die MCP-Tools neu zu erstellen.

DataGate stellt keine MCP-Funktion für freie SQL-Abfragen bereit: Der Agent sendet ausschließlich strukturierte Parameter, die vor der Erstellung der parametrisierten Abfrage gegen Schema und Policy validiert werden.

Öffentliche Fehler verwenden die Codes invalid_request, policy_denied, backend_unavailable und internal_error. SQL, Stack Traces, Passwörter, Filterwerte und nicht autorisierte Objektnamen überschreiten nicht die MCP-Grenze.

PostgreSQL-Konfiguration

PostgreSQL-Anmeldeinformationen werden nicht in Konfigurationsdateien oder im Code gespeichert. Der Dienst liest die Verbindung aus der Laufzeitumgebung:

• kompakte Variante: DB_URL

• Komponenten-Variante: DB_HOST, DB_PORT (Standard 5432), DB_USER, DB_PASSWORD, DB_NAME

• PostgreSQL-Optionen: DB_OPTIONS, im Format key=value&key=value

• Pool: DB_MAX_CONNECTIONS und DB_ACQUIRE_TIMEOUT_SECS

SQLite-Konfiguration

Um SQLite im read-only Modus zu verwenden, konfiguriere eine der beiden Varianten:

• vollständige URL: SQLITE_URL

• Dateipfad: SQLITE_PATH

SQLite-Pool-Optionen:

• SQLITE_MAX_CONNECTIONS

• SQLITE_ACQUIRE_TIMEOUT_SECS

MySQL/MariaDB-Konfiguration

Um MySQL oder MariaDB im read-only Modus zu verwenden, konfiguriere eine der beiden Varianten:

• vollständige URL: MYSQL_URL

• Komponenten-Variante: MYSQL_HOST, MYSQL_PORT (Standard 3306), MYSQL_USER, MYSQL_PASSWORD, MYSQL_DATABASE

MySQL/MariaDB-Pool-Optionen:

• MYSQL_MAX_CONNECTIONS

• MYSQL_ACQUIRE_TIMEOUT_SECS

Auswahl des Multi-Datenbank-Backends

Um explizit auszuwählen, welches Backend aktiviert werden soll, setze DATAGATE_BACKEND:

• auto (Standard): Reihenfolge postgres -> mysql -> sqlite

• postgres

• mysql (oder mariadb)

• sqlite

Wenn DATAGATE_BACKEND auf ein bestimmtes Backend gesetzt ist, verlangt DataGate die entsprechende Umgebungskonfiguration; andernfalls wird mit einem expliziten Fehler beendet.

Backend-Reihenfolge beim Bootstrap:

1. PostgreSQL

2. MySQL/MariaDB

3. SQLite

Das erste konfigurierte Backend in der Liste wird aktiviert.

Das optionale serverseitige Rate Limiting verwendet RATE_LIMIT_REQUESTS und RATE_LIMIT_WINDOW_SECS. Das Limit wird pro request_id vor Policy, Query Builder und Datenbank angewendet; Anfragen über der Schwelle erhalten rate_limited und erzeugen kein SQL.

Der Query Builder wendet auch ein konfigurierbares Budget in der Policy über max_query_complexity an: Jede Spalte kostet 1 und jeder Filter kostet 2. Anfragen über dem Budget werden abgelehnt, bevor SQL erzeugt wird.

Die select-Antwort unterliegt auch max_output_bytes in der Policy: Wenn das endgültige JSON-Payload das Limit überschreitet, lehnt DataGate die Anfrage mit einem Policy-Fehler ab, ohne SQL oder interne Details preiszugeben.

Die Metrik-Schicht registriert auch Zähler und serverseitige Latenz für das select-Tool: Gesamt-/akzeptierte/abgelehnte Anfragen, Backend-Fehler, p95-Latenz im Speicher und Snapshot des PostgreSQL-Pools (size, idle).

Die Anwendungsprotokollierung unterstützt zwei Formate:

• LOG_FORMAT=pretty (Standard)

• LOG_FORMAT=json (strukturiert, geeignet für Log-Collector)

Die Mindeststufe der Logs kann mit LOG_LEVEL (trace|debug|info|warn|error) oder über RUST_LOG konfiguriert werden.

Wenn DB_URL vorhanden ist, hat es Vorrang vor den Komponenten. Die PostgreSQL-Rolle muss nur Leserechte haben; außerdem setzt jede Verbindung default_transaction_read_only = on.

Das aktive Profil wird mit profile = "dev" ausgewählt und kann die Policy in [profiles.dev.policy] definieren. Wenn keine benannten Profile vorhanden sind, bleibt die Legacy-Form [policy] unterstützt. Ein deklariertes, aber nicht vorhandenes Profil aktiviert eine Deny-all-Policy, ohne Datenbankoperationen zu starten.

Die veröffentlichten Releases enthalten Binärdateien für Linux x64/ARM64, Windows x64/ARM64 und macOS Intel/Apple Silicon, mit plattformbenannten Archiven und SHA256SUMS-*- Dateien zur Verifizierung der Artefakte.

🛡️ Warum DataGate?

LLMs sollten nicht direkt mit Datenbanken sprechen. Es wird eine sichere, vorhersehbare, kontrollierte, prüfbare, erweiterbare und Multi-Anwendungs-Schicht benötigt. DataGate ist diese Schicht.

🔧 Technologien

• Sprache: Rust

• Datenbanken: PostgreSQL, MySQL/MariaDB und SQLite (heute), weitere DBs morgen

• Protokoll: MCP (Model Context Protocol)

• Architektur: asynchron, policy-gesteuert, schema-bewusst

🚀 Projektstatus

DataGate befindet sich in der Entwurfsphase. Das Repository enthält die anfängliche Struktur, die Dokumentation und die technische Roadmap.

🧪 Multi-Backend-Integrationstests

Die Backend-Integrationstests verwenden optionale Umgebungsvariablen:

• DATAGATE_TEST_POSTGRES_URL

• DATAGATE_TEST_MYSQL_URL

Wenn eine Variable vorhanden ist, prüft der entsprechende Test, dass das Backend read-only kontrollierte SELECT-Abfragen ausführt und Schreibanweisungen ablehnt. Wenn die Variable nicht vorhanden ist, wird der Test ohne Fehler übersprungen.

Vollständige Dokumentation:

• Architecture.md — Design-Prinzipien und Schichtenarchitektur

• ROADMAP.md — detaillierte Roadmap zur 1.0

• docs/configuration.md — Schnellstart, Backend, Policy und Operationen

• docs/benchmarks.md — lokale SQLite- und reale PostgreSQL-Benchmarks

• docs/hardening.md — finale Härtungs-Checkliste für die MCP/Datenbank-Grenze

• docs/http-transport-decision.md — Sicherheitsentscheidung über den entfernten MCP-HTTP-Transport

• docs/editor-registry-evaluation.md — Bewertung der MCP-Registry-Anforderungen und Cross-Editor-Clients

• docs/packaging.md — Packaging-Kanäle und kanonische Quelle der Artefakte

• docs/postgres-mcp-comparison.md — Vergleich mit anderen PostgreSQL-MCP-Servern

• docs/registry-publication.md — MCP-Registry-Strategie, Cross-Editor-Installation und benannte Verbindungen

• docs/mcp-registry-metadata.json — Kandidaten-Metadaten für MCP-Registries/Galerien

• docs/release-candidate.md — Kriterien und Gates der 1.0-Kandidaten

• docs/mcp-tools.md — interne Verträge und Regeln der MCP-Tools

• CONTRIBUTING.md — Regeln für Beiträge, Commits und Branches

• SECURITY.md — Sicherheitsrichtlinie und Meldung von Schwachstellen

Für den Start aus VS Code mit MCP:

• der lokale Standardtransport ist stdio

• die mcp.json-Vorlagen für lokales stdio befinden sich in docs/mcp-tools.md und docs/configuration.md

• entfernter HTTP-Zugriff liegt außerhalb des 1.0-Standards und erfordert eine dedizierte Sicherheitsentscheidung

📍 Roadmap (Zusammenfassung)

• Definition der Policy-Engine

• Implementierung des kontrollierten Query Builders (parametrisiertes select)

• Garantierte read-only Verbindung

• Automatisches Schema-Bewusstsein (interner PostgreSQL-Katalog)

• Audit-Log-Grundlage (JSONL über AUDIT_LOG_PATH)

• MCP-Tools (select, search, aggregate)

• Multi-Datenbank-Unterstützung (PostgreSQL, MySQL/MariaDB, SQLite)

• Initiale Enterprise-Schicht (Beobachtbarkeit, Härtung, dynamische Policy)

• MCP-API-Stabilität (versionierter Deskriptor; stdio-Transport)

• MCP-stdio-Transport

• Benchmarks

• Finale Härtung

• Version 1.0-Kandidat

📄 Lizenz

Apache License 2.0