dbt

Kurzfazit

dbt (data build tool) ist der De-facto-Standard für Datentransformation im modernen Data Stack und hat den Begriff „Analytics Engineering” praktisch erfunden. Wer SQL-Modelle in Snowflake, BigQuery, Databricks oder Redshift baut, kommt an dbt fast nicht mehr vorbei — und sollte es auch nicht wollen. Die Idee ist bestechend einfach: Behandle SQL-Transformationen wie Software. Versioniere sie in Git, schreibe Tests, dokumentiere automatisch, deploye über CI/CD. dbt Core ist Open-Source unter Apache-2.0-Lizenz und kostet nichts. dbt Cloud liefert IDE, Scheduler, Semantic Layer und seit 2024 Copilot-Code-Generierung — aber zu Preisen, die seit der Restrukturierung 2024 spürbar gestiegen sind. Die Frage ist heute selten „dbt ja oder nein”, sondern „dbt Core selbst hosten oder dbt Cloud kaufen”.

Für wen ist dbt?

Analytics Engineers und Data Engineers: Das Kernpublikum. Wer in Snowflake, BigQuery, Databricks oder Redshift Datenmodelle baut, bekommt mit dbt das mit Abstand mächtigste Werkzeug für saubere, testbare und versionierte Transformationen. Viele Stellenausschreibungen für Analytics Engineers nennen dbt explizit als Skill — die Jobrolle ist von dem Tool praktisch nicht zu trennen.

Data-Teams in mittleren und großen Unternehmen: Sobald mehr als zwei Personen am Datenmodell arbeiten, wird Versionierung und Code-Review unverzichtbar. dbt erzwingt diese Disziplin elegant — Pull Requests gegen Datenmodelle, automatische Tests vor dem Merge, klare Lineage zwischen Quellen und Ableitungen. Das ist der Hebel, mit dem man aus „Stored Procedures im Wildwuchs” eine wartbare Datenplattform macht.

ML- und KI-Teams für Feature-Pipelines: Auch wenn dbt selbst keine KI ist, spielt es im KI-Ökosystem eine zentrale Rolle. Feature-Stores für ML-Modelle werden in der Regel als dbt-Modelle implementiert — saubere Trennung zwischen Datenvorbereitung und Modellschicht. Wer mit Snowflake oder Databricks ML-Pipelines baut, baut die Featurelogik typischerweise in dbt.

Teams mit BI-Tooling on top: dbt bereitet die saubere Datengrundlage, Tableau, Power BI, Looker oder Metabase visualisieren darauf. Der dbt Semantic Layer (in Cloud-Plänen) macht Metriken im BI-Tool konsistent — eine Definition von „Umsatz” für alle Reports.

Open-Source-Verfechter und souveränitätsbewusste Teams: dbt Core unter Apache 2.0 läuft komplett selbst gehostet — auf einer Build-Maschine, in Apache Airflow, in einem Container, im eigenen CI/CD-System. Keine Cloud-Abhängigkeit, kein Vendor-Lock-in, voller Funktionsumfang für Transformation und Tests.

Weniger geeignet für: Teams ohne SQL-Kenntnisse oder ohne Cloud-Warehouse, klassische On-Prem-Setups mit Stored Procedures auf Oracle/SQL Server (technisch möglich, aber selten sinnvoll), Echtzeit-Streaming-Anwendungen (Materialize, Flink oder RisingWave passen besser) und alle, die ein End-to-End-Tool für Ingest, Transformation, Orchestrierung und Visualisierung in einem suchen.

Preise im Detail

Plan	Preis	Was du bekommst
dbt Core	0 € (Apache 2.0)	Vollständige Transformation, Tests, Dokumentation, Lineage. Self-Hosted, eigene Orchestrierung
dbt Cloud Developer	0 USD	1 Sitz, 3.000 erfolgreiche Modelle/Monat, 1 Projekt, Browser-IDE, Scheduler, MFA
dbt Cloud Starter	100 USD/Sitz/Monat	5 Sitze, 15.000 Modelle/Monat, 5.000 Metric-Queries, 1 Projekt, Catalog (Basic), Semantic Layer (Basic), Copilot, API
dbt Cloud Enterprise	Auf Anfrage	Custom Sitze, 100.000 Modelle/Monat, 20.000 Metric-Queries, bis 30 Projekte, Advanced Catalog, dbt Canvas, dbt Insights, Cost Optimization, dbt Mesh
dbt Cloud Enterprise+	Auf Anfrage	Enterprise + PrivateLink, IP-Restrictions, Rollback, Hybrid-Projekte, unlimited Projekte

Einordnung: dbt Core deckt für viele Teams 90 % des praktischen Funktionsumfangs ab — Modelle, Tests, Lineage, Dokumentation. Wer ein Orchestrierungs-Tool wie Airflow, Prefect oder Dagster ohnehin betreibt, kann dbt Core dort einbinden und spart die Cloud-Kosten komplett. Astronomer Cosmos macht die Airflow-dbt-Integration besonders schmerzarm. dbt Cloud lohnt sich, wenn du keine eigene Orchestrierung hast, Browser-IDE für nicht-Engineers brauchst, den Semantic Layer in BI-Tools nutzen willst oder Enterprise-Funktionen (SSO, Mesh, Cost Optimization) brauchst. Die Restrukturierung 2024 hat die Preise spürbar erhöht — ein Starter-Sitz für 100 USD/Monat ist deutlich teurer als der frühere Team-Plan. Für 5-Personen-Data-Teams sind das 6.000 USD/Jahr; bei 10 Sitzen 12.000 USD/Jahr. Ab dieser Größenordnung ist Self-Hosting wirtschaftlich attraktiv, sofern Engineering-Kapazität vorhanden ist.

Stärken im Detail

Software-Engineering-Disziplin für SQL. Vor dbt waren Datenmodelle oft eine Sammlung von Stored Procedures, Views und ad-hoc-Skripten ohne Versionierung. dbt etabliert: Jede Transformation ist eine .sql-Datei in Git, jeder Change ein Pull Request, jede Änderung läuft durch automatische Tests, jedes Deployment ist nachvollziehbar. Das klingt selbstverständlich, war es im SQL-Bereich aber lange nicht. dbt hat diese Praxis im Markt durchgesetzt.

Apache 2.0 lizenziert, vollständig herstellerneutral. dbt Core ist Open-Source ohne Strings — du kannst es selbst hosten, in eigene Orchestrierung integrieren, in jeder Cloud betreiben, on-prem ausführen. Die Geschäftsstrategie von dbt Labs ist Cloud + Enterprise-Features, aber die Kernfunktionalität bleibt frei. Für souveränitätsbewusste Teams (Banken, Behörden, Versicherungen) ist das ein nicht zu unterschätzender Faktor.

Adapter für alle relevanten Warehouses. Snowflake, BigQuery, Databricks, Redshift, Postgres, MySQL, Microsoft Fabric, DuckDB, ClickHouse, Trino — über 30 offizielle und Community-Adapter decken praktisch jedes Warehouse ab, das im Data Stack zählt. Du wechselst die Datenbank, dbt läuft weiter. Das ist eine Vendor-Lock-in-Versicherung, die in der Praxis selten gezogen wird, aber Verhandlungspositionen verbessert.

Automatische Lineage und Dokumentation. dbt generiert aus dem Code automatisch eine vollständige Datenlineage: Welches Modell hängt von welchen Quellen ab, welche Spalten werden wie abgeleitet, was passiert nach unten. Die generierte HTML-Doku ist navigierbar und immer aktuell — kein doppelter Pflegeaufwand zwischen Code und Confluence. Für Data Governance, Audit und Onboarding ein massiver Hebel.

Test-Framework als first-class citizen. Schema-Tests (unique, not_null, accepted_values, relationships) sind out-of-the-box, Custom-Tests werden als SQL geschrieben, und seit dbt 1.8 (Mai 2024) gibt es echte Unit Tests für Transformationen — du kannst Modelle gegen synthetische Eingaben prüfen, bevor sie produktiv laufen. Das ist Software-Testing-Standard, im SQL-Bereich aber Pioniertat.

dbt Hub mit hunderten Paketen. Das Package-System erlaubt, fertige Transformationsmodule zu installieren — dbt_utils für Standard-Macros, dbt_expectations für umfangreiche Datenqualitätstests, fertige Modelle für Stripe-, Salesforce-, HubSpot- oder Mixpanel-Daten. In vielen Projekten ersetzt das Wochen an Eigenentwicklung.

Schwächen ehrlich betrachtet

Nur Transformation, sonst nichts. dbt deckt das „T” in ELT ab — Transformation. Ingest (Daten ins Warehouse holen) übernimmt es nicht (dafür Fivetran, Airbyte, Stitch oder eigene Skripte). Orchestrierung über mehrere Tools hinweg übernimmt es nicht (dafür Airflow, Prefect, Dagster — oder dbt Cloud Scheduler für reine dbt-Läufe). Visualisierung übernimmt es nicht (dafür BI-Tools). dbt ist ein Baustein, kein Komplett-Stack — wer ein End-to-End-Tool sucht, sollte das wissen.

SQL-only in Core, Python nur in Cloud. Python-Modelle (für komplexe Transformationen oder ML-Featurelogik) sind in dbt Core nicht verfügbar — nur in dbt Cloud auf bestimmten Warehouses (Snowflake, Databricks, BigQuery). Wer Python in der Transformationsschicht braucht und Self-Hosting bevorzugt, hat hier eine echte Lücke. Workaround: Python-Transformationen außerhalb von dbt orchestrieren, Ergebnisse als Tabellen ablegen, dbt darauf aufsetzen.

Cloud-Pricing wurde 2024 spürbar teurer. dbt Labs hat 2024 die Pricing-Struktur restrukturiert — der frühere Team-Plan (50 USD/Sitz/Monat) wurde durch Starter (100 USD/Sitz) ersetzt, mit zusätzlichen Modell-basierten Limits. Für viele Bestandskunden war das eine Verdopplung. Das ist kommerziell nachvollziehbar (dbt Labs braucht Umsatz), erhöht aber den Druck, Self-Hosting ernsthaft zu prüfen. Wer ohnehin Airflow betreibt, hat den günstigeren Pfad.

Keine deutsche UI, keine deutschsprachige Doku. Wie bei den meisten Engineering-Tools ist alles englisch. Für deutsche Engineering-Teams meist akzeptabel, für Schulungen mit nicht-englischsprachigen Mitarbeitenden ein Faktor.

Jinja-Templating und Macros sind Lerngebiete. dbt nutzt Jinja als Template-Sprache für Macros, Refs und dynamische SQL. Das ist mächtig, aber für SQL-Anfänger nicht intuitiv — Konstrukte wie {{ ref('stg_orders') }} oder {% if target.name == 'prod' %} brauchen Einarbeitung. Erfahrene Engineers lernen das in Tagen, Quereinsteiger eher in Wochen.

Enterprise-Features hinter Cloud-Wand. dbt Mesh (Multi-Projekt-Orchestrierung), erweiterte Catalog-Funktionen, Cost Optimization und der vollständige Semantic Layer sind nur in dbt Cloud Enterprise verfügbar — nicht in Core. Wer diese Features haben will, hat keinen Self-Hosting-Pfad. Das ist eine bewusste kommerzielle Entscheidung, aber für souveränitätsbewusste Großkunden manchmal ein Bruch.

Alternativen im Vergleich

Wenn du…	…nimm stattdessen
Eine Plattform mit Spark, ML und Datentransformation aus einer Hand willst	Databricks
Snowflake-native Transformation und KI-Features brauchst	Snowflake
Workflow-Orchestrierung um dbt herum brauchst	Apache Airflow
Sehr große SQL-Pipelines auf BigQuery mit ML direkt im Warehouse willst	BigQuery ML
Visuelle Datenmodellierung per Klick brauchst	Matillion oder Coalesce (keine eigene Tool-Seite)

Erwähnenswert ohne eigene Tool-Seite: SQLMesh (jüngerer Open-Source-Konkurrent mit interessantem virtuellen Data Environment), Dataform (von Google übernommen, BigQuery-fokussiert, gratis), Coalesce (visueller Snowflake-Konkurrent mit Code-Generierung), Matillion (klassische ETL/ELT-Plattform mit visuellem Editor). dbt bleibt im Markt der Default für SQL-Transformation — die meisten Konkurrenten positionieren sich explizit gegen dbt oder als Spezialfall darüber hinaus. Für die nächsten Jahre ist dbt der sichere Standard, an dem sich alles andere messen lassen muss.

So steigst du ein

Schritt 1: Lokal mit dbt Core und einem Demo-Projekt starten. Installiere dbt per pip install dbt-snowflake (oder den passenden Adapter) und initialisiere mit dbt init ein Projekt. Verbinde es mit deinem Warehouse, schreibe ein erstes Modell (select * from raw.orders where status = 'completed') und führe dbt run aus. Spätestens hier verstehst du das ref-Konzept, die Materialisierung als Table/View/Incremental und die generierte Lineage.

Schritt 2: Tests, Quellen und Dokumentation aufsetzen. Definiere sources.yml für deine Rohdaten, schreibe Schema-Tests in schema.yml (unique auf IDs, not_null auf Pflichtfeldern, relationships für Foreign Keys). Generiere die Doku mit dbt docs generate && dbt docs serve und schaue dir die Lineage im Browser an. Das ist der Moment, in dem die meisten Teams verstehen, warum dbt einen Unterschied macht.

Schritt 3: Cloud oder Self-Hosting entscheiden. Spätestens vor dem produktiven Einsatz ehrlich rechnen: Was kostet dbt Cloud Starter (100 USD/Sitz × Anzahl Sitze × 12 Monate) versus Self-Hosting in vorhandener Airflow- oder CI/CD-Infrastruktur? Bei kleineren Teams ohne Engineering-Kapazität gewinnt Cloud, bei größeren Teams mit eigener Orchestrierung typischerweise Self-Hosting. Mittelweg: dbt Core in Airflow integrieren (Astronomer Cosmos), dbt Cloud Developer (gratis) für die Browser-IDE der Analytics-User.

Ein konkretes Beispiel

Ein deutsches SaaS-Unternehmen aus Berlin (95 Mitarbeitende, B2B-Plattform für HR-Software) hat seinen Data Stack 2025 auf dbt Core in Snowflake umgestellt. Vorher: Eine Sammlung von Stored Procedures und ad-hoc-SQL-Views, die niemand mehr verstand und die regelmäßig stillschweigend falsche Zahlen lieferten. Nachher: 180 dbt-Modelle in einem Git-Repository, mit Schema-Tests, Unit Tests, automatischer Lineage und CI/CD über GitHub Actions. Orchestriert wird über Airflow auf Astronomer in Frankfurt — eine Airflow-DAG triggert nach jedem Fivetran-Sync den passenden dbt-Subtree. Die Datenmodelle füttern ein Tableau-Dashboard und einen Snowflake-Cortex-basierten internen KI-Chatbot (Snowflake-Cortex-Funktionen direkt im Warehouse), der „Frag dein Data Warehouse”-Queries für das Vertriebsteam beantwortet. Effekt: Datenfehler in Reports sind quasi verschwunden — Tests fangen sie vor dem Deployment ab. Onboarding neuer Analysten dauert statt zwei Monate jetzt zwei Wochen, weil die Lineage-Doku selbsterklärend ist. Das vierköpfige Data-Team hat dbt Core selbst aufgesetzt; gespart wurden ca. 8.000 USD/Jahr gegenüber dbt Cloud Starter, kein zusätzlicher Aufwand für Engineering, weil Airflow ohnehin schon lief.

DSGVO & Datenschutz

• Datenhosting (dbt Core): Vollständig in deiner Hand. dbt selbst speichert keine Nutzdaten — die Transformationen laufen in deinem Warehouse (Snowflake, BigQuery, Databricks, Redshift), wo deine Daten ohnehin liegen. Self-Hosted: läuft, wo du es betreibst.
• Datenhosting (dbt Cloud): Region wählbar — US (Standard), EMEA (Frankfurt für Multi-Tenant Cloud) und APAC. Für DSGVO-Einsätze EMEA-Region wählen. Single-Tenant- und VPC-Optionen in Enterprise+ verfügbar.
• Datennutzung: dbt Cloud verarbeitet ausschließlich Metadaten (Modell-Definitionen, Lauf-Status, Logs) — keine Nutzdaten verlassen dein Warehouse. Diese saubere Architektur ist ein DSGVO-Vorteil gegenüber Tools, die Daten zur Transformation aus dem Warehouse extrahieren.
• Auftragsverarbeitung (AVV): Für dbt Cloud Team und Enterprise verfügbar — Standardgeschäft mit dbt Labs. Bei Self-Hosting irrelevant.
• Sensible Daten: Modell-Definitionen liegen im Git-Repository — keine personenbezogenen Daten oder Credentials in SQL-Dateien committen. Secrets über Umgebungsvariablen, dbt-Profiles oder Secret-Manager des Warehouses verwalten.
• Empfehlung für DSGVO-sensible Branchen: dbt Core selbst hosten ist der sauberste Pfad — dbt Labs sieht keine Daten oder Metadaten. Bei dbt Cloud zwingend EMEA-Region wählen und Datenschutz-Folgenabschätzung dokumentieren. Da die Daten ohnehin nur im Warehouse verarbeitet werden, hängt die DSGVO-Compliance primär an Warehouse-Auswahl und -Region.

Gut kombiniert mit

• Apache Airflow — Airflow orchestriert übergreifend (Trigger nach Fivetran-Sync, Abhängigkeiten zu ML-Trainings), dbt führt die Transformation aus. Astronomer Cosmos macht die Integration besonders elegant: Jedes dbt-Modell wird automatisch zu einer Airflow-Task mit Lineage. Ein Standard-Setup im Modern Data Stack.
• Databricks — dbt-databricks-Adapter erlaubt, Transformationen direkt auf dem Lakehouse auszuführen. Saubere Trennung: dbt für SQL-Transformation auf der Gold-Layer, Databricks für Spark-basierte Heavy-Lifting auf der Bronze/Silver-Schicht.
• Snowflake — dbt bereitet die strukturierten Daten und Feature-Tabellen, Snowflake (mit Cortex-Funktionen) liefert LLM- und ML-Funktionen direkt im Warehouse. Beispiel: dbt erzeugt ein sauberes customer_360-Modell, eine Cortex-Funktion nutzt es für Klassifikation oder semantische Suche — ohne dass Daten das Warehouse verlassen.

Unser Testurteil

dbt verdient 5 von 5 Sternen. Es ist nicht nur ein gutes Werkzeug — es hat einen ganzen Berufszweig (Analytics Engineering) und eine ganze Disziplin (versionierte SQL-Transformation) im Markt etabliert. dbt Core ist Open-Source unter Apache 2.0, läuft auf allen relevanten Warehouses, hat ein riesiges Ökosystem und ist in der praktischen Tagesarbeit beneidenswert effektiv. Den fünften Stern verdient es trotz der teurer gewordenen Cloud-Variante, weil der Open-Source-Pfad ungebrochen vollständig ist. Wer heute ein modernes Data Warehouse aufbaut und dbt nicht zumindest evaluiert, sollte sehr gute Gründe nennen können. Für KI- und ML-Teams ist es zwar kein KI-Tool im engeren Sinn, aber das Rückgrat sauberer Featurelogik — und damit eine Grundvoraussetzung für seriöse ML-Pipelines, die sich nicht in Datenchaos verlieren.

Was wir bemerkt haben

• Mai 2024 — dbt 1.8 brachte echte Unit Tests für Modelle. Damit wurde das Test-Framework von „Schema-Validierung in Produktion” zu „Software-Tests gegen synthetische Daten vor dem Deployment” erweitert — eine seit Jahren erwartete Funktion, die das Tool in der Reife einen Schritt nach vorn gebracht hat.
• 2024 — dbt Labs hat die Cloud-Pricing-Struktur restrukturiert: Der frühere Team-Plan für 50 USD/Sitz/Monat wurde durch Starter für 100 USD/Sitz ersetzt, zusätzlich kamen Modell- und Metric-basierte Limits hinzu. Für viele Bestandskunden war das faktisch eine Verdopplung. Die Diskussion in der Community war lebhaft — viele Teams haben daraufhin Self-Hosting (mit Airflow oder Dagster) ernsthaft geprüft.
• 2024 — Mit dbt Mesh haben dbt Labs eine Multi-Projekt-Architektur eingeführt, die für große Konzerne mit dezentralen Datenteams gedacht ist. Funktion ist exklusiv für Cloud Enterprise — bewusste Strategie, kommerzielles Premium über Open-Source zu legen.
• 2024–2025 — dbt Copilot wurde in dbt Cloud eingebaut: KI-Code-Assistenz für SQL-Modelle, Test-Generierung und Dokumentation. Funktional vergleichbar mit GitHub Copilot, aber dbt-spezifisch trainiert. Verfügbar ab Starter-Plan.
• 2025 — SQLMesh hat als Open-Source-Konkurrent zu dbt Core spürbar Aufmerksamkeit gewonnen — virtuelle Data Environments, native Python-Modelle, bessere Performance bei sehr großen Projekten. Echte Marktverschiebung ist bisher nicht zu sehen, aber dbt hat erstmals einen ernsthaften Open-Source-Wettbewerber im SQL-Transformations-Bereich.
• Mai 2026 — Aktuelle stabile Version ist dbt 1.9.x. Der Open-Source-Pfad ist weiterhin vollständig nutzbar, das Ökosystem wächst weiter. Die Diskussion um Cloud-Pricing hat sich beruhigt, viele Teams haben sich für einen Mittelweg entschieden: dbt Core in eigener Orchestrierung, dbt Cloud Developer (gratis) für Browser-IDE der Analytics-User.