Fivetran und dbt Labs schließen Fusion ab – auf dem Weg zur agentenfähigen Datenplattform

Wer schon einmal einen Sonntagabend damit verbracht hat, eine defekte ELT-Pipeline zu reparieren, weiß: Der moderne Data Stack hat zwei tragende Wände – Ingestion und Transformation. Seit dem 5. Juni gehören beide Wände demselben Eigentümer. Fivetran und dbt Labs haben ihre All-Stock-Fusion abgeschlossen, acht Monate nach der Ankündigung – und sie wollen das Standard-Substrat für KI-Agenten werden, die tatsächlich auf Produktionsdaten zugreifen.

Was passiert ist

Der Deal wurde erstmals im Oktober 2025 bekannt und, wie Pulse 2.0 berichtete, am 5. Juni 2026 als All-Stock-Transaktion abgeschlossen. Das fusionierte Unternehmen firmiert unter Fivetran + dbt Labs. George Fraser bleibt CEO. Tristan Handy übernimmt den Posten des President. Beide behalten ihre Mitgründer-Titel im neuen Organigramm.

Die Botschaft ist klar: Fivetran übernimmt die Datenbewegung und -synchronisierung, dbt die Transformation, Governance und semantische Modellierung – und gemeinsam bedienen sie nach eigenen Angaben mehr als 100.000 Datenteams weltweit. Das ist ein ernsthafter Distributionsvorteil. Am ersten Tag veröffentlichte das Unternehmen zudem eine Produktpalette, die zeigt, wohin die Engineering-Energie fließt.

Die Highlights: eine Alpha-Version von dbt Core v2.0, die die dbt Fusion Engine Runtime unter Apache 2.0 als Open Source freigibt. Ein neues Caching-Layer namens dbt State, das nur geänderte Assets neu erstellt, um Infrastrukturkosten zu senken. dbt Wizard, ein KI-Assistent zum Erstellen, Debuggen und Refaktorieren von Modellen. Und Agents Schema, ein Open-Source-Standard, der semantische Modelle, Metriken, Lineage und Business-Dokumentation in SQL-Tabellen speichert, die KI-Agenten abfragen können – bei voller Kompatibilität mit bestehender Governance.

Zu den genannten Referenzkunden zählen Zendesk, Inova Health, Tinuiti, Shutterstock und DocuSign. Der große Auftritt folgt beim Snowflake Summit 2026, wo die gemeinsame Plattform erstmals auf einer großen Bühne präsentiert wird. Fraser formulierte die Wette unverblümt: „Die nächste Generation von Enterprise-KI wird durch die Qualität und Vertrauenswürdigkeit der zugrundeliegenden Daten definiert." Handy war noch direkter: Vertrauen entsteht auf der Infrastrukturebene, auf offenen Standards.

Technische Analyse

Hinter den PR-Texten verbergen sich vier Engineering-Maßnahmen, die es sich zu analysieren lohnt.

Erstens: die Apache-2.0-Lizenzierung der dbt Fusion Engine Runtime in dbt Core v2.0. Fusion war das Rust-Rewrite, das dbt Labs einführte, um den Python-Parser zu ersetzen. Die Veröffentlichung der Runtime unter Apache 2.0 ist bedeutsam. Cloud-Anbieter und Wettbewerber können darauf aufbauen, ohne Lizenzgebühren zu zahlen – aber dbt selbst kann später keinen Redis- oder Elastic-artigen Relicense mehr durchführen. Das ist ein Glaubwürdigkeitssignal für Platform-Engineers, die schon einmal die Erfahrung gemacht haben, dass ein „source-available"-Anbieter seine Meinung geändert hat. Wer langfristige Verpflichtungen plant, sollte die eigentliche dbt-Dokumentation zu Fusion lesen, bevor er davon ausgeht, dass die OSS-Haltung alle Komponenten abdeckt.

Zweitens: dbt State als Caching-Layer. Nur geänderte Assets neu zu bauen ist kein neuer Gedanke – wer schon einmal --defer und State-Vergleiche eingerichtet hat, kennt das Muster. Der interessante Teil ist die Produktivierung als erstklassiges Caching-Layer. Bei großen dbt-Projekten können vollständige Rebuilds die Warehouse-Kosten dominieren. Wenn State hält, was es verspricht, zeigen sich die Einsparungen direkt auf der Snowflake- oder BigQuery-Rechnung.

Drittens: Agents Schema. Das ist das strategisch gewichtigste Element. Indem dbt standardisiert, wie semantische Modelle, Metriken und Lineage in SQL-Tabellen gespeichert werden, versucht das Unternehmen, den Kontext-Layer zu besitzen, den KI-Agenten lesen, bevor sie handeln. Das ist derselbe Instinkt, der den ursprünglichen Semantic-Layer-Push angetrieben hat – jetzt aber auf LLM-gesteuerte Konsumenten statt auf BI-Dashboards ausgerichtet.

Viertens: die cloud-agnostische Positionierung. Die gemeinsame Plattform wird als auf offenen Standards basierend und ohne Vendor-Lock-in vermarktet. Meine Einschätzung: Das ist ein direkter Angriff auf Databricks und Snowflake, die beide darum wetteifern, ihre eigenen Walled-Garden-Semantic-Layer durchzusetzen. Fivetran + dbt setzt darauf, dass Platform-Engineers die Abstraktion lieber selbst besitzen, als sie von einem Warehouse-Anbieter zu mieten.

Wer unter Druck gerät

Beginnen wir mit dem offensichtlichen Ziel: jede „KI-native Datenplattform" der Series B, die in den letzten 18 Monaten eine einheitliche Ingestion-plus-Transformation-Story präsentiert hat. Ihr TAM wurde soeben durch einen Anbieter mit 100.000 bestehenden Datenteams komprimiert. Verkaufszyklen, die ohnehin schon hart waren, werden noch schwieriger, wenn der Incumbent dieselbe Funktion kostenlos unter Apache 2.0 ausliefert.

Als nächstes: die Orchestrierungs-Anbieter, die zwischen Ingest und Transform sitzen. Wenn dbt Wizard sich vom Authoring hin zur Runtime-Orchestrierung ausdehnt und Agents Schema zum De-facto-Kontextstandard wird, schrumpft der Markt für eigenständige Metadaten- und Katalog-Anbieter. Produktionsvorfälle, die ich bei überlappenden Tools erlebt habe, lassen sich immer auf dieselbe Grundursache zurückführen: zu viele Systeme, die behaupten, Lineage zu besitzen, ohne dass eines davon autoritativ ist. Ein fusioniertes Fivetran + dbt kann diese Autorität standardmäßig beanspruchen.

Für Platform-Teams im iGaming- und Fintech-Bereich ist die Exposition eine andere. Diese Branchen betreiben umfangreiche regulatorische Reporting-Workloads auf dbt-Projekten, oft mit maßgeschneiderter Ingestion. Die Fusion bedeutet, dass eine einzige Anbieterbeziehung nun zwei bisher unabhängige Vertragsflächen überspannt. Der Beschaffungsaufwand sinkt. Der Preisdruck bei Verlängerungen steigt. Teams, mit denen ich gearbeitet habe, unterschätzen regelmäßig, wie schnell ein Anbieter die Preisgestaltung nach einem Akquisitionsabschluss konsolidiert.

Die unangenehme Lesart: dbt Cloud-Kunden, die für gehostete Transformation zahlen, teilen jetzt eine Roadmap mit Fivetrans Connector-Geschäft – und Fivetrans MAR-basiertes Preismodell war historisch gesehen die unbeliebteste Rechnungsposition im modernen Data Stack. Wenn diese beiden Preismodelle in irgendeiner Richtung konvergieren, bricht jemandes Budget. Senior-Engineers sollten davon ausgehen, dass der nächste Verlängerungszyklus ein gebündeltes SKU beinhalten wird, und das jetzt schon einkalkulieren.

Snowflake und Databricks beobachten die Entwicklung mit Bedacht. Sie profitieren von günstigeren, besseren Transformationen, die mehr Compute antreiben. Sie verlieren, wenn Agents Schema zum portablen Kontext-Layer wird, der Kunden ermöglicht, Workloads zwischen Warehouses zu verschieben, ohne Semantik neu zu schreiben.

Handlungsempfehlungen für Datenteams

Konkrete Maßnahmen für diese Woche – nicht für nächstes Quartal.

Wenn Ihr Team dbt Core in der Produktion betreibt, wechseln Sie nicht auf die v2.0-Alpha bei Systemen, die jemanden um 2 Uhr nachts anpiepen. Richten Sie eine parallele CI-Umgebung ein, führen Sie Ihr bestehendes Projekt gegen die Fusion Runtime aus und vergleichen Sie Kompilier- und Laufzeiten mit Ihrem aktuellen Setup. Alphas sind Alphas. Die Apache-2.0-Lizenz ist hier die eigentliche Neuigkeit, nicht die Produktionsreife.

Wenn Sie dbt Cloud nutzen, ziehen Sie Ihre letzten zwölf Monate an Rechnungen und Ihren Fivetran-MAR-Trend in dieselbe Tabelle. Modellieren Sie, wie ein gebündelter Vertrag bei der Verlängerung aussieht. Sie wollen diese Zahl kennen, bevor der Account Executive sie Ihnen präsentiert – nicht danach.

Wenn Sie Agent-Workflows auf Snowflake oder einem anderen Warehouse aufbauen, evaluieren Sie Agents Schema als Kontextstandard, bevor Sie sich auf einen proprietären Semantic-Layer festlegen. Die Kosten für einen Wechsel des Kontext-Layers, nachdem Agenten in der Produktion sind, sind erheblich. Wählen Sie die Abstraktion, die einen Anbieterwechsel überlebt.

Für Platform-Leads in regulierten Branchen gilt: Dokumentieren Sie, welche Governance-Kontrollen derzeit in Fivetran und welche in dbt liegen. Nach der Fusion werden diese Kontrollen beginnen, zu konsolidieren. Den Ist-Zustand zu kennen ist die einzige Möglichkeit, den Soll-Zustand zu auditieren.

Behandeln Sie schließlich die Ankündigungen des Snowflake Summit 2026 als die eigentliche Produktpräsentation. Alpha-Versionen zeigen die Absicht. Summit-Demos zeigen, was auslieferbar ist.

Wichtigste Erkenntnisse

• Fivetran und dbt Labs haben ihre All-Stock-Fusion am 5. Juni 2026 abgeschlossen und vereinen Ingestion und Transformation in einem Unternehmen, das über 100.000 Datenteams bedient.
• dbt Core v2.0 Alpha veröffentlicht die Fusion Engine Runtime als Open Source unter Apache 2.0 – ein bedeutendes Commitment, das künftige Relicensing-Manöver verhindert.
• Agents Schema ist das strategisch entscheidende Element: ein SQL-nativer Kontext-Layer für KI-Agenten, der zum portablen Standard werden könnte, den Warehouse-Anbieter nicht kontrollieren.
• Rechnen Sie mit gebündeltem Preisdruck bei der Verlängerung. Modellieren Sie den kombinierten Vertrag jetzt, bevor Ihr Account-Team es tut.
• Betreiben Sie dbt Core v2.0 Alpha nicht in der Produktion. Benchmarken Sie in CI, warten Sie auf die Ankündigungen beim Summit 2026 und planen Sie dann ein Migrationsfenster.