Lokale Datenbanken anbinden: PostgreSQL, MySQL und SQL Server

Quellen- und Prüfstand: 15. Oktober 2026. OpenMetadata-Anleitungen beziehen sich auf die verlinkte Dokumentation 2.0.x. Einrichtungsschritte und Voraussetzungen vor Einsatz mit Server-, Runner- und Connector-Version abgleichen. Redaktionell geprüft; keine Verbindung zu einem Kundensystem durchgeführt.

„Lokal“ zuerst richtig verstehen

OpenMetadata kann in einer Cloud laufen und Metadaten von einem Runner im Kundennetz erhalten. Entscheidend sind zwei Verbindungen: Runner zur Datenbank und Runner zur OpenMetadata-API. Eine im Browser erreichbare Oberfläche beweist keine dieser Verbindungen.

Vorab erfassen: Engine und Version, Host, feste Port-/Instanzkonfiguration, Datenbank, Schema, TLS-CA, technische Identität, Proxy/Firewall und zugelassenes Ausführungsfenster. Container-DNS und interne Hostnamen vom tatsächlichen Runner prüfen. Keine pauschale Freigabe der Datenbank für das Internet vorsehen.

1. Rechte nach Arbeitsschritt trennen

Die minimalen Rechte nicht pauschal als „nur Metadaten“ verkaufen: Manche Connectoren verlangen SELECT, auch wenn zunächst nur Metadaten importiert werden. Berechtigung und aktivierte Arbeitslast getrennt dokumentieren.

2. PostgreSQL

Unter Database Services → PostgreSQL einen Service wie postgres_erp_prod erstellen. Host/Port, Datenbank und technische Identität eintragen; SSL-Modus und CA passend setzen. In den Datenbank-/Schema-/Tabellenfiltern nur den vereinbarten Pilot wählen. Views einschließen, wenn sie Teil des fachlichen Pfads sind. Test Connection, dann ersten Metadata-Lauf ausführen.

Die PostgreSQL-Anleitung beschreibt für Usage und querybasierte Lineage pg_stat_statements mit zusätzlichen Statistikrechten. Diese optionale Erweiterung kann Serverkonfiguration und Neustart betreffen; sie gehört in eine geplante DBA-Änderung. Sie ist keine Voraussetzung, um zuerst Tabellenmetadaten zu prüfen.

3. MySQL

Den MySQL-Connector mit dem vom Runner erreichbaren Host und Port, passender Anmeldung und engem Schemafilter konfigurieren. Ein gültiges Kennwort löst keine fehlende Hostfreigabe des Datenbankkontos. Version, TLS und unterstützte Rechte anhand der eingesetzten MySQL-/MariaDB-Variante prüfen; MariaDB bei Bedarf über den eigenen dokumentierten Connector behandeln.

Eine Tabelle und eine View als Soll-Liste verwenden. Die View-Definition mit der beobachteten Lineage vergleichen. Statistik-/Query-Historie nicht als automatisch vorhanden annehmen. Profiling zunächst deaktiviert lassen, bis Datenzugriff und Last abgestimmt sind.

4. Microsoft SQL Server

Database Services → MSSQL wählen. Host/Port, konkrete Datenbank und ODBC-Treiber auf dem Runner prüfen. Bei benannten Instanzen die tatsächlich verwendete TCP-Konfiguration mit dem DBA festlegen. Nicht nur auf den Namen aus dem lokalen SSMS-Profil vertrauen.

Die MSSQL-Anleitung unterscheidet SELECT für Tabellen und VIEW DEFINITION beziehungsweise serverweite Entsprechung für View-SQL. Query Store oder DMV-basierte Usage/Lineage benötigen weitere, versionsabhängige Monitoring-Rechte. SQL Server kann View-Definitionen als leer liefern, obwohl der Import der Tabellen erfolgreich ist.

5. Abnahme und Betrieb

pg_stat_statements liefert aggregierte Abfragestatistiken, keine lückenlose Liste aller Einzelausführungen. Begrenzte Einträge, Verdrängung und Resets beeinflussen die Erfassung. Ein eingestelltes Lookback macht daraus keine vollständige Ereignishistorie. Teilabgleich 23.10.2026: PostgreSQL 18 und OpenMetadata 2.0.x. Datenwertzugriff und Statistikrechte getrennt abnehmen.

Nach dem ersten Lauf Tabellen- und Spaltenanzahl im Pilotscope vergleichen, View-SQL prüfen und erwartete Fremdschlüssel beziehungsweise Herkunftsbeziehungen einzeln ansehen. Mit einem ausgeschlossenen Schema prüfen, ob der Filter greift. Danach den Join zu einem Tableau-Workbook oder Power-BI-Modell nachweisen.

Den ersten erfolgreichen Lauf mit Version, Scope, Dauer und Nachweis sichern. Rotation, regelmäßigen Lauf und Alarmempfänger festlegen. Nicht erkannte Verarbeitungsschritte bleiben als konkrete Lücken im GAP-Plan.