dbt Core und Cloud Adopt
Überblick
dbt (data build tool) modelliert Analytics-Transformationen als Software: modulares SQL, Packages, Tests und aus Metadaten generierte Dokumentation. dbt Core läuft lokal und in CI; dbt Cloud, inzwischen dbt platform genannt, ergänzt Orchestrierung, Job-Observability und den MetricFlow-gestützten Semantic Layer für konsistente Business-Metriken (dbt Dokumentation). Seit September 2026 ist die Engine dbt v2 (die frühere Fusion Engine): Die vollständige Distribution heißt „dbt“, ihr Apache-2.0-Subset „dbt OSS“, der Name dbt Core gilt nur noch für die v1.x-Linie (dbt licensing FAQ).
Adopt für Teams, die kuratierte Tabellen in Cloud Warehouse oder Lakehouse bauen und reproduzierbare Pipelines, PR-Review für Datenlogik und Verträge zwischen Analytics Engineering und AI- oder BI-Konsumenten brauchen.
Adoptionssignale
- Fivetran und dbt Labs haben ihre Fusion per Aktientausch am 1. Juni 2026 abgeschlossen; das gemeinsame Unternehmen nennt mehr als 100.000 Data Teams, darunter OpenAI, Zendesk, Coupa und HubSpot (dbt Labs).
- dbt v2, die Rust-basierte Fusion Engine unter dem neuen Namen „dbt“, ist seit 16. September 2026 allgemein verfügbar; dbt Labs nennt ein Projekt mit 10.000 Nodes, das in 17 statt 70 Sekunden (dbt 1.12) kompiliert (dbt blog).
- Die Open-Source-Linie bleibt: Das „dbt OSS“-Subset von v2 und dbt Core v1.x stehen unter Apache 2.0, MetricFlow als Engine des Semantic Layer wurde im Oktober 2025 auf Apache 2.0 umlizenziert (dbt licensing FAQ).
- 44 % der Befragten in Astronomers State of Airflow 2026 nutzen dbt zusammen mit Airflow (Astronomer).
Risiken
- Ungetestete inkrementelle Models können Zeilen still duplizieren oder verlieren.
- Zu breite Warehouse-Rollen in CI-Service-Accounts vergrößern den Blast Radius.
- Metrikdefinitionen ohne Owner reproduzieren widersprüchliche KPIs.
- Package-Version-Drift zwischen Projekten erschwert zentrale Upgrades.
- Lizenz-Split in v2. Funktionen außerhalb von dbt OSS stehen unter dem proprietären dbt Product Licensing Agreement; wer eine vollständig quelloffene Toolchain braucht, muss prüfen, welche v2-Funktionen genutzt werden (dbt licensing FAQ).
Vorteile & Nachteile
Vorteile
- Versionskontrollierte SQL-Transformationen mit Tests, Dokumentation und Lineage sind De-facto-Standard für Warehouse Analytics.
- Die dbt platform (früher dbt Cloud) ergänzt Scheduling, Observability und Semantic-Layer-APIs für governete Metrik-Nutzung.
- Adapter-Ökosystem umfasst Snowflake, Databricks, BigQuery, Redshift und offene Lakehouse-Engines.
Nachteile
- Komplexe Jinja-Macros werden ohne Style Guides und Code Review schwer debuggbar.
- Semantic-Layer-Adoption braucht organisatorische Einigung über Metrikdefinitionen und Owner.
- Große Projekte ohne CI-Performance-Tuning liefern langsames Merge-Feedback.
Empfehlung
dbt ist der Transformation Layer für Warehouse- und Lakehouse-Analytics (Adopt), mit Pflicht-Tests auf inkrementellen Models und dokumentierten Ownern pro Semantic Metric. Die dbt platform (früher dbt Cloud) eignet sich für zentrales Scheduling und Observability; bei Kosten- oder Residency-Anforderungen bleiben dbt OSS oder Core plus Orchestrator die Wahl. Bestehende Projekte sollten vor dem Wechsel gegen dbt v2 getestet werden, da der eingebaute SQL-Compiler Fehler schon vor der Ausführung meldet, die dbt 1.x erst im Warehouse sichtbar machte.
Quellen
Beratung
Vom Radar zur Umsetzung
Du hast Technologien bewertet — wir helfen dir, sie sicher und messbar in produktive Systeme zu bringen.
