Was ist dbt? Der vollständige Guide für Data Engineers

Du bist neu in einem Data-Team, und jemand spricht ständig von "dbt models" in Pull Requests. Oder dein Warehouse hat 200 Views, und keiner weiß, welche noch genutzt werden. dbt (data build tool) ist das Framework, das SQL-basierte Datentransformation zu einer richtigen Engineering-Disziplin gemacht hat — mit Versionskontrolle, Tests und Doku eingebaut.

Dieser Artikel erklärt, was dbt wirklich macht, wie es unter der Haube funktioniert, wann es die richtige Wahl ist und wann nicht.

TL;DR

• dbt transformiert Daten, die bereits im Warehouse liegen, mit SQL-SELECT-Statements
• dbt Core ist Open Source und kostenlos; dbt Cloud ist Managed SaaS mit IDE und Scheduler
• Materializations: view, table, incremental, ephemeral — wähle nach Datengröße und Refresh-Frequenz
• Tests in YAML (unique, not_null, accepted_values) sind Pflicht für jedes Production-Modell
• Nicht für: Streaming, Python-/Spark-lastige Transformations, Teams ohne SQL-Kompetenz

Was ist dbt und warum existiert es?

dbt ist ein Open-Source-Command-Line-Tool, mit dem du bereits ins Warehouse geladene Daten mit SQL-SELECT-Statements transformierst. Du schreibst Models (SQL-Dateien), dbt kompiliert sie zu DDL/DML und führt sie in der korrekten Dependency-Reihenfolge gegen dein Warehouse aus.

Vor dbt bedeutete Datentransformation eines von drei Dingen:

• Stored Procedures, die niemand anfasste
• Python-Skripte, die Extraction, Loading und Transformation zu unwartbaren Blobs vermischten
• GUI-ETL-Tools, in denen Logik in Drag-and-Drop-Canvases lebte — unsichtbar für Versionskontrolle

dbt hat das Spiel verändert, indem es Software-Engineering-Praktiken — Git, CI/CD, Modularität, Testing — auf das T in ELT angewandt hat. Es extrahiert oder lädt keine Daten. Es transformiert nur, was schon im Warehouse ist.

Wie dbt funktioniert: Die Kernkonzepte

Models

Ein dbt-Model ist ein SQL-SELECT-Statement, gespeichert als .sql-Datei. dbt wrappt es in CREATE TABLE AS oder CREATE VIEW AS, abhängig von der Materialization-Config. Hier ein praktisches Beispiel — ein Staging-Model, das rohe Order-Daten säubert:

-- models/staging/stg_orders.sql
-- Dialect: Snowflake SQL (works similarly in BigQuery, Redshift, Postgres)

WITH source AS (
    SELECT * FROM {{ source('raw', 'orders') }}
),

cleaned AS (
    SELECT
        id                          AS order_id,
        user_id,
        TRIM(LOWER(status))         AS order_status,
        amount_cents / 100.0        AS order_amount_usd,
        created_at::timestamp       AS ordered_at
    FROM source
    WHERE id IS NOT NULL
)

SELECT * FROM cleaned

Die Functions {{ source() }} und {{ ref() }} sind Jinja-Macros, die dbt nutzt, um einen Dependency-Graph (DAG) deiner Models zu bauen. Führst du dbt run aus, läuft das Tool die Models in topologischer Reihenfolge — Upstream-Tabellen zuerst.

Materializations

dbt unterstützt out-of-the-box vier Materialization-Strategien:

Tests und Doku

dbt erlaubt Tests in YAML:

# models/staging/_stg_models.yml
models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: order_status
        tests:
          - accepted_values:
              values: ['pending', 'completed', 'cancelled', 'refunded']

Führ dbt test aus, und du bekommst Pass/Fail für jede Assertion. Das ist Tafelsalz für Data Quality — und etwas, was den meisten SQL-only-Workflows komplett fehlt.

dbt Core vs dbt Cloud

Das ist die erste Entscheidung, die jedes Team beim Evaluieren von dbt-Analytics-Engineering treffen muss. Ein ehrlicher Vergleich:

Wann dbt Core: Dein Team hat schon Orchestration (Airflow, Dagster), will volle Kontrolle und hat Engineers, die mit DevOps klarkommen. Kostensensible Teams profitieren auch — frei für immer.

Wann dbt Cloud: Du bist ein kleineres Team ohne dedizierte Platform-Engineers, willst schnelles Onboarding oder brauchst den Managed Semantic Layer. Die eingebaute CI spart allein schon erheblich Setup-Zeit.

Meine Einschätzung: Teams mit bestehenden Airflow- oder Dagster-Deployments bekommen mehr Wert aus dbt Core. Startest du von null und willst keine Infrastruktur managen, verdient dbt Cloud seinen Preis.

Ein praktisches dbt-Tutorial: Von Null zum ersten Model

Der schnellste Weg, dbt gegen ein Warehouse laufen zu lassen:

1. dbt Core installieren (mit deinem Warehouse-Adapter):

pip install dbt-snowflake  # or dbt-bigquery, dbt-postgres, dbt-redshift

2. Projekt initialisieren:

dbt init my_analytics
cd my_analytics

3. Warehouse-Verbindung konfigurieren in ~/.dbt/profiles.yml:

my_analytics:
  target: dev
  outputs:
    dev:
      type: snowflake
      account: xy12345.us-east-1
      user: "{{ env_var('DBT_USER') }}"
      password: "{{ env_var('DBT_PASSWORD') }}"
      database: ANALYTICS
      warehouse: TRANSFORM_WH
      schema: DEV_MARC
      threads: 4

4. Ein Model schreiben und laufen lassen:

dbt run --select stg_orders
dbt test --select stg_orders

Das war's. Du hast eine getestete, versionierte Transformation. Die dbt-Dokumentation deckt Adapter für jedes größere Warehouse ab.

Häufige Fallen

Aus der Arbeit mit dbt über mehrere Teams hinweg — das sind die Fallen, die ich am häufigsten sehe:

1. Das "One-Giant-Staging-Layer"-Anti-Pattern. Teams dumpen jede Source-Tabelle in ein Staging-Model, ohne zu überlegen, was Downstream wirklich braucht. Du endest mit 300 Staging-Models, von denen 40 referenziert sind. Audite deinen DAG regelmäßig mit dbt ls --resource-type model --select +marts.

2. Incremental Models zu früh nutzen. Incremental-Materializations bringen Komplexität — Merge Keys, Late-Arriving-Daten, Full-Refresh-Kadenz. Start mit table-Materialization. Wechsle auf incremental erst, wenn die Rebuild-Zeit tatsächlich zum Problem wird.

3. Keine Naming Conventions. Ohne Präfixe (stg_, int_, fct_, dim_) wird dein Projekt nach Monaten ein Labyrinth. Setz Conventions am ersten Tag und enforce sie mit dbt-project-evaluator.

4. Den ref()-Graphen ignorieren. Tabellennamen hardcoden statt {{ ref('model_name') }} zu nutzen, bricht dbts Dependency-Auflösung. Jede Cross-Model-Referenz sollte ref() nutzen — keine Ausnahmen.

5. Tests skippen, "weil die Daten okay aussehen". Sie sehen okay aus, bis sie es nicht tun. Minimum: Teste Primary Keys (unique, not_null) auf jedem Model. Das kostet 30 Sekunden pro Model und spart Stunden Debugging in Downstream-Dashboards.

6. Sources nicht nutzen. Definier deine rohen Tabellen als Sources mit Freshness-Checks. Ohne das hast du keine Sichtbarkeit, ob Upstream-Daten tatsächlich ankommen.

Wann dbt NICHT die richtige Wahl ist

dbt ist exzellent in dem, was es tut — aber nicht universell. Skip es, wenn:

• Deine Transformations primär Python/Spark sind. Bei ML-Feature-Engineering, komplexer Geo-Verarbeitung oder unstrukturierten Daten erzeugt dbts SQL-first-Ansatz Reibung. Ja, dbt unterstützt jetzt Python-Models, aber sie sind Bürger zweiter Klasse verglichen mit der SQL-Experience.

• Du hast kein Warehouse. dbt transformiert Daten innerhalb eines Warehouses. Wenn deine Daten in APIs, Flat Files oder App-DBs liegen und du sie erst bewegen musst, brauchst du ein Ingestion-Tool — nicht dbt.

• Dein Team kennt kein SQL. Klingt offensichtlich, aber dbts Wertversprechen setzt SQL-Kompetenz voraus. Ein Python-only-Team kämpft gegen das Paradigma statt davon zu profitieren.

• Du machst Real-Time-Streaming. dbt operiert im Batch-Modus. Brauchst du Sub-Sekunden-Latenz, schau auf Kafka Streams, Flink oder Materialize.

• Deine ganze Pipeline sind 3 Queries. dbts Projekt-Struktur, YAML-Config und Kompilierungsschritt bringen Overhead. Für trivial einfache Transformations ist ein scheduled SQL-Script ehrlich gesagt fine.

dbt im Modern Data Stack

dbt sitzt auf der Transformation-Schicht der Medallion-Architektur — speziell zwischen Raw/Bronze-Daten und den gesäuberten Silver/Gold-Schichten, die deine Analyst:innen abfragen. Es paart sich natürlich mit:

• Ingestion: Fivetran, Airbyte, custom API-Pipelines
• Orchestration: Airflow, Dagster, Prefect (für dbt Core)
• Warehouse: Snowflake, BigQuery, Redshift, Databricks, Postgres
• BI / Analytics: Looker, Metabase, Power BI — oder leichtgewichtige Tools für Ad-hoc-Exploration

Diese letzte Kategorie wird interessant. Sobald dbt saubere, getestete Tabellen in deinem Warehouse gebaut hat, muss jemand sie noch abfragen. Traditionelle BI-Tools funktionieren, aber manchmal willst du einfach ein Tool auf deine Daten richten und Fragen stellen. Harbinger Explorer macht genau das — du verbindest Datenquellen über den Source-Catalog, dann nutzt du Natural-Language-Queries oder schreibst SQL direkt im Browser via DuckDB-Engine, ohne einen vollen BI-Stack aufzusetzen.

Was kommt als nächstes für dbt?

Das dbt-Ökosystem entwickelt sich weiter. Der Semantic Layer (MetricFlow) zielt darauf, eine Single Source of Truth für Metric-Definitionen zu schaffen. Die Einführung von Python-Models erweitert dbt über reines SQL hinaus. Und das Mesh-Architektur-Pattern — wo Teams Models projektübergreifend publizieren und entdecken — adressiert die Skalierungsherausforderungen großer Organisationen.

Ob dbt dominant bleibt, hängt davon ab, wie gut es die Spannung zwischen Einfachheit (seine ursprüngliche Stärke) und Feature-Sprawl mit Enterprise-Adoption hinbekommt. Vorerst bleibt es der praktischste Weg, Engineering-Disziplin in SQL-basierte Datentransformation zu bringen.

Dein nächster Schritt: Wenn du dbt evaluierst, start mit dbt Core gegen ein Dev-Schema. Bau 5-10 Models nach dem Staging → Intermediate → Marts-Pattern. Innerhalb einer Woche weißt du, ob es zu deinem Team-Workflow passt.

FAQ

Brauche ich dbt Cloud oder reicht dbt Core?

Hast du schon einen Orchestrator (Airflow, Dagster) und ein CI/CD-Setup, reicht dbt Core. Bist du ein kleines Team ohne Platform-Engineering-Kapazität, zahlt sich dbt Cloud durch eingebaute Scheduler, IDE und Slim CI aus. Bei $100/Seat/Monat ist die Schwelle ab ca. 5-10 aktiven Analytics Engineers.

Welche Warehouses unterstützt dbt?

Alle gängigen: Snowflake, BigQuery, Redshift, Databricks, Postgres, MS SQL Server, DuckDB und mehr. Über Community-Adapter auch ClickHouse, Trino, SingleStore. Für DACH-Setups mit DSGVO-Anforderungen funktioniert dbt nahtlos gegen Snowflake EU-Frankfurt oder Postgres in eu-central-1.

Ersetzt dbt mein ETL-Tool?

Nein. dbt macht nur die T in ELT. Du brauchst trotzdem ein Ingestion-Tool (Fivetran, Airbyte, Custom) für die E und L. dbt nimmt an, dass die Rohdaten schon im Warehouse liegen.

Lohnt sich dbt für kleine Teams?

Ja, sogar besonders. Ein Solo-Analytics-Engineer mit dbt Core schlägt produktiv ein 3er-Team mit Stored Procedures. Die Investition in Setup zahlt sich nach 10-20 Models aus, weil Tests und Lineage Fehler abfangen, die sonst Stunden Debugging kosten.

Weiterlesen

• dbt Cloud vs dbt Core Kosten
• SCD Guide mit dbt Snapshots
• SQL Window Functions Tutorial

Stand: 15. Mai 2026.