ETL vs ELT: Welche Pipeline passt zu deinem Data-Stack?

TL;DR: ELT ist der Default für Cloud-Warehouses (Snowflake, BigQuery, Databricks) — Raw landen, dann transformieren mit dbt im Warehouse. ETL bleibt sinnvoll für PII-Maskierung vor dem Load (DSGVO), Legacy-On-Prem-Warehouses oder bandbreiten-limitierte Setups. Die meisten Teams fahren ein Hybrid: ELT als Default, ETL für Edge-Cases.

Jedes Data-Team trifft irgendwann diese Entscheidung: transformierst du Daten vor dem Load ins Warehouse — oder danach? Die Antwort formt deine Architektur, deine Kosten und wie schnell deine Analysten Antworten bekommen. ETL und ELT klingen fast identisch, aber der Unterschied entscheidet, ob deine Pipeline ein Bottleneck oder Rückgrat ist.

TL;DR — ETL vs ELT auf einen Blick

Was ist ETL?

ETL — Extract, Transform, Load — ist der klassische Ansatz. Daten werden aus Source-Systemen gezogen, auf einem dedizierten Middleware-Server transformiert, und nur das bereinigte, strukturierte Ergebnis wird ins Ziel geladen.

Das war jahrzehntelang Standard, weil On-Prem-Data-Warehouses (Teradata, Oracle, Netezza) teuren, begrenzten Compute hatten. Schwere Transformationen im Warehouse zu fahren war verschwenderisch. Es machte Sinn, das Heavy-Lifting woanders zu machen.

Ein typischer ETL-Flow

Source-DBs -> Extract -> Staging-Server (Transform) -> Load -> Data Warehouse

Der Transformations-Schritt erledigt Deduplikation, Type-Casting, Joins, Business-Logik und Aggregation — alles, bevor Daten das Warehouse berühren.

ETL-Beispiel — SSIS-Style (SQL Server)

-- SQL Server / SSIS: Transform in staging before loading to warehouse
-- Step 1: Extract into staging table
SELECT
    order_id,
    customer_id,
    order_date,
    total_amount,
    status
INTO staging.raw_orders
FROM OPENROWSET('SQLNCLI', 'Server=source_erp;Database=sales;',
    'SELECT order_id, customer_id, order_date, total_amount, status FROM orders WHERE order_date >= DATEADD(day, -1, GETDATE())')

-- Step 2: Transform in staging (clean + enrich before loading)
SELECT
    o.order_id,
    o.customer_id,
    c.customer_segment,
    CAST(o.order_date AS DATE) AS order_date,
    ROUND(o.total_amount, 2) AS total_amount,
    CASE
        WHEN o.status = 'C' THEN 'Completed'
        WHEN o.status = 'P' THEN 'Pending'
        WHEN o.status = 'X' THEN 'Cancelled'
        ELSE 'Unknown'
    END AS order_status,
    GETDATE() AS loaded_at
INTO staging.transformed_orders
FROM staging.raw_orders o
JOIN staging.customer_dim c ON o.customer_id = c.customer_id

-- Step 3: Load only the clean result into the warehouse
INSERT INTO warehouse.fact_orders
SELECT * FROM staging.transformed_orders

-- Step 4: Clean up staging
DROP TABLE staging.raw_orders
DROP TABLE staging.transformed_orders

Die Rohdaten sind nach dem Load weg. Findest du drei Monate später einen Bug in der Transform-Logik, musst du aus der Source re-extrahieren — wenn die Daten dort noch existieren.

Was ist ELT?

ELT — Extract, Load, Transform — dreht die Reihenfolge um. Rohdaten landen zuerst im Warehouse, dann laufen Transformationen darin mit dem Warehouse-eigenen Compute-Engine.

Dieser Ansatz wurde lebensfähig (und dominant), als Cloud-Warehouses wie Snowflake, BigQuery und Databricks Compute elastisch und günstig machten. Warum einen separaten Transformations-Server pflegen, wenn dein Warehouse in Sekunden einen Cluster hochfahren kann?

Ein typischer ELT-Flow

Source-DBs -> Extract -> Load (raw) -> Data Warehouse -> Transform (im Warehouse)

ELT-Beispiel — dbt + Snowflake

-- Snowflake SQL: Raw data already loaded into raw.orders by an ingestion tool (Fivetran, Airbyte, etc.)

-- dbt model: models/staging/stg_orders.sql
-- Transforms run inside Snowflake using warehouse compute

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

cleaned AS (
    SELECT
        order_id,
        customer_id,
        order_date::DATE AS order_date,
        ROUND(total_amount, 2) AS total_amount,
        CASE
            WHEN status = 'C' THEN 'Completed'
            WHEN status = 'P' THEN 'Pending'
            WHEN status = 'X' THEN 'Cancelled'
            ELSE 'Unknown'
        END AS order_status,
        CURRENT_TIMESTAMP() AS transformed_at
    FROM source
    WHERE order_date >= DATEADD(day, -1, CURRENT_DATE())
)

SELECT * FROM cleaned

Die Rohdaten bleiben in raw.orders. Die transformierte View sitzt daneben. Ändert sich Business-Logik, führst du das dbt-Model erneut aus — keine Re-Extraktion nötig.

Wann ETL noch Sinn macht

ETL ist nicht tot. Es ist die richtige Wahl in spezifischen Szenarien:

Compliance und Datenminimierung. Wenn Regulierungen verlangen, Roh-PII nicht im Warehouse zu speichern (DSGVO Art. 5, HIPAA), ist die Transformation vor dem Load — Maskierung, Pseudonymisierung oder Dropping sensibler Felder — ein legitimes Pattern. Was schon gelandet ist, kannst du nicht mehr nachträglich redigieren.

Legacy-On-Prem-Warehouses. Wenn du Teradata oder Oracle auf fester Hardware fährst, ist Compute echt teuer. Pre-Transformation, um Warehouse-Last zu reduzieren, ist rationale Ökonomie, nicht Nostalgie.

Kleine, stabile Datasets. Wenn du einmal pro Tag eine 10-Zeilen-Config-Tabelle aus einer REST-API lädst, ist die ETL-vs-ELT-Unterscheidung akademisch. Nimm, was simpler ist.

Bandbreiten-limitierte Umgebungen. Beim Laden über langsame Netzwerke macht erst transformieren, dann laden, pragmatisch Sinn.

Wann ELT die bessere Wahl ist

Für die meisten modernen Cloud-Native-Teams ist ELT aus guten Gründen Default:

Raw-Daten erhalten. Der größte Einzelvorteil. Wenn (nicht falls) sich Business-Logik ändert, musst du nicht aus der Source re-extrahieren. Die Rohdaten sind schon im Warehouse. Allein das spart Teams Wochen Rework pro Jahr.

Warehouse-nativer Compute skaliert. Snowflake, BigQuery und Databricks auto-skalieren. Du bist nicht vom RAM und CPU eines Middleware-Servers bottlenecked. Eine Transformation, die auf einem ETL-Server 45 Minuten dauert, kann auf Snowflake mit XL-Warehouse 90 Sekunden brauchen.

Analyst-Self-Service. Wenn Rohdaten im Warehouse liegen, können Analysten sie direkt explorieren. Sie bauen eigene Staging-Models in dbt, ohne aufs ETL-Team zu warten.

Iterative Entwicklung. Ein dbt-Model ändern und neu laufen lassen dauert Minuten. Ein Informatica-Mapping ändern, in Staging testen und in Produktion deployen dauert Tage.

Kostenvergleich

Verifiziert: März 2026.

Die Hybrid-Realität

In der Praxis fahren die meisten Teams Hybrid:

ELT für die Haupt-Pipeline: Rohdaten ingestieren -> Warehouse -> dbt-Transforms. Deckt 80–90 % der Use-Cases.

ETL für Edge-Cases: PII-Maskierung vor dem Load, Daten aus Legacy-Sources mit Format-Konvertierung, oder High-Volume-Streams, die von Pre-Aggregation profitieren.

Der moderne Stack sieht typisch so aus:

• Extract + Load: Fivetran, Airbyte oder Custom-Python-Skripte
• Transform: dbt (läuft im Warehouse)
• Orchestrate: Airflow, Dagster oder Prefect
• ETL-Ausnahmen: Spark-Jobs oder Python-Skripte für PII-Handling

Häufige Fehler

Fehler 1: "Wir machen ELT", aber laden tatsächlich pre-transformierte Daten. Wenn dein Ingestion-Tool Joins, Filter oder Aggregationen vor dem Landen im Warehouse anwendet, machst du ETL. Wisse, was du tatsächlich fährst.

Fehler 2: Alles roh laden ohne Governance. ELT heißt nicht "alles dumpen und später sortieren". Du brauchst trotzdem einen Schema-Registry, Data-Contracts oder mindestens eine dokumentierte Raw-Layer-Convention. Sonst wird dein Raw-Zone zum Data-Swamp.

Fehler 3: Schwere Transforms in Peak-Query-Stunden. Nur weil Transforms im Warehouse laufen, sollten sie nicht laufen, wenn Analysten queryen. Transform-Jobs in Off-Peak-Fenster schedulen oder isolierten Compute nutzen (Snowflake-Warehouse-Scheduling, BigQuery-Reservations).

Fehler 4: ETL wählen, weil "das, was wir kennen". Sunk-Cost-Reasoning. Wenn dein Team Informatica-Expertise hat, aber ihr nach Snowflake migriert, zahlt sich die Migration zu dbt-basiertem ELT innerhalb eines Jahres allein in Lizenzersparnis aus.

Daten erkunden, bevor du dich auf eine Architektur festlegst

Bevor du entscheidest, wie du Daten transformierst, hilft es, sie tatsächlich anzuschauen. Wenn du neue Datenquellen evaluierst — APIs, CSVs, oder hochgeladene Datasets — kannst du mit Harbinger Explorer direkt im Browser via DuckDB WASM abfragen, ohne Warehouse-Setup. Du explorist Schemas, testest Transformationen mit Klartext-Queries und verstehst die Datenform, bevor du Pipeline-Infrastruktur drumherum baust.

FAQ

Soll mein Team ETL oder ELT als Default nutzen?

Bei Cloud-Warehouse (Snowflake, BigQuery, Databricks): ELT. Bei On-Prem-Legacy oder strikten DSGVO-Anforderungen mit Datenminimierung vor dem Load: ETL als Ergänzung.

Wie passt DSGVO in ein ELT-Setup?

Pseudonymisierung vor dem Load (PII durch Hash ersetzen) oder im Staging-Layer mit kontrolliertem Zugriff. right-to-be-forgotten-Pipelines müssen Raw- und Transformed-Layer beide löschen.

Was ist mit Reverse-ETL?

Reverse-ETL (Daten aus dem Warehouse zurück in Operativsysteme schicken) ist ein eigenes Kapitel, neben ETL/ELT. Tools: Hightouch, Census, Rudderstack.

Wann lohnt sich der Wechsel von ETL zu ELT?

Wenn (1) du auf ein Cloud-Warehouse migrierst, (2) deine Middleware-Lizenz auslaufen lässt, oder (3) du Schema-Änderungen viel Rework verursachen. ROI typisch innerhalb 12 Monaten.

Brauche ich Airflow, wenn dbt mein Transform übernimmt?

Für rein dbt-getriebene Setups: oft nein, dbt Cloud reicht. Mit komplexer Cross-Tool-Orchestrierung (z. B. dbt + Spark-Job + ML-Training): ja, Airflow oder Dagster.

Entscheide nach deinem Stack

Wenn du ein modernes Cloud-Warehouse fährst, starte mit ELT. Roh laden, im Warehouse mit dbt oder Spark SQL transformieren, Raw-Layer intakt halten. ETL-Ausnahmen nur, wo Compliance oder Legacy-Constraints es erzwingen. Die Architektur, die Rohdaten erhält und Transforms an elastischen Compute pusht, wird middleware-abhängige Pipelines in Kosten, Geschwindigkeit und Flexibilität schlagen.

Dein nächster Schritt: auditiere deine aktuelle Pipeline. Wenn du Transformationen außerhalb des Warehouses fährst, die innen laufen könnten, hast du den ersten Migrations-Kandidaten gefunden.

Stand: 14. Mai 2026.