dbt vs Spark SQL: Welches Tool für deinen Transformations-Layer?

Wer auf einem Lakehouse einen Transformations-Layer baut, steht früher oder später vor der dbt-vs-Spark-SQL-Frage. Die beiden optimieren nicht für dasselbe Problem, und die falsche Wahl bedeutet entweder Monate Maintenance-Schmerz oder verfehlte Skala. Dieser Vergleich zeigt, wo welches Tool passt, wann du sie kombinierst und wie die ehrlichen Trade-offs wirklich aussehen.

TL;DR (wenn du Eile hast)

• Wähl dbt, wenn dein Team in SQL denkt, du Built-in-Testing und -Doku willst, und dein Warehouse oder Lakehouse einen dbt-Adapter hat.
• Wähl Spark SQL, wenn du Skala-Anforderungen über das hinaus hast, was deine Warehouse-SQL-Engine effizient verarbeitet, oder wenn deine Transformationen von der Spark-DataFrame-API profitieren.
• Nimm beides, wenn du auf Databricks bist — viele Teams nutzen Spark SQL für schweres Heavy-Lifting und dbt für den Modeling-/Testing-/Doku-Layer obendrauf. Die Rollen überlappen sich nicht.

Was die Tools wirklich tun

dbt (data build tool) ist ein Transformations-Framework, keine Query-Engine. Es packt SQL-SELECT-Statements in einen DAG (Directed Acyclic Graph), führt sie gegen dein bestehendes Warehouse oder Lakehouse aus und addiert Testing, Doku und Lineage-Tracking on top. dbt führt selbst kein SQL aus — dein Warehouse tut es. Der Wert ist die Engineering-Disziplin um SQL herum, nicht das SQL selbst.

Spark SQL ist ein SQL-Dialekt, der auf Apache Spark läuft. Verarbeitet Daten verteilt über einen Cluster, unterstützt komplexe Aggregationen und Window-Funktionen und integriert tight mit PySpark und Scala. Du nutzt es in Notebooks, in Spark-Jobs oder über ein Databricks-SQL-Warehouse.

Die beiden lösen fundamental unterschiedliche Probleme: dbt ist Development-Workflow und Modeling-Layer; Spark SQL ist eine distributed Query-Execution-Engine. Das als direkten Wettbewerb zu framen, verkennt, wofür beide gebaut sind.

Feature-Vergleich

Preise

dbt Core ist Open Source und kostenlos. Self-Hosting braucht deinen eigenen Orchestrator (Airflow, Dagster oder ähnlich).

dbt Cloud (Stand: März 2026):

• Developer: kostenlos (1 Seat)
• Team: $100/Monat pro Seat
• Enterprise: Custom Pricing

Spark SQL — Kosten sind deine Spark-Infrastruktur:

• Databricks (Stand: März 2026): DBU-Pricing variiert je Cloud-Provider und Instance-Typ. Serverless-SQL-Warehouse-Pricing liegt ca. bei $0,25–$0,70/DBU je Region. Vollständig aktuell bei databricks.com/product/pricing.
• Apache Spark auf Self-Managed-Infrastructure: Du zahlst nur Compute und Storage.

Code-Beispiele

dbt-Model — Incremental Strategy

-- models/marts/fct_orders_daily.sql
-- SQL dialect: dbt with Databricks adapter (Spark SQL under the hood)
-- Incrementally processes new orders, merging on order_id

{{
  config(
    materialized='incremental',
    unique_key='order_id',
    incremental_strategy='merge',
    partition_by={'field': 'created_date', 'data_type': 'date'}
  )
}}

with source_orders as (
    select
        order_id,
        customer_id,
        order_status,
        total_amount,
        date(created_at) as created_date,
        created_at
    from {{ ref('stg_orders') }}

    {% if is_incremental() %}
        -- Only process records newer than the current max in the target
        where created_at > (select max(created_at) from {{ this }})
    {% endif %}
),

enriched as (
    select
        o.order_id,
        o.customer_id,
        c.customer_segment,
        o.order_status,
        o.total_amount,
        o.created_date
    from source_orders o
    left join {{ ref('dim_customers') }} c
        on o.customer_id = c.customer_id
)

select * from enriched

Äquivalent in Spark SQL (PySpark)

# spark_jobs/transform_orders_daily.py
# SQL dialect: Spark SQL
# Equivalent logic to the dbt model above — merge-based incremental load
# No DAG management, no testing framework — those you wire separately

from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("orders-daily-transform").getOrCreate()

# Equivalent to stg_orders — read from staging table
# Incremental filter: only records newer than current max in target
source_orders = spark.sql("""
    SELECT
        order_id,
        customer_id,
        order_status,
        total_amount,
        CAST(created_at AS DATE) AS created_date,
        created_at
    FROM catalog.staging.stg_orders
    WHERE created_at > (
        SELECT COALESCE(MAX(created_at), '1970-01-01')
        FROM catalog.marts.fct_orders_daily
    )
""")

source_orders.createOrReplaceTempView("source_orders")

# Enrich with customer dimension — equivalent to dim_customers ref
enriched = spark.sql("""
    SELECT
        o.order_id,
        o.customer_id,
        c.customer_segment,
        o.order_status,
        o.total_amount,
        o.created_date
    FROM source_orders o
    LEFT JOIN catalog.dimensions.dim_customers c
        ON o.customer_id = c.customer_id
""")

enriched.createOrReplaceTempView("enriched_orders")

# Merge into target Delta table
spark.sql("""
    MERGE INTO catalog.marts.fct_orders_daily AS target
    USING enriched_orders AS source
    ON target.order_id = source.order_id
    WHEN MATCHED THEN UPDATE SET *
    WHEN NOT MATCHED THEN INSERT *
""")

row_count = enriched.count()
print(f"Processed {row_count} incremental records")

Schau, was dbt automatisch übernimmt, das Spark SQL nicht tut: den Upstream-DAG (stg_orders, dim_customers resolven zur richtigen Tabelle ohne Hardcoding), den Built-in-Testing-Layer, generierte Doku und die Inkremental-Logik. Die Spark-SQL-Version ist expliziter und gibt dir mehr Kontrolle — aber jede strukturelle Entscheidung musst du selbst treffen und warten.

Wann dbt

• Die Primärsprache deines Teams ist SQL und du willst, dass Transformationen wie SQL aussehen.
• Du brauchst Built-in-Daten-Testing, -Doku und -Lineage ohne separate Tools.
• Du bist auf Snowflake, BigQuery oder nutzt Databricks-SQL-Warehouse.
• Du willst eine Modeling-Convention (Staging → Intermediate → Mart) im verteilten Team durchsetzen.
• Du hast Junior-Analysts, die innerhalb von Guardrails sicher beitragen sollen.
• Du willst dbt Cloud für Scheduling, ohne eigenes Airflow zu betreiben.

dbts opinionated Conventions sind der Punkt — sie machen verteilte Collaboration handhabbar. Wenn dein Team viel SQL schreibt und du Software-Engineering-Praktiken auf das SQL anwenden willst, ist dbt das richtige Tool.

Wann Spark SQL

• Du transformierst Daten in Volumes, die deine Warehouse-SQL-Engine strapazieren — Multi-TB-Daily-Loads, komplexe Shuffle-Operationen.
• Deine Transformations-Logik braucht iteratives Processing, komplexe UDFs oder ML-Feature-Engineering, die in purem SQL unpraktisch sind.
• Du betreibst bereits Spark-Workloads und willst Stack-Consistency.
• Du brauchst Fine-Grained-Control über Partitionierung, File-Formate und Cluster-Config.
• Du baust Streaming-Pipelines — Structured Streaming nutzt Spark SQL unter der Haube.

Spark SQL ist die richtige Wahl, wenn du spezifisch die Spark-Execution-Engine brauchst, nicht als Default für alle SQL-Transformations-Arbeit.

Ehrliche Trade-offs

dbts echte Schwächen:

• Model-DAGs werden in großen Projekten ohne strenge Naming-Conventions und Folder-Organisation unhandlich. Technical Debt sammelt sich leise.
• Batch-only — dbt handled kein Streaming oder Stateful Processing.
• Inkrementelle Models werden bei Edge-Cases (Late-Arriving Data, Schema-Changes mid-increment) fragil.
• dbt-Cloud-Pricing eskaliert schnell bei Teams jenseits einer Handvoll Developer.

Spark SQLs echte Schwächen:

• Kein natives Testing-Framework. Du schreibst Tests selbst oder integrierst Great Expectations separat.
• Doku ist abwesend, außer du baust einen separaten Catalog-Layer.
• Cluster-Management addiert operativen Overhead, den SQL-first-Teams konstant unterschätzen.
• Spark-Error-Messages von verteilten Jobs sind notorisch schwer zu debuggen — Stack-Traces über Hunderte Zeilen, oft verschleiern sie die echte Ursache.

Beides nutzen: die Databricks-Pattern

Auf Databricks laufen viele Teams einen Hybrid: Spark SQL (oder PySpark) übernimmt den schweren Transformations-Layer — Ingestion, Deduplication, große Aggregationen, Partition-Management — während dbt den Modeling-Layer fährt, der die Tabellen produziert, die Business-User abfragen. Der Databricks-dbt-Adapter unterstützt Incremental-Strategien nativ gegen Delta-Tabellen.

Das ist nicht redundant — es spielt die Stärken beider Tools aus. Spark übernimmt Volume und Komplexität; dbt übernimmt Struktur, Testing und Doku. Das Interface zwischen ihnen ist ein klar definiertes Set von Delta-Tabellen, das dbt liest.

FAQ

Brauche ich dbt Cloud oder reicht dbt Core?

dbt Core reicht für die meisten Teams technisch aus. dbt Cloud lohnt sich, wenn du keine eigene Orchestrierungs-Infrastruktur willst, IDE-Features für Junior-Analysten brauchst oder Lineage über mehrere Projekte hinweg visualisieren willst. Bei Teams mit <5 Developern und vorhandenem Airflow ist Core meist die günstigere Wahl.

Funktioniert dbt mit DuckDB?

Ja — der dbt-duckdb-Adapter ist offiziell und Production-Ready. Bei lokalen Entwicklungs- oder kleinen Produktions-Setups (<100 GB) eine extrem günstige Kombi. Im DACH-Raum populär für DSGVO-kritische Workloads, die nicht in die Cloud sollen.

Kann ich dbt mit Spark SQL Streaming kombinieren?

Nein, dbt ist Batch-only. Für Streaming-Logik brauchst du Spark Structured Streaming oder DLT direkt. dbt kann aber die Gold-Tabellen modellieren, die aus Streaming-Bronze/Silver-Layern entstanden sind.

Ist dbt im DACH-Raum verbreitet?

Ja — dbt hat im DACH-Raum eine wachsende Community, getrieben durch deutsche Analytics-Engineering-Teams und Data-Mesh-Adoptionen. Conferences wie Coalesce zeigen viele DACH-Speaker, und mehrere DACH-Beratungen haben dbt im Standard-Stack.

Gut wählen

dbt und Spark SQL konkurrieren nicht um denselben Job. dbt ist Engineering-Disziplin für SQL-basierte Transformation; Spark SQL ist eine distributed Execution-Engine für Workloads, die sie brauchen. Die Frage ist nicht welches besser ist — sondern welches Problem du löst.

Wenn dein Team SQL schreibt und Struktur, Testing und Doku braucht: starte mit dbt. Wenn du auf Spark-Skala verarbeitest oder im Spark-Ökosystem eingebettet bist: nutze Spark SQL. Wenn du auf Databricks mit ernsten Volume-Anforderungen bist: nutze beides, mit klarem Ownership, was jeder Layer macht.

Weiterlesen

• REST-API-Daten-Pipeline in Python bauen
• AI-Agents vs BI-Dashboards
• Self-Service-Analytics: Warum die meisten Teams es vermasseln

Stand: März 2026. dbt Cloud und Databricks ändern Preise regelmäßig — verifiziere kritische Annahmen direkt bei den Anbietern.