Skip to content
RiverCore
Fivetran-dbt-Fusion abgeschlossen: Der Analytics-Stack konsolidiert sich
Fivetran dbt mergeranalytics stackdata integrationFivetran dbt Labs combined platformagentic AI data infrastructure

Fivetran-dbt-Fusion abgeschlossen: Der Analytics-Stack konsolidiert sich

9 Jul 20267 Min. LesezeitAlex Drover

Jeder Data-Platform-Verantwortliche, der schon einmal ein Wochenende damit verbracht hat, eine fehlerhafte ELT-Pipeline gegen einen Semantic Layer abzugleichen, weiß: Die Naht zwischen Ingestion und Transformation ist der Ort, an dem die Nächte lang werden. Diese Naht wurde soeben offiziell verschweißt. Fivetran und dbt Labs haben die im Oktober angekündigte Fusion vollzogen, und das gemeinsame Unternehmen liefert bereits am ersten Tag neue Produkte aus.

Was geschehen ist

Wie Techzine Global berichtete, haben die beiden Unternehmen den im Oktober 2025 angekündigten Zusammenschluss formalisiert – mit einem kombinierten Umsatz von 600 Millionen Dollar und einer Kundenbasis von über 100.000 Daten-Teams. George Fraser bleibt CEO. Tristan Handy, der Mitgründer, der dbt zum De-facto-Standard für Datentransformation gemacht hat, übernimmt die Rolle des Präsidenten.

Das Versprechen ist klar: Ein Anbieter kontrolliert die gesamte Pipeline vom Quellsystem ins Data Warehouse sowie die darüber liegende Transformations-, Semantik- und Governance-Schicht. Fivetran übernimmt die kontinuierliche Synchronisierung und Vollständigkeit. dbt kümmert sich um Geschäftslogik, semantischen Kontext, Tests und Lineage. Das gemeinsame Angebot bettet dies in ein Narrativ ein, wonach agentische KI verlässliche Datenfundamente benötigt.

Die Zahlen, die Fivetran selbst zur Begründung der Strategie veröffentlicht, sind es wert, zweimal gelesen zu werden. Der Agentic AI Readiness Index 2026 behauptet, dass bereits 60 Prozent der Unternehmen Millionen in agentische KI investieren, während nur 15 Prozent über ein Datenfundament verfügen, das diese Workloads tatsächlich sicher unterstützen kann. Eine separate Fivetran-Umfrage beziffert den Anteil der Unternehmen, die agentische KI auf nicht ausreichender Dateninfrastruktur betreiben, auf 85 Prozent. Das gesponserte Framing sollte man mit Vorsicht genießen, aber die grundsätzliche Richtung ist real.

Die Produktveröffentlichungen zum Start sind ambitioniert. dbt Core v2.0 erscheint in der Alpha-Version unter Apache 2.0, aufgebaut auf der neuen Fusion Engine Runtime. dbt State kommt als Preview-Version eines Caching-Layers, der nur neu aufbaut, was sich geändert hat – der Anbieter verspricht eine Reduzierung der Infrastrukturkosten um 30 Prozent oder mehr. dbt Wizard, in der Beta-Phase, verspricht autonomes Erstellen, Refactoring und Debugging von Modellen. Und Agents Schema, ein Open-Source-Standard, definiert ein einzelnes Warehouse-Schema als gemeinsamen Kontext-Layer für KI-Agenten.

Handys Aussage gibt den Rahmen vor: „Die Unternehmen, die KI im nächsten Jahrzehnt erfolgreich einsetzen, werden jene sein, deren Agenten vertrauenswürdig handeln können. Vertrauen entsteht auf der Infrastrukturebene – durch hochwertige Werkzeuge und offene Standards."

Technische Analyse

Lässt man das KI-Framing beiseite und schaut, was tatsächlich geliefert wurde, ist dbt Core v2.0 auf der Fusion Runtime die eigentliche Geschichte. Die ursprüngliche dbt Engine war trotz ihrer weiten Verbreitung ein Python-Orchestrator, der Befehle an Warehouses weitergab. Fusion ist eine Neuentwicklung. Teams, mit denen ich bei großen dbt-DAGs gearbeitet habe – tausende Modelle mit langen Parse- und Compile-Zeiten – haben das seit Jahren erwartet. Wenn Fusion bei Parse- und Ausführungsgeschwindigkeit liefert, rechtfertigt das allein schon den Versions-Sprung.

dbt State ist operativ interessanter. Ein Caching-Layer, der nur neu aufbaut, was sich geändert hat, klingt nach Standard-Inkremental-Logik, aber das Framing deutet auf etwas hin, das eher einem materialisierungsbasierten Cache über den gesamten DAG entspricht – nicht nur auf Modell-Ebene. Wenn die 30-Prozent-Kostenersparnis des Anbieters selbst zur Hälfte zutrifft, ist das relevant. Bei einer Snowflake- oder BigQuery-Rechnung von 2 Millionen Dollar jährlich entsprechen 15 Prozent dem Gehalt eines Senior Engineers. Wer schwere nächtliche Transformations-Fenster betreibt, sollte das gegen den aktuellen Compute-Aufwand modellieren. Die dbt-Dokumentation wird der erste Anlaufpunkt sein, um die Semantik zu prüfen, sobald State die Preview-Phase verlässt.

Agents Schema ist das Thema, über das Analysten im nächsten Jahr diskutieren werden. Das Konzept: Ein dediziertes Schema im Warehouse hält Metrik-Definitionen, semantische Modelle und dbt-Lineage als einfache SQL-Tabellen vor. Jeder SQL-fähige Agent kann darauf zugreifen. Es übernimmt die bestehende Sicherheit und Governance des Warehouses. Kein neuer Server, kein separater Metadaten-Dienst, keine proprietäre API.

Meine Einschätzung: Das ist ein kluger architektonischer Schachzug. Jeder Semantic-Layer-Anbieter der letzten fünf Jahre versuchte, einen separaten Dienst zu verkaufen, mit dem sich Agenten und BI-Tools integrieren mussten. Agents Schema dreht das um. Wenn Ihr Agent bereits SQL gegen Snowflake oder Databricks spricht, kann er semantischen Kontext über dieselbe Verbindung konsumieren – unter denselben Row-Level-Policies, auditiert durch dieselbe Query-History. Das ist die Art langweiliger Infrastrukturentscheidung, die tatsächlich ein Security-Review überlebt.

dbt Wizard würde ich am kritischsten unter die Lupe nehmen. Autonomes Refactoring von Produktionsdatenmodellen ist eine Kategorie, in der eine schlechte Empfehlung stillschweigend eine Kennzahl korrumpiert, die das Finanzteam am Montag liest. Beta bedeutet Beta.

Wer unter Druck gerät

Beginnen wir mit den offensichtlichen Verlierern. Eigenständige Semantic-Layer-Anbieter konkurrieren jetzt mit einem kostenlosen, Open-Source-Standard, der vom Unternehmen unterstützt wird, das bereits in 100.000 Warehouses vertreten ist. Cube, AtScale und das Looker Semantic Model müssen die Frage beantworten: Warum für einen separaten Dienst zahlen, wenn Agents Schema 80 Prozent der Arbeit innerhalb des bestehenden Warehouse-Sicherheitsperimeters erledigt?

Reverse-ETL- und leichtgewichtige Ingestion-Anbieter sind die zweite Risikogruppe. Fivetran hatte bereits Skalierbarkeit. Kombiniert mit dbt's Entwickler-Mindshare wird der Cross-Sell in Richtung Transformations-Käufer trivial. Jedes Tool, das an dieselbe Data-Engineering-Persona verkauft wird, konkurriert jetzt gegen einen Suite-Rabatt.

Die unbequeme Lektüre: Unabhängige dbt-Beratungen und Boutique-Implementierer sollten wegen dbt Wizard nervös sein. Wenn autonome Modellerstellung auch nur auf Junior-Engineer-Niveau funktioniert, schrumpft der Markt für „Hilf uns, unsere Staging-Schicht zu schreiben"-Verträge schnell. Die hochwertige Arbeit verlagert sich nach oben in die Datenmodellierungsstrategie und nach unten in Governance, während die Mitte ausgehöhlt wird. Das ist in jeder Kategorie passiert, in der ein kompetenter Copilot ausgeliefert wurde.

Für iGaming- und Fintech-Plattformteams ist die Risikolage anders. Diese Branchen operieren unter strengen regulatorischen Anforderungen, bei denen Lineage, Auditierbarkeit und Reproduzierbarkeit nicht verhandelbar sind. Eine Fusion, die Ingestion und Transformation unter einem Anbieter konzentriert, bedeutet einen Beschaffungsvertrag, ein SOC-2-Review, einen Single Point of Failure. Produktionsvorfälle, die ich bei Betreibern mit Multi-Vendor-Stacks erlebt habe, lagen selten an den Tools selbst. Sie lagen an den Nahtstellenproblemen. Weniger Nahtstellen ist genuiner Fortschritt. Ein Anbieter, der die gesamte Datenwertschöpfungskette hält, ist ein anderes Risikoprofil.

Die von Fivetran zitierte Readiness-Lücke von 85 Prozent ist auch eine Warnung an alle, die agentische KI in kundennahe Oberflächen drängen. Wenn Ihr Agent einem Support-Mitarbeiter eine fehlerhafte Churn-Zahl präsentiert, landet das Incident-Postmortem auf dem Tisch des Daten-Teams – nicht des ML-Teams.

Handlungsempfehlungen für Daten-Teams

Konkrete Maßnahmen für die nächsten zwei Wochen:

Erstens: Ziehen Sie die Warehouse-Compute-Abrechnung des letzten Quartals und identifizieren Sie die zehn teuersten dbt-Modelle nach Laufzeit. Das sind Ihre dbt-State-Kandidaten, sobald es in den allgemeinen Verfügbarkeitsstatus geht. Modellieren Sie die 30-Prozent-Ersparnis gegen den tatsächlichen Aufwand, bevor Sie daran glauben.

Zweitens: Lesen Sie die Agents-Schema-Spezifikation, sobald sie veröffentlicht wird. Wenn Sie bereits einen selbst entwickelten Metrikkatalog betreiben, entscheiden Sie jetzt, ob Sie auf den offenen Standard konvergieren oder benutzerdefiniert bleiben. In zwei Jahren wird jedes LLM-basierte Analytics-Tool davon ausgehen, dass Agents Schema in Ihrem Warehouse existiert. Das letzte Team zu sein, das benutzerdefinierte Metrik-APIs schreibt, ist keine gute Position.

Drittens: Bringen Sie dbt Wizard in diesem Quartal nicht in die Nähe von Produktionsmodellen. Testen Sie es gegen ein Staging-Projekt, protokollieren Sie jeden Vorschlag, überprüfen Sie die Diffs. Entwickeln Sie institutionelles Urteilsvermögen darüber, wo es hilft und wo es scheitert, bevor es irgendetwas berührt, was das Finanzteam liest.

Viertens: Überprüfen Sie Ihr Vendor-Concentration-Risikoregister. Wenn Fivetran plus dbt nun 60 Prozent Ihrer Datenplattform abdecken, ist das eine Abhängigkeit auf Vorstandsebene. Dokumentieren Sie den Migrationspfad von beiden, auch wenn Sie ihn nie nutzen. Optionalität ist eine günstige Versicherung.

Fünftens: Wenn Sie Snowflake oder Databricks einsetzen, prüfen Sie, ob Agents Schema sauber mit Ihren bestehenden Row-Level-Security- und Masking-Policies funktioniert, bevor Ihr erster Agent live geht. Governance ist der Punkt, an dem diese Projekte scheitern.

Die wichtigsten Erkenntnisse

  • Die Fusion schließt mit 600 Mio. $ kombiniertem Umsatz und 100.000 Daten-Teams ab – das ist die größte Konzentration im Analytics-Tooling-Stack seit Jahren.
  • Die behauptete 30-prozentige Infrastrukturkostenreduzierung durch dbt State ist der unmittelbar quantifizierbarste Vorteil und sollte gegen den tatsächlichen Warehouse-Aufwand getestet werden.
  • Agents Schema als Open-Source-, Warehouse-nativer Standard untergräbt jeden proprietären Semantic-Layer-Anbieter und ist der strategisch unterschätzte Spielzug dieser Veröffentlichung.
  • Eigenständige Semantic-Layer-Unternehmen, Boutique-dbt-Beratungen und kleine Ingestion-Anbieter stehen in den nächsten 12 Monaten unter dem stärksten Wettbewerbsdruck.
  • Das Vendor-Concentration-Risiko ist nun ein Thema auf Vorstandsebene für jedes Team, das Fivetran plus dbt als primäre Datenwertschöpfungskette betreibt.

Häufig gestellte Fragen

F: Was hat die Fusion von Fivetran und dbt Labs am ersten Tag konkret geliefert?

Vier Produktveröffentlichungen: dbt Core v2.0 in der Alpha-Version unter Apache 2.0 auf der neuen Fusion Runtime, dbt State in der Preview-Version als Caching-Layer, dbt Wizard in der Beta-Phase für autonomes Modell-Authoring sowie Agents Schema als Open-Source-Standard für KI-Agenten-Kontext im Warehouse.

F: Wie viel kann dbt State realistischerweise bei Warehouse-Kosten einsparen?

Der Anbieter verspricht eine Reduzierung der Infrastrukturkosten um 30 Prozent oder mehr, indem nur neu aufgebaut wird, was sich in Datenpipelines geändert hat. Diese Zahl muss gegen Ihre spezifische Workload validiert werden, aber selbst die Hälfte dieser Ersparnis ist bei jeder Warehouse-Rechnung im siebenstelligen Bereich material.

F: Ersetzt Agents Schema Tools wie Cube oder den Looker Semantic Layer?

Es konkurriert direkt mit ihnen, indem es Metrik-Definitionen und semantische Modelle als SQL-Tabellen im Warehouse selbst speichert – kompatibel mit jedem SQL-fähigen Agenten und unter Übernahme bestehender Sicherheitsrichtlinien. Proprietäre Semantic-Layer-Anbieter müssen jetzt einen separaten Dienst gegenüber einem kostenlosen offenen Standard rechtfertigen.

AD
Alex Drover
RiverCore Analyst · Dublin, Ireland
TEILEN
// ÄHNLICHE ARTIKEL
StartseiteLösungenProjekteÜber unsKontakt
News06
Dublin, Irland · EUGMT+1
LinkedIn
🇩🇪DE