Data Catalog: Tools, Trade-offs & wann du wirklich einen brauchst

Dein Daten-Team shippt Pipelines im Wochentakt. Die Zahl der Stakeholder wächst. Und jede Woche fragt jemand „Wo kommt diese Zahl her?" oder „Wem gehört diese Tabelle?" — und die Antwort ist entweder ein Slack-Thread, Tribal Knowledge oder Schweigen. Das ist das Data-Catalog-Problem, und es eskaliert schnell.

TL;DR

• Ein Data Catalog beantwortet drei Fragen: Was haben wir, was bedeutet es, kann ich's vertrauen?
• DataHub: OSS, Engineering-getrieben, mature Connector-Ökosystem.
• Atlan: Beste UX, dbt/Looker/Tableau-Integration, $$$.
• Alation: Enterprise-Standard, Compliance-stark.
• OpenMetadata: Modernerer OSS-Alternative zu DataHub, API-first.
• Faustregel: < 20 Personen Team → dbt docs + Notion reichen.

  20 Personen mit Cross-funktionalen Consumern → richtiger Catalog.

Was ein Data Catalog wirklich ist

Ein Data Catalog ist ein zentralisiertes Inventar deiner Daten-Assets — Tabellen, Files, Reports, Dashboards, APIs — plus Metadaten, die diese Assets auffindbar machen. Das Schlüsselwort: auffindbar.

Ein Data Catalog beantwortet drei Fragen:

1. Welche Daten haben wir? — Inventar und Schema-Doku
2. Was bedeuten sie? — Business-Definitionen, Ownership, Lineage
3. Kann ich ihnen trauen? — Freshness, Quality-Scores, Usage-Metriken

Ein Data Catalog ist kein Data Warehouse. Er speichert nicht die Daten — er speichert Informationen über die Daten. Die Unterscheidung zählt bei der Tool-Auswahl, weil manche Anbieter diese Linie verwischen.

Der Begriff „Metadata Management" wird oft synonym verwendet, ist aber breiter — er umfasst operative Metadaten (Job-Run-Logs, Pipeline-Status), die viele Data-Catalogs nicht gut abdecken. Eine „Data Discovery Platform" betont typischerweise das Such-und-Find- Erlebnis über Governance.

Was in einen Data Catalog reingehört

Minimum für einen brauchbaren Catalog:

• Technische Metadaten — Schemata, Spaltennamen, Datentypen, Row-Counts, Last-Updated-Timestamps
• Business-Metadaten — Klartext-Beschreibungen, Business-Owner, freigegebene Use-Cases
• Lineage — Woher Daten kommen, was sie transformiert, was davon abhängt
• Usage-Metadaten — Wer welche Tables queried, was genutzt vs. verlassen wird

Der Unterschied zwischen einem funktionierenden Catalog und einer Geisterstadt ist die Business-Metadata. Technische Metadaten kann man automatisch scrapen. Business-Metadaten muss jemand aufschreiben — und genau hier scheitern die meisten Catalog-Initiativen.

Die Data-Catalog-Landschaft: vier Tools im Vergleich

Der Markt ist explodiert. Ehrlicher Vergleich, Stand März 2026:

Stand: März 2026 — Pricing-Tiers ändern sich häufig; verifiziere direkt bei den Anbietern.

Ein paar ehrliche Beobachtungen:

DataHub (ursprünglich von LinkedIn, jetzt OSS unter dem Acryl-Data- Umbrella) hat das reifste Connector-Ökosystem und die aktivste Community. Das Self-Hosted-Setup hat nicht-trivialen Operations-Overhead — du betreibst Kafka, Elasticsearch und MySQL als Dependencies. Es lohnt sich für große Engineering-Teams; für ein 5-Personen-Daten-Team wahrscheinlich Overkill.

Atlan hat die beste UX der kommerziellen Optionen. Tight integration mit dbt, Looker und Tableau macht die Lineage-Story für BI-heavy Shops attraktiv. Das Pricing reflektiert die UX-Qualität.

Alation ist die etablierte Enterprise-Wahl — am längsten am Markt, starke Governance-Features, häufig in regulierten Branchen (Finanzdienstleister, Gesundheitswesen). Budget entsprechend planen.

OpenMetadata ist der jüngere OSS-Einstieg mit einem saubereren API-Design als DataHub und moderner UI. Wenn du volle Ownership deiner Catalog-Infrastruktur willst und Engineering-Kapazität hast, einen Blick wert neben DataHub.

Build vs. Buy: ein Decision-Framework

Bevor du ein Tool wählst, beantworte ehrlich:

1. Wie viele Daten-Assets hast du tatsächlich? Unter 50 Tables mit kleinem Team? Eine gut gepflegte dbt-Docs-Site und ein README-getriebener Ansatz reichen wahrscheinlich. Der Catalog- Overhead lohnt sich auf dieser Größe nicht.

2. Wer muss die Daten finden und nutzen? Wenn's primär Engineers sind, die den Stack eh kennen, reicht Lightweight-Tooling. Wenn's Business-Analysten und Domain-Teams sind, die nicht wissen, wo die Daten liegen, brauchst du eine such-freundliche UI mit Business-Metadaten.

3. Hast du regulatorische Anforderungen? DSGVO, BAIT (Banken-IT), HIPAA oder Finanz-Compliance machen Governance-Tooling nicht-optional. Die Audit-Trail- und Lineage-Features von Enterprise-Catalogs existieren genau für diese Use-Cases.

4. Was ist deine Engineering-Kapazität? OSS-Catalogs (DataHub, OpenMetadata) geben dir volle Kontrolle und null Lizenzkosten — aber jemand muss sie betreiben. Operations-Overhead einrechnen. Ein managed SaaS-Catalog hat oft niedrigere TCO für ein Team ohne dedizierte Infrastruktur-Kapazität.

5. Wie reif ist dein Daten-Stack? Ein Catalog ohne stabiles Upstream-Daten-Modell ist Verbindlichkeit — du dokumentierst Tabellen, die sich wöchentlich ändern. Stabilisier deine Core-Daten-Modelle, bevor du schwer in deren Catalog-isierung investierst.

Faustregel: Teams unter 10 Personen mit stabilen Stacks starten mit dbt docs + shared Notion-Page, bevor sie dedizierte Catalog-Tools evaluieren. Teams über 20 Personen mit Cross-funktionalen Daten-Consumern brauchen wahrscheinlich was Robusteres.

Häufige Fallen

1. Catalog als Einmal-Projekt behandeln. Ein Data Catalog ist ein lebendes System. Wenn Metadaten nicht aktuell gehalten werden, erodiert der Catalog zum historischen Dokument, dem niemand mehr vertraut. Klare Ownership für die Pflege vor dem Deployment zuweisen.

2. Alles automatisieren, nichts vertrauen. Auto-gescrapte technische Metadaten sind zuverlässig. Auto-generierte Business-Descriptions (z.B. AI-geschriebene Column-Descriptions) klingen plausibel, sind aber in subtilen Punkten oft falsch. Behandle sie als Entwürfe, die menschlichen Review brauchen.

3. Enterprise-Catalog kaufen ohne Enterprise-Governance. Ein 300k€/Jahr-Tool fixt keine Kultur, die Dinge nicht dokumentiert. Das Tool verstärkt bestehende Gewohnheiten — gute wie schlechte.

4. Lineage ignorieren. Das wertvollste Feature eines reifen Catalogs ist Lineage — „diese Dashboard-Zahl" durch Transforms zur Source zurück verfolgen können. Teams, die Lineage skippen, bauen das später manuell in Confluence nach, wenn was in Production bricht.

5. Popularität mit Fit verwechseln. DataHub ist weit verbreitet. Das heißt nicht, dass es für ein 6-Personen-Team passt, das primär dbt und Metabase nutzt. Match das Tool zu deinem realen Workflow, nicht zu den meisten GitHub-Stars.

Der Lightweight-Catalog-Case

Nicht jedes Team braucht ein volles Catalog-Deployment. Brauchbarer Mittelweg: behandle dein dbt-Projekt als Source-of-Truth für Lineage und Dokumentation, leg eine Discovery-Layer obendrauf für Business-User, und nutze strukturierte Naming-Conventions und Ownership-Tags im Warehouse.

Für Teams, die ad-hoc analysieren — CSVs verbinden, APIs queryen, schnelle Analysen — manifestiert sich das „Catalog"-Problem oft als „Ich weiß nicht, welche Daten ich verfügbar habe." Tools wie Harbinger Explorer gehen das aus einem anderen Winkel an: ein Source-Catalog, in dem du Daten-Sources (URLs, CSV-Uploads, API-Endpoints) registrierst und beschreibst, dann mit DuckDB-SQL oder natural-language queryst — ohne volle Catalog- Infrastruktur. Keine Governance-Plattform, aber das Discovery-Problem auf der Analyse-Layer ist gelöst. Ab 19 €/Monat mit 7-Tage-Free-Trial.

Wann ein Data Catalog NICHT die Lösung ist

Ein Data Catalog fixt nicht:

• Inkonsistente Daten-Modelle — schlechte Daten zu katalogisieren macht sie nicht vertrauenswürdig
• Fehlende Ownership-Kultur — das Tool erfordert, dass Menschen Descriptions schreiben und aktuell halten
• Abwesende Governance-Prozesse — ein Catalog ist ein Tool, das Governance unterstützt, kein Ersatz dafür
• Ein Data-Quality-Problem — Tabellen mit unbekannter Qualität zu katalogisieren macht sie nicht nutzbar; du brauchst Data-Quality- Tooling daneben

Wenn dein Kernproblem Data Quality ist, fang dort an. Wenn dein Kernproblem inkonsistente Definitionen Cross-Team ist, fang mit einem Business-Glossary-Prozess an — nicht mit einem Tool. Der Catalog kommt, nachdem die Grundlagen existieren.

FAQ

Brauche ich einen Data Catalog für ein kleines DACH-Startup? Unter 50 Tables und 10 Engineers: nein. dbt docs + Notion reichen. Setz die Energie lieber in Data-Quality und klare Ownership.

DataHub vs. OpenMetadata: was wählen? DataHub für Reife und Community-Größe, OpenMetadata für sauberere API und einfacheres Setup. Beide OSS. Wenn du Engineers hast, die beides evaluieren können: 1 Tag PoC, dann entscheiden.

Erfüllt ein Data Catalog DSGVO-Anforderungen? Er hilft. Lineage und Ownership-Tracking sind core DSGVO-Asks (Art. 30 Verzeichnis von Verarbeitungstätigkeiten). Aber der Catalog selbst muss DSGVO-konform gehostet sein — bei OSS auf EU-Infra, bei SaaS auf einen EU-Tenant achten.

Was kostet Atlan oder Alation realistisch? Atlan: ab ~50k$/Jahr für mittelgroße Teams. Alation: ab ~100k$/Jahr, oft 200–500k$ für Enterprise-Deployments. Beide reden nur mit dir, wenn du seriös skaliert bist.

Fazit

Ein Data Catalog löst das Discovery- und Trust-Problem: welche Daten existieren, was sie bedeuten, ob sie verlässlich sind. Die Tool-Wahl hängt stark von Team-Größe, Engineering-Kapazität, regulatorischem Kontext und der Reife deines Daten-Stacks ab. Für die meisten Teams unter 20 Personen ist der Start mit dbt-Docs und strukturierten Metadata-Practices wertvoller als ein volles Catalog-Deployment.

Wenn du dedizierte Tools evaluierst, bieten OSS-Optionen (DataHub, OpenMetadata) maximale Flexibilität bei Kostenpunkt-Operations-Overhead. Kommerzielle Optionen (Atlan, Alation) tauschen Kosten gegen UX und Support. Keine Wahl ist falsch — es kommt drauf an, was dein Team tatsächlich pflegen wird.

Starte mit den Metadaten, die „wer besitzt das und kann ich's trauen?" beantworten, bevor du den vollen Catalog ausbaust. Das Fundament entscheidet, ob dein Catalog genutzt oder verlassen wird.

Stand: März 2026. Catalog-Tools iterieren schnell — Pricing und Features regelmäßig prüfen.