Great Expectations (GX Core)

Kurzfazit

Great Expectations ist der De-facto-Standard für Datenqualitätsprüfung in Python-basierten Datenpipelines. Die Open-Source-Variante GX Core ist mächtig, dauerhaft kostenlos und in jeder seriösen Data-Engineering-Stack-Kombination einsetzbar, von einer einzelnen PostgreSQL-Datenbank bis zur Lakehouse-Architektur mit Snowflake und Databricks. Der Preis dafür ist eine echte Lernkurve: Wer keinen Python-Hintergrund mitbringt und keine Pipeline-Erfahrung hat, kommt mit dem Tool allein nicht weit. GX Cloud schließt die Lücke mit einer Web-Oberfläche, kostet aber je nach Team-Größe schnell vierstellig pro Monat und wird ausschließlich in den USA gehostet. Für deutsche Mittelständler ohne Data-Engineering-Team ist das Tool eher Werkzeug für externe Dienstleister als für die eigene Anwendung.

Für wen ist Great Expectations?

Data-Engineering-Teams in mittleren bis großen Unternehmen: Wer Pipelines mit Airflow, Dagster oder dbt betreibt, bekommt mit GX Core ein Framework, das sich sauber in CI/CD einfügt. Qualitätschecks laufen als Code, brechen Pipelines bei Verletzungen ab und produzieren Berichte, die im internen Wiki landen.

Beratungen und Migrations-Spezialisten: Vor jedem ERP- oder Data-Warehouse-Wechsel steht die Frage „Wie sauber sind unsere Stammdaten eigentlich?”. GX Core liefert in wenigen Tagen ein belastbares Bild, Nullquoten, Werteverteilungen, Konsistenzbrüche zwischen Tabellen. Beratungen wie KPMG oder PwC nutzen das Framework intern für Due-Diligence- und Migrationsprojekte.

IT-Verantwortliche vor ERP-Migrationen: Wer 2026 von SAP ECC auf S/4HANA wechseln muss, weiß: Schlechte Stammdaten kosten im Migrationsprojekt das Mehrfache. GX Core auf einem Python-Server mit ODBC-Zugriff zur ERP-Datenbank deckt in wenigen Wochen auf, wo das Bereinigungsprojekt ansetzen muss, bevor die Migration crasht.

Open-Source-überzeugte Unternehmen: Wer keine SaaS-Lizenzen will, kein Vendor-Lock-in akzeptiert und Datenverarbeitung im eigenen Hause behalten muss (Banken, Versicherungen, Behörden), bekommt mit GX Core eine vollwertige Lösung ohne laufende Lizenzkosten.

Weniger geeignet für: Fachabteilungen ohne IT-Unterstützung (keine Klick-Oberfläche in GX Core), Unternehmen mit reinen SAP- oder Salesforce-Datenwelten ohne externen Daten-Layer, Teams, die deutschsprachigen Support brauchen, sowie alle Anwender, die eine fertige Excel-Pivot-Auswertung statt eines Pipeline-integrierten Frameworks suchen.

Preise im Detail

Plan	Preis	Was du bekommst
GX Core (OSS)	0 USD	Vollständiges Python-Framework unter Apache-2.0, alle Expectations, Data Docs, alle Connectors, keine Limits, aber keine Web-UI und kein Support
GX Cloud Developer	0 USD	Web-UI, eine Data Source, einzelner Nutzer, gehostete Validierung, für Evaluierung und Proof-of-Concept
GX Cloud Team	Auf Anfrage (typ. ab ~500 USD/Monat)	Mehrere Nutzer, Team-Verwaltung, mehrere Data Sources, Alerts, geteilte Expectations
GX Cloud Enterprise	Individuell	SSO/SAML, Audit-Logs, AVV, erweiterte Sicherheit, höhere Limits, dedizierter Support

Einordnung: Für Teams mit Python-Kompetenz ist GX Core die richtige Wahl, kostenlos, mächtig, ohne externe Datenflüsse. Wer eine Web-Oberfläche, geteilte Sichten und Stakeholder-Berichte ohne eigenes Hosting will, kommt um GX Cloud nicht herum. Die Team- und Enterprise-Preise werden nicht öffentlich gelistet, das ist ein Warnsignal: Wer im Mittelstand budgetiert, muss vor der Entscheidung ein Angebot einholen und mit vierstelligen Monatskosten rechnen. Die kostenlose Developer-Stufe der Cloud-Variante eignet sich gut, um die UI zu testen, deckt aber keine Teamarbeit ab.

Stärken im Detail

Open-Source-Lizenz ohne Hintertüren. GX Core steht unter Apache-2.0 und ist damit auch kommerziell uneingeschränkt nutzbar, ohne „free for non-commercial use”-Klauseln oder API-Quoten. Wer das Framework auf eigenen Servern betreibt, hat volle Kontrolle über Datenflüsse, Versionen und Anpassungen. Für regulierte Branchen ist das der entscheidende Vorteil gegenüber proprietären SaaS-Tools.

Breite Connector-Palette für moderne Data Stacks. GX Core spricht mit PostgreSQL, MySQL, SQL Server, Snowflake, BigQuery, Databricks, Pandas, Spark, Azure Blob Storage und S3. Das deckt 95 % aller realen Datenarchitekturen ab. Eine ERP-Datenbank-Anbindung ist über ODBC oder native SQL-Treiber möglich, auch SAP HANA wird unterstützt, wenn der Datenbank-Layer freigegeben ist.

Profiling als Schnellstart. Mit drei Zeilen Python lässt sich auf eine Tabelle ein automatisches Profiling werfen: GX erkennt Datentypen, berechnet Verteilungen, identifiziert Nullquoten und erstellt erste Hypothesen für sinnvolle Expectations. Das ist der schnellste Weg, in einer fremden Datenbasis Auffälligkeiten zu finden, Stunden statt Tage.

Expectations als Code. Statt klickbarer Regeln definierst du Erwartungen als Python-Aufrufe (expect_column_values_to_not_be_null("ust_id"), expect_column_values_to_be_in_set("waehrung", ["EUR", "USD", "CHF"])). Diese liegen im Git-Repository, werden im Code-Review geprüft, durchlaufen CI/CD und sind reproduzierbar. Für Audits und Compliance ist das ein erheblicher Mehrwert gegenüber UI-basierten Tools.

Data Docs für Stakeholder. Nach jedem Validierungslauf erzeugt GX automatisch eine HTML-Seite mit Ergebnissen, Statistiken und Trends. Diese Berichte sind statisches HTML, du kannst sie in einem internen Wiki, S3-Bucket oder SharePoint ablegen und auch Nicht-Entwickler informieren. Die Auflösung der „Wer sieht die Qualitätsergebnisse?”-Frage ist damit elegant gelöst.

MCP-Integration für LLM-Workflows. Seit 2025 gibt es einen offiziellen Model-Context-Protocol-Server für GX, der es Claude, ChatGPT oder Cursor erlaubt, Datenqualitätsdaten direkt zu lesen und Expectations zu generieren. Praktisch: Du beschreibst in natürlicher Sprache („alle Lieferanten brauchen eine gültige USt-IdNr im EU-Format”), die KI generiert die passende Expectation. Das senkt die Einstiegshürde spürbar, vorausgesetzt, dein Team nutzt ohnehin LLM-Werkzeuge im Code.

Schwächen ehrlich betrachtet

Steile Lernkurve, sobald es nicht-trivial wird. Die Einstiegs-Tutorials funktionieren reibungslos. Sobald du aber eigene Expectations schreibst, Custom Data Sources anbindest oder das Konfigurationsmodell der Version 1.0 verstehen musst, wird es anspruchsvoll. Viele alte Blog-Posts und Stack-Overflow-Antworten beziehen sich auf die alte 0.x-API, das verwirrt Neueinsteiger zuverlässig.

Keine Klick-Lösung in GX Core. Wer keine Python-Umgebung aufsetzen kann, kommt mit GX Core nicht weit. Es gibt keine GUI, keine Drag-and-Drop-Regelerstellung, keinen No-Code-Modus. Für Fachabteilungen ohne IT-Backup ist das ein Stopper, entweder du buchst GX Cloud (mit Kosten) oder einen externen Dienstleister.

GX Cloud ist nicht in der EU verfügbar. Der gehostete SaaS-Dienst läuft auf AWS in US-Regionen. Eine EU-Region für GX Cloud gibt es nicht. Für DSGVO-strenge Branchen (Banken, Versicherungen, Gesundheit, Behörden) ist das ein Ausschlusskriterium, selbst wenn nur Metadaten und Validierungsergebnisse in die Cloud fließen würden, ist das datenschutzrechtlich aufwendig zu legitimieren. Lösung: GX Core selbst hosten.

Kein deutschsprachiges Support- und Doku-Ökosystem. Die offizielle Dokumentation ist ausschließlich Englisch. Auch die Community-Antworten in GitHub-Issues und Discord laufen auf Englisch. Wer in seinem Team viele Nicht-Native-Speaker hat, bekommt eine zusätzliche Hürde.

Performance bei sehr großen Tabellen. Wer mehrere Hundert Millionen Zeilen pro Validierungslauf prüft, muss tief in die Konfiguration einsteigen (Sampling-Strategien, Partitionierung). Out-of-the-box scant GX die Daten, bei Snowflake oder BigQuery löst das Compute-Kosten aus, die schnell unerwartet groß werden können.

Keine direkte ERP-Integration. GX kennt keine SAP-Geschäftsobjekte, keine Oracle-EBS-Strukturen, keine Workday- oder Salesforce-API. Du brauchst immer Zugriff auf die unterliegende Datenbank, was bei modernen SaaS-ERPs (z. B. S/4HANA Cloud, NetSuite) oft gar nicht möglich ist. Für reine ERP-Datenqualitätsprüfung sind spezialisierte Tools wie Camelot ITLab oder zetVisions teilweise besser positioniert.

Alternativen im Vergleich

Wenn du…	…nimm stattdessen
Eine ähnliche Open-Source-Lösung mit anderem Konzept brauchst	Soda Core
KI-basierte Code-Erzeugung von Expectations möchtest	Claude oder Cursor

Erwähnenswert ohne eigene Tool-Seite: Soda (Cloud + OSS, ähnliches Konzept, oft als Wettbewerber genannt), Monte Carlo (Data Observability, breiter, aber teurer), Anomalo (KI-gestützt, automatische Anomalieerkennung ohne explizite Regeln), Elementary (Open Source für dbt). Für reine ERP-Stammdaten-Cleansing sind außerdem Stibo STEP, Informatica MDM oder Camelot ITLab branchenstärker, aber deutlich teurer und proprietär. Great Expectations punktet mit Verbreitung, Reife und der Tatsache, dass es vollständig kostenlos und offen ist, das macht es zur ersten Wahl für Teams, die Datenqualität von Grund auf in ihre Pipelines bauen wollen.

So steigst du ein

Schritt 1: Installiere GX Core in einer virtuellen Python-Umgebung: pip install great_expectations. Erstelle ein neues GX-Projekt mit gx init. Das legt die Verzeichnisstruktur an, in der später Expectations, Validierungsläufe und Data Docs liegen. Verbinde dich mit deiner ersten Data Source, typischerweise eine Lesekopie der ERP-Datenbank, ein Snowflake-Schema oder eine Sammlung von Parquet-Dateien in S3.

Schritt 2: Führe ein automatisches Profiling auf einer Tabelle aus, zum Beispiel auf dem Artikelstamm oder den Lieferanten. GX erzeugt eine HTML-Übersicht mit Verteilungen, Nullquoten und Hypothesen für sinnvolle Expectations. Wähle aus dem Profiling-Ergebnis manuell die Regeln aus, die wirklich Geschäftsbedeutung haben, nicht jede statistische Auffälligkeit ist auch ein Qualitätsproblem.

Schritt 3: Integriere die Validierungen in deine Pipeline-Umgebung. In Airflow gibt es einen offiziellen GreatExpectationsOperator, in dbt lässt sich GX über Hooks anbinden, in CI/CD-Workflows kannst du GX direkt als Schritt in GitHub Actions oder GitLab CI laufen lassen. Plane wöchentliche oder tägliche Validierungsläufe und stelle sicher, dass Ergebnisse als Data Docs in einem zugänglichen Speicherort landen (interner S3-Bucket, SharePoint, Confluence).

Schritt 4 (optional): Wenn das Team wächst und nicht-technische Stakeholder live mitlesen sollen, evaluiere GX Cloud. Beachte: Daten fließen in US-Region. Für regulierte Branchen ist das Selbsthosting auf einem eigenen Server der sauberere Weg, kombiniert mit einem statischen HTML-Hosting für die Data Docs reicht das in den meisten Fällen aus.

Ein konkretes Beispiel

Ein produzierendes Unternehmen mit 450 Mitarbeitenden in Bielefeld will 2026 vom Altsystem auf SAP S/4HANA wechseln. Der IT-Leiter weiß aus früheren Migrationsprojekten, dass schlechte Stammdaten der häufigste Crash-Treiber sind. Statt eine externe Beratung für 80.000 Euro zu beauftragen, setzt das eigene Data-Engineering-Team (zwei Personen) GX Core auf einem internen Python-Server auf und verbindet es über ODBC mit der bestehenden SQL-Server-Datenbank des ERP. Innerhalb von drei Wochen werden 40 Expectations für die wichtigsten Stammdatentabellen formuliert: Artikelstamm, Lieferanten, Kunden, Materialklassen. Das erste Profiling deckt auf: 12 % der Artikel haben keine Maßeinheit, 8 % der Lieferanten haben keine gültige USt-IdNr, 23 % der Kostenstellen referenzieren einen veralteten Kontenrahmen. Die HTML-Berichte gehen wöchentlich an die Fachbereiche, die das Bereinigen vor der Migration übernehmen. Aufwand intern: ca. 6 Personenwochen. Vermiedener Migrations-Crash: geschätzt sechsstellig. Lizenzkosten: 0 Euro.

DSGVO & Datenschutz

• GX Core (Open Source): Läuft vollständig in deiner Infrastruktur. Keine Daten verlassen das eigene Netzwerk, kein externer Dienstleister. Für DSGVO ist das der unkomplizierte Weg, die Verarbeitung findet vollständig im eigenen Verantwortungsbereich statt.
• GX Cloud: Gehostet in den USA (AWS). Eine EU-Region gibt es aktuell nicht. Für DSGVO-strenge Branchen ist GX Cloud daher nur mit Standardvertragsklauseln, Datenschutz-Folgenabschätzung und expliziter Datenflussbewertung einsetzbar.
• Datenflüsse in der Cloud: Bei GX Cloud werden Validierungsergebnisse, Metadaten und Konfigurationen in der US-Cloud gespeichert. Die eigentlichen Daten verbleiben in der Quelldatenbank, geprüft wird in der Regel über einen Agent, der im eigenen Netz läuft. Das mildert das DSGVO-Risiko, eliminiert es aber nicht vollständig.
• Auftragsverarbeitung (AVV): Für GX Cloud Enterprise wird auf Anfrage ein AVV bereitgestellt. Bei GX Core entfällt der AVV, weil es kein Auftragsverhältnis gibt.
• Empfehlung für Unternehmen: In Deutschland produzierende Mittelständler und regulierte Branchen sollten GX Core selbst hosten. GX Cloud ist erst dann eine Option, wenn die Datenflüsse genau dokumentiert sind und der US-Transfer datenschutzrechtlich abgesichert ist.

Gut kombiniert mit

• Apache Airflow, Workflow-Orchestrierung, die GX-Validierungen als Tasks in DAGs einbettet. Der offizielle GreatExpectationsOperator macht die Integration trivial. Datenqualität wird damit Teil jedes Datenflusses, nicht ein nachgelagerter Audit.
• dbt, wenn die Transformation in dbt läuft, ergänzt GX die Qualitätsprüfung auf Eingangs- und Ausgangsdaten. dbt Tests sind schlanker, GX hat den größeren Funktionsumfang und das bessere Reporting. In der Praxis verwenden viele Teams beides parallel.
• Claude oder Cursor, über den MCP-Server kann ein LLM Expectations aus natürlicher Sprache erzeugen oder Profiling-Ergebnisse interpretieren. Senkt die Einstiegshürde erheblich für Teams, die ohnehin mit KI-Coding-Assistenten arbeiten.

Unser Testurteil

Great Expectations verdient 3 von 5 Sternen. Für Data-Engineering-Teams mit Python-Kompetenz ist es eines der besten verfügbaren Werkzeuge für systematische Datenqualität, kostenlos, ausgereift, gut dokumentiert, breite Connector-Palette. In dieser Zielgruppe würde der Stern fünf locker stehen. Den Abzug gibt es für die deutlich engere praktische Nutzbarkeit: Wer kein Engineering-Team hat, kann es nicht eigenständig betreiben. Die Cloud-Variante füllt die Lücke, ist aber US-gehostet, intransparent bepreist und für deutsche Mittelständler oft nicht passend. Die KI-Komponente (Profiling, MCP-Integration) ist real, aber nicht der Star der Show, das Tool ist im Kern ein Datenqualitäts-Framework, das KI-Workflows ermöglicht, nicht ein KI-Produkt im engeren Sinne. Wer im DACH-Raum eine schlüsselfertige, deutschsprachige Datenqualitätslösung sucht, ist hier falsch. Wer ein Data-Engineering-Team aufbaut oder schon hat, sollte GX Core ausprobieren, die Zeitinvestition rechnet sich langfristig.

Was wir bemerkt haben

• 2024, Mit GX 1.0 wurde die API grundlegend umgebaut. Der neue Ansatz ist sauberer und konsistenter, aber viele Tutorials, Blog-Posts und Stack-Overflow-Antworten beziehen sich noch auf die alte 0.x-API. Wer einsteigt, sollte ausschließlich die offizielle Dokumentation als Quelle nutzen und sich nicht von älteren Beispielen verwirren lassen.
• 2024, Die Firma hinter Great Expectations hat sich von „Superconductive” in „GX Labs” umbenannt. Marke und URL sind jetzt konsistenter, frühere Verweise auf Superconductive zeigen meist noch funktionierende Weiterleitungen.
• 2025, Ein offizieller MCP-Server für Great Expectations wurde veröffentlicht. Damit kann Claude oder ChatGPT direkt auf GX-Konfigurationen zugreifen und Expectations aus natürlicher Sprache generieren, ein interessantes Beispiel, wie klassische Engineering-Tools mit LLMs verschmelzen.
• Mai 2026, GX Cloud bleibt US-gehostet. Eine EU-Region ist nicht in der öffentlichen Roadmap. Für DSGVO-strenge Branchen bleibt das Selbsthosting von GX Core die einzige saubere Option, und das ist seit Jahren unverändert.
• 2025–2026, Die Pricing-Struktur von GX Cloud ist weiterhin intransparent. Team- und Enterprise-Preise sind nicht öffentlich, Kunden berichten von Monatskosten im vierstelligen Bereich. Wer evaluiert, sollte vor Vertragsabschluss mehrere Anbieter (Soda, Monte Carlo, Anomalo) vergleichen, weil der Markt deutlich in Bewegung ist.