dbt Fusion in der Praxis: Erfahrungsbericht und Migration

Im Februar 2026 stand in unserem internen Tech-Radar ein klarer Satz: "dbt Fusion ist nicht produktionsreif." Ende September haben wir trotzdem unser dbt-Template auf Fusion umgestellt, also die Vorlage, aus der wir jedes neue Datenprojekt aufsetzen (Ordnerstruktur, Konfiguration, Pakete, Style Guide). Jedes neue Projekt bei uns startet seitdem damit.

Widersprechen wir uns da? Nicht ganz. Beide Entscheidungen hatten damals gute Gründe. Hier steht, was Fusion im Alltag wirklich besser macht, warum unser erster Test schiefging, was eine Migration von dbt Core kostet und wann du besser noch wartest.

Was ist dbt Fusion?

dbt Fusion ist die neue Engine hinter dbt. dbt Labs hat sie von Grund auf neu geschrieben, in Rust statt in Python. Inzwischen spricht dbt Labs von "dbt v2": Wer dbt heute neu installiert, bekommt standardmäßig diese Version (dbt Docs).

Der wichtigste Unterschied steckt unter der Haube. dbt Core rendert dein Jinja zu SQL und schickt es an das Warehouse. Ob das SQL stimmt, merkst du erst, wenn das Warehouse einen Fehler zurückgibt. Fusion hingegen versteht SQL, es kennt Spalten, Typen und Abhängigkeiten, bevor irgendetwas läuft.

Praktisch für den Umstieg: Zum Ausprobieren installieren wir Fusion als eigenständiges Programm systemweit, nicht in der Python-Umgebung des Projekts. So läuft es problemlos neben einer bestehenden dbt-Core-Installation. Bei uns ruft der Befehl dbtf immer Fusion auf, dbt im aktiven venv weiterhin dbt Core. So kannst du beide an einem Projekt vergleichen, ohne etwas kaputt zu machen. Ist ein Projekt umgestellt, legen wir die Fusion-Version im Projekt selbst fest (mehr dazu bei der Migration).

Was Fusion im Alltag besser macht

Am meisten merken wir das schnellere Feedback beim Schreiben, mehr als die reine Geschwindigkeit. Vier Dinge fallen uns jeden Tag auf:

Fehler, bevor etwas läuft. Die offizielle dbt-Extension für VS Code markiert falsches SQL und kaputtes Jinja direkt im Editor. Ein vertippter Spaltenname fällt also beim Tippen auf, nicht nach drei Minuten Build. Die Extension braucht Fusion und ist kostenlos. Für einige Funktionen brauchst du ein ebenfalls kostenloses Konto bei dbt.
Vorschau und Lineage im Editor. Du kannst dir Modelle und einzelne CTEs direkt im Editor ansehen, dazu die Lineage bis auf Spaltenebene. Der Wechsel ins Warehouse für schnelle Kontrollabfragen wird seltener.
Schnelles Parsen. Zum Start hat dbt Labs mit bis zu 30-mal schnellerem Parsen geworben. Ehrlich gesagt war das Kompilieren bei uns selten der Engpass. Bei großen Projekten mit vielen Modellen spürst du den Unterschied aber, gerade in der CI.
Schnelles Feedback auch ohne Editor. Immer mehr Arbeit an dbt-Projekten passiert im Terminal, oft mit KI-Agenten wie Claude Code. Die statische Analyse von Fusion läuft auch bei dbtf compile. Ein Agent erfährt so in Sekunden, dass sein SQL nicht passt, ohne eine einzige Abfrage im Warehouse. Wichtig: Im Standardmodus baseline sind die Funde nur Warnungen. Typfehler erkennt Fusion erst im Modus strict.

Alte Projekte haben einen Haken: Die Fehlermarkierung folgt der aktuellen Syntax. Bei einem Repo auf einer alten dbt-Version wirst du anfangs mit Warnungen zugeschüttet. Das nervt, ist aber auch ein ziemlich deutlicher Hinweis, dass ein Update fällig ist.

Unser erster Test: schneller und langsamer zugleich

Im Februar 2026 haben wir Fusion an zwei Projekten ausprobiert. Das Ergebnis war widersprüchlich:

Projekt	dbt Core	dbt Fusion
jaffle_shop (Demo-Projekt von dbt Labs)	ca. 25 s	ca. 10 s
Unser internes Projekt auf Snowflake	ca. 20 s	ca. 120 s

Beim Demo-Projekt war Fusion mehr als doppelt so schnell. Bei unserem eigenen Projekt dauerte der Build sechsmal so lang.

Die Ursache war kein Fehler in unserem Code. Fusion hat damals die Einstellung threads für Snowflake ignoriert, als Teil seiner eigenen Performance-Optimierung. Es schickte also mehr Abfragen gleichzeitig ab, als wir eingestellt hatten. Unser kleines XS-Warehouse kam damit nicht hinterher, die Abfragen stauten sich. Mehr Parallelität hat das Ganze also langsamer gemacht.

Daher kam unser Urteil "nicht produktionsreif". Die wichtigere Lehre war aber eine andere: Benchmarks aus Blogposts sagen wenig über dein Projekt (auch die aus diesem).

Warum Fusion trotzdem unser Standard wurde

Zwischen Februar und September hat sich einiges geändert. Mitte September hat dbt Labs Fusion als dbt v2.0.0 offiziell freigegeben. Seitdem erscheinen stabile Releases statt Preview-Versionen.

Auch das Threads-Problem aus unserem Test ist gelöst. Wir hatten es im Februar bei dbt Labs gemeldet, und nach und nach kamen viele Nutzer mit demselben Problem dazu, auch auf BigQuery und Redshift. Seit Mai 2026 behandelt Fusion threads als Obergrenze (dbt Docs). Wer ein kleines Warehouse hat, kann die Parallelität also wieder begrenzen. Im November haben wir unseren Test mit denselben Einstellungen wiederholt. Diesmal war Fusion etwas schneller als dbt Core: rund 18 statt 22 Sekunden.

Und das Feedback im Editor lohnt sich jeden Tag, am meisten in der Einarbeitung. Wer neu im Team ist, sieht Fehler sofort und nicht erst im fehlgeschlagenen Build.

Unser neues internes Datenprojekt läuft komplett auf Fusion, auch die dbt-Jobs in unserem Airflow. Wir arbeiten also selbst mit dem, was wir unseren Kunden einrichten.

Migration von dbt Core zu Fusion: Aufwand und Stolperfallen

Wenn dein Projekt schon auf aktuellem dbt Core ohne Deprecation-Warnungen läuft, ist der Umstieg etwa so aufwendig wie ein normales Versions-Update. Genau das nennt dbt Labs auch als Voraussetzung. Fusion ist weitgehend rückwärtskompatibel. Bei älteren Projekten kommt zuerst die Arbeit, die du bei jedem größeren Update hättest. Unser Template sprang von 1.6 direkt auf Fusion. Diese Schritte waren nötig:

Versionsgrenze anpassen. In der dbt_project.yml steht jetzt require-dbt-version: ['>=2.0.0-preview', '<3.0.0'].
Testparameter umziehen. Parameter von generischen Tests gehören unter arguments:. Wir haben dazu die Flag require_generic_test_arguments_property: true gesetzt, damit alte Schreibweisen sofort auffallen.
tags und meta unter config: schieben. Auch das ist eine reine Syntaxänderung, betrifft aber fast jede yaml.
Pakete aktualisieren. dbt deps meldet, welche Pakete nicht kompatibel sind. Bei uns waren es dbt_utils (jetzt 1.4.1) und dbt_snowflake_monitoring (jetzt 5.x).
sql_header prüfen. Bei Snapshots, Seeds und Analysen bricht Fusion beim Parsen ab, wenn dort +sql_header gesetzt ist. Wir haben es dort entfernt. Für Modelle und Tests setzen wir die Zeitzone weiterhin per +sql_header in der dbt_project.yml.
Version im Projekt festlegen. Zum Testen reicht das Binary (curl, brew oder winget). Im umgestellten Projekt installieren wir Fusion per pip oder uv in die Python-Umgebung des Projekts, mit fester Version, denn das Paket dbt installiert inzwischen dbt v2. So steht die Version im Repo, und jede Änderung läuft über einen Pull Request. dbt Core und Fusion können sich allerdings keine Python-Umgebung teilen. Für den Vergleich nebeneinander bleibt deshalb das Binary der einfachere Weg.

Zwei Dinge haben wir erst später gelernt:

Pinne die Version überall gleich. Fusion entwickelt sich schnell. Bei einem Kunden hat das Release von Fusion 2.0 den CI-Build gebrochen. Wir legen die Version deshalb fest, und zwar lokal, in der CI und im Orchestrierungs-Image (bei uns Airflow) identisch. Am einfachsten geht das mit einer Lockfile im Repo, aus der alle drei installieren.
SQLFluff passt nicht direkt zu Fusion. Wenn dein Team stark auf SQLFluff setzt, plane hier Zeit ein. dbt Labs beschreibt in der Dokumentation mehrere Wege, aber keiner ist ein reines Plug-and-play.

Der Rest unserer Struktur, Ordner und Konventionen blieb gleich. Den Großteil eines Projekts musst du also nicht anfassen.

Wann du (noch) nicht wechseln solltest

Fusion ist für uns der neue Standard, aber nicht für jedes Projekt sofort die richtige Wahl. In diesen Fällen würden wir abwarten:

Dein Warehouse wird nicht unterstützt. Fusion läuft mit Snowflake, BigQuery, Databricks und Redshift, dazu DuckDB lokal. ClickHouse und Spark sind noch in der Beta. Postgres oder Microsoft Fabric fehlen derzeit (Stand November 2026).
Deine Tools lesen die Logs von dbt Core. Fusion schreibt andere Logs. Monitoring oder Skripte, die genau dieses Format erwarten, musst du anpassen.
Du brauchst Funktionen der dbt-Plattform, die v2 noch nicht kann, zum Beispiel Benachrichtigungen auf Modellebene.

Auch wenn dein Projekt passt: Teste zuerst nebenher. Weil Fusion neben dbt Core läuft, zeigt dir dbtf parse ohne Risiko, wie viel Migrationsarbeit vor dir liegt, bevor du die CI umstellst.

FAQ zu dbt Fusion

Ist dbt Fusion dasselbe wie dbt 2.0? Ja. Fusion ist die Engine, dbt Labs nennt die Version inzwischen dbt v2. dbt Core (v1) wird parallel weiter gepflegt.

Ist dbt Fusion kostenlos? Die Engine und die VS-Code-Extension kannst du kostenlos nutzen. Einige Funktionen brauchen ein kostenloses Konto bei dbt. Die Standard-Distribution von dbt v2 ist allerdings proprietär und steht unter der Lizenz von dbt Labs. Brauchst du zwingend Open Source, gibt es mit dbt-oss eine Apache-2.0-Variante auf derselben Rust-Engine, mit weniger Funktionen. dbt Core (v1) bleibt ebenfalls Apache 2.0.

Kann ich dbt Core und Fusion parallel nutzen? Ja. Installier Fusion als Binary systemweit und dbt Core wie gewohnt in deiner Python-Umgebung. Mit einem Alias wie dbtf rufst du gezielt Fusion auf.

Ist Fusion immer schneller als dbt Core? Nein. Das Parsen ist deutlich schneller, die Laufzeit eines Builds hängt aber auch von deinem Warehouse ab. In unserem ersten Test im Februar 2026 war Fusion auf einem kleinen Snowflake-Warehouse sechsmal langsamer, weil es die Einstellung threads ignorierte. Das ist seit Mai 2026 behoben. Stell threads passend zu deinem Warehouse ein und vergleiche selbst.

Lohnt sich Fusion, wenn ich mit KI-Agenten arbeite? Ja, vielleicht sogar mehr als im Editor. Ein Agent wie Claude Code prüft sein SQL mit dbtf compile in Sekunden und ohne Abfrage im Warehouse. Weil ein Agent pro Aufgabe oft dutzende Male kompiliert, zählt hier auch das schnelle Parsen. Im Standardmodus baseline sind die Funde nur Warnungen, die ein Agent leicht übersieht. Mit static_analysis: strict prüft Fusion gründlicher, zum Beispiel auch Datentypen.

Wie aufwendig ist die Migration? Wenn dein Projekt auf aktuellem dbt Core ohne Deprecation-Warnungen läuft, etwa so wie ein normales Versions-Update. Die meisten Änderungen betreffen Syntax in YAML-Dateien und Paketversionen. dbt Labs bietet außerdem Agent-Skills an, die einen Teil der Migration automatisieren.

Fazit: Testen, messen, dann umsteigen

Unser erster Eindruck von Fusion war schlecht, und er war damals berechtigt. Sieben Monate später ist Fusion unser Standard für neue Projekte. Den Ausschlag gaben nicht die Benchmarks, sondern die tägliche Arbeit, im Editor wie im Terminal, und die Erfahrung aus echten Projekten.

Wenn du über den Umstieg nachdenkst, fang klein an: Installier Fusion neben dbt Core und lass dbtf parse laufen. Nach ein paar Minuten weißt du, wie weit dein Projekt von Fusion entfernt ist. Vieles davon behebt dbt-autofix automatisch, der Rest sind meist die Stolperfallen von oben.

Du willst ein bestehendes dbt-Projekt migrieren oder eine neue Datenplattform direkt auf Fusion aufsetzen? Sprich mit uns, wir sind diesen Weg schon mehrfach gegangen.