ETL vs ELT 2026: Datenpipeline-Architektur im Vergleich

ETL vs ELT bestimmt, wie Daten durch eine Pipeline fließen — und die Wahl zwischen beiden Ansätzen beeinflusst Kosten, Geschwindigkeit und Flexibilität der gesamten Datenplattform. Beide Akronyme beschreiben dieselben drei Operationen — Extrahieren, Transformieren, Laden — doch die Reihenfolge von Transformation und Laden verändert die Architektur grundlegend.

So funktionieren ETL-Pipelines

In einer ETL-Pipeline durchlaufen die Daten eine dedizierte Transformationsschicht zwischen Extraktion und Laden. Ein Staging-Server oder eine Verarbeitungsengine empfängt Rohdaten aus Quellsystemen, wendet Bereinigung, Filterung, Aggregation und Schema-Mapping an und schreibt das transformierte Ergebnis in die Zieldatenbank.

Diese Architektur entstand in einer Zeit, als Speicher teuer und Rechenleistung fix war. Die Transformation vor dem Laden reduzierte Speicherkosten und stellte sicher, dass ausschließlich bereinigte, strukturierte Daten in das Warehouse gelangten.

# etl_pipeline.py
import pandas as pd
from sqlalchemy import create_engine

def extract(source_url: str) -> pd.DataFrame:
    """Extract raw data from source system."""
    return pd.read_csv(source_url)

def transform(df: pd.DataFrame) -> pd.DataFrame:
    """Clean and reshape data before loading."""
    # Remove rows with missing revenue
    df = df.dropna(subset=["revenue"])
    # Normalize currency to USD
    df["revenue_usd"] = df.apply(
        lambda row: row["revenue"] * get_exchange_rate(row["currency"]),
        axis=1
    )
    # Aggregate to daily granularity
    return df.groupby("date").agg({"revenue_usd": "sum"}).reset_index()

def load(df: pd.DataFrame, engine) -> None:
    """Write transformed data to the warehouse."""
    df.to_sql("daily_revenue", engine, if_exists="append", index=False)

# Pipeline execution: Extract -> Transform -> Load
engine = create_engine("postgresql://warehouse:5432/analytics")
raw = extract("s3://data-lake/sales/2026-04-13.csv")
cleaned = transform(raw)
load(cleaned, engine)

Die Transformation findet auf einem separaten Server statt. Wenn die Pipeline während der Transformation fehlschlägt, gelangen keine unvollständigen Daten ins Warehouse. Diese Isolation bietet einen Vorteil für regulierte Branchen, in denen Rohdaten in bestimmten Umgebungen niemals existieren dürfen.

So nutzen ELT-Pipelines Cloud-Warehouses

ELT kehrt die letzten beiden Schritte um. Rohdaten landen zuerst im Warehouse, dann werden Transformationen innerhalb des Warehouses mit dessen nativer Compute-Engine ausgeführt. Snowflake, BigQuery, Redshift und Databricks bieten alle die Rechenleistung, um Transformationen im großen Maßstab ohne separaten Staging-Server durchzuführen.

-- models/daily_revenue.sql (dbt model)
-- Transforms raw sales data inside the warehouse

WITH raw_sales AS (
    SELECT
        sale_date,
        revenue,
        currency,
        exchange_rate
    FROM {{ source('raw', 'sales_events') }}
    WHERE revenue IS NOT NULL
),

normalized AS (
    SELECT
        sale_date,
        revenue * exchange_rate AS revenue_usd
    FROM raw_sales
)

SELECT
    sale_date,
    SUM(revenue_usd) AS total_revenue_usd,
    COUNT(*) AS transaction_count
FROM normalized
GROUP BY sale_date

dbt hat sich als Standard-Transformationsschicht für ELT-Pipelines etabliert. Es führt SQL-Modelle direkt im Warehouse aus, versioniert jede Transformation und erstellt einen Abhängigkeitsgraphen, der sicherstellt, dass Modelle in der richtigen Reihenfolge ausgeführt werden.

Architekturvergleich: ETL vs ELT im direkten Vergleich

| Dimension | ETL | ELT | |-----------|-----|-----| | Transformationsort | Separater Staging-Server | Im Ziel-Warehouse | | Daten im Warehouse | Nur bereinigt und strukturiert | Rohdaten + transformierte Schichten | | Speicherkostenmodell | Geringere Warehouse-Speicherkosten | Höhere Warehouse-Speicherkosten, aber Cloud-Speicher ist günstig | | Rechenkostenmodell | Dedizierter ETL-Server (dauerhaft aktiv) | On-Demand-Warehouse-Compute (Bezahlung pro Abfrage) | | Schema-Flexibilität | Schema vor dem Laden definiert | Schema-on-Read, flexible Iteration | | Neuverarbeitung | Erneute Extraktion aus der Quelle erforderlich | Transformationen auf gespeicherten Rohdaten erneut ausführen | | Latenz | Höher (Transformations-Engpass) | Niedriger (zuerst laden, dann asynchron transformieren) | | Datenaktualität | Begrenzt durch Pipeline-Geschwindigkeit | Nahezu Echtzeit möglich | | Compliance | Rohdaten gelangen nie ins Warehouse | Rohdaten im Warehouse gespeichert (Verschlüsselung/Maskierung nötig) | | Typische Tools | Informatica, Talend, SSIS, eigene Skripte | Fivetran + dbt, Airbyte + dbt, Stitch + dbt |

Die Tabelle zeigt ein klares Muster: ETL tauscht Flexibilität gegen Kontrolle, während ELT Kontrolle gegen Flexibilität tauscht. Keiner der beiden Ansätze ist universell überlegen.

Wann ETL weiterhin die richtige Wahl ist

ETL ist nicht veraltet. Mehrere Szenarien erfordern die Transformation von Daten, bevor sie das Warehouse erreichen.

Regulatorische Compliance: DSGVO, HIPAA und PCI-DSS verlangen teilweise, dass personenbezogene Daten (PII) in bestimmten Systemen niemals in Rohform vorliegen dürfen. Eine ETL-Pipeline kann sensible Felder maskieren, hashen oder entfernen, bevor sie geladen werden.

Feste Zielschemas: Legacy-Systeme mit starren Schemas — Mainframe-Datenbanken, ERP-Systeme, Drittanbieter-APIs — erfordern Daten in einem exakten Format. Die Transformation vor dem Laden stellt Kompatibilität sicher, ohne das Zielsystem zu verändern.

Geringe Datenmengen: Bei der Verarbeitung von nur wenigen tausend Datensätzen pro Tag verursacht ein Cloud-Warehouse für ELT unnötige Infrastrukturkosten. Ein einfaches Python-Skript oder eine Apache-Spark-Pipeline, die ETL ausführt, ist günstiger und einfacher.

Netzwerkbeschränkte Umgebungen: IoT-Edge-Deployments oder Air-Gapped-Netzwerke profitieren von der lokalen Transformation der Daten, bevor kleinere, bereinigte Payloads an ein zentrales System übertragen werden.

Wann ELT bessere Ergebnisse liefert

ELT dominiert moderne Datenplattformen aus guten Gründen — und die Zahlen von 2026 bestätigen diesen Trend. Der Markt für Datenpipeline-Tools soll bis 2030 48,3 Milliarden Dollar erreichen, wobei Cloud-Deployments über 71 % der Marktumsätze ausmachen.

Iterative Analytik: Geschäftsanforderungen ändern sich ständig. Mit ELT verbleiben die Rohdaten dauerhaft im Warehouse. Wenn eine neue Metrik benötigt wird, liest ein neues dbt-Modell aus derselben Rohschicht — ohne erneute Extraktion.

Hohe Datenvolumen: Cloud-Warehouses skalieren Compute unabhängig vom Speicher. Das Laden von Terabytes an Rohdaten kostet in Snowflake oder BigQuery nur wenige Cent pro Gigabyte. Transformationen laufen auf elastischer Rechenleistung, die sich an die Arbeitslast anpasst.

Quellenübergreifende Joins: Rohdaten aus CRM, Payment-Prozessoren, Product-Analytics und Marketing-Plattformen landen alle im selben Warehouse. Joins über verschiedene Quellen hinweg erfolgen in SQL, ohne dass benutzerdefinierte Extraktionslogik für jede Kombination erstellt werden muss.

ML-Feature-Engineering: Data-Science-Teams benötigen Zugriff auf granulare Rohdaten. Vorab aggregierte ETL-Ausgaben schränken die ableitbaren Features ein. ELT bewahrt jedes Feld und ermöglicht es Data-Engineering-Teams, Feature Stores direkt aus Rohtabellen aufzubauen.

Der moderne ELT-Stack: Fivetran, dbt und das Warehouse

Das dominierende Muster im Jahr 2026 folgt einer Drei-Schichten-Architektur: Ingestion, Transformation und Consumption.

# dbt_project.yml - Modern ELT project configuration
name: analytics_pipeline
version: "1.0.0"

models:
  analytics_pipeline:
    staging:             # 1:1 mappings from raw sources
      +materialized: view
      +schema: staging
    intermediate:        # Business logic, joins, calculations
      +materialized: ephemeral
    marts:               # Final tables consumed by BI tools
      +materialized: table
      +schema: analytics

Ingestion-Schicht: Fivetran oder Airbyte extrahiert Daten aus Quellsystemen und lädt Rohdatensätze in das Warehouse. Über 600 vorgefertigte Konnektoren eliminieren benutzerdefinierten Extraktionscode. Allein Fivetran bedient über 6.300 Kunden bei einem ARR von 300 Millionen Dollar — ein Beleg dafür, wie standardisiert diese Schicht geworden ist.

Transformations-Schicht: dbt-Modelle organisieren SQL-Transformationen in Staging-, Zwischen- und Mart-Schichten. Jedes Modell wird versioniert, getestet und dokumentiert. Die ref()-Funktion verwaltet Abhängigkeiten automatisch.

Consumption-Schicht: BI-Tools (Looker, Tableau, Metabase) und ML-Plattformen lesen aus den Mart-Tabellen. Reverse-ETL-Tools wie Census oder Hightouch schieben Warehouse-Daten zurück in operative Systeme.

Die 2025 angekündigte Fusion von Fivetran und dbt signalisiert eine weitere Konsolidierung der Ingestion- und Transformationsschichten zu einer einzigen Plattform.

Hybride Pipelines: ETL und ELT kombiniert

Reale Architekturen verwenden selten reines ETL oder reines ELT. Hybride Pipelines wenden leichte Transformationen während der Extraktion an — PII-Maskierung, Deduplizierung, Formatnormalisierung — und führen dann schwere analytische Transformationen innerhalb des Warehouses aus.

# hybrid_pipeline.py
# Light ETL at extraction + heavy ELT in warehouse

def extract_and_mask(source: str) -> pd.DataFrame:
    """Extract with minimal transformation: PII masking only."""
    df = pd.read_json(source)
    # Mask email addresses before loading
    df["email"] = df["email"].apply(lambda e: hash_pii(e))
    # Remove raw IP addresses
    df.drop(columns=["ip_address"], inplace=True)
    return df

def load_raw(df: pd.DataFrame, warehouse) -> None:
    """Load masked but otherwise raw data to warehouse."""
    df.to_sql("raw_user_events", warehouse, if_exists="append", index=False)

# Heavy transformations happen in dbt inside the warehouse
# See: models/marts/user_engagement.sql

Dieser hybride Ansatz erfüllt Compliance-Anforderungen an der Extraktionsgrenze und bewahrt gleichzeitig die analytische Flexibilität von ELT innerhalb des Warehouses.

Leistung und Kosten in der Praxis

Die Kostenmodellierung hängt von der spezifischen Plattform und dem Datenvolumen ab. Einige Benchmarks aus Produktions-Pipelines verdeutlichen die Unterschiede.

| Metrik | ETL (EC2 + RDS) | ELT (Fivetran + Snowflake + dbt) | |--------|-----------------|-----------------------------------| | Monatliche Ingestion (1 TB/Tag) | 2.400 $ (c5.4xlarge) | 1.800 $ (Fivetran nutzungsbasiert) | | Transformations-Compute | 2.400 $ (dedizierter Server) | 600–1.200 $ (Snowflake on-demand) | | Speicher (Roh + transformiert) | 200 $ (EBS) | 460 $ (Snowflake-Speicher) | | Engineering-Wartung | 40+ Stunden/Monat | 5–10 Stunden/Monat | | Monatliche Gesamtkosten | ~5.000 $ + Engineering-Zeit | ~3.000–3.500 $ + minimaler Engineering-Aufwand |

Der Unterschied bei der Engineering-Wartung ist am bedeutendsten. Benutzerdefinierte ETL-Pipelines brechen zusammen, wenn sich Quellschemas ändern, API-Rate-Limits verschoben werden oder Datenvolumen unerwartet ansteigen. Verwaltete ELT-Plattformen wie Fivetran und Airbyte bewältigen diese Probleme automatisch.

Datenqualität und Teststrategien

ELT-Pipelines erfordern explizite Datenqualitätsprüfungen, da Rohdaten ohne Validierung ins Warehouse gelangen. dbt bietet integrierte Testfunktionen, die Probleme erkennen, bevor sie sich in Dashboards ausbreiten.

# models/staging/stg_orders.yml
version: 2

models:
  - name: stg_orders
    description: "Cleaned orders from raw source"
    columns:
      - name: order_id
        tests:
          - unique           # No duplicate orders
          - not_null         # Every row has an ID
      - name: order_total
        tests:
          - not_null
          - dbt_utils.accepted_range:
              min_value: 0   # No negative totals
              max_value: 100000
      - name: customer_id
        tests:
          - not_null
          - relationships:   # Foreign key integrity
              to: ref('stg_customers')
              field: customer_id

Jedes dbt-Modell sollte Schema-Tests enthalten. Die Ausführung von dbt test nach jedem Transformations-Build erkennt Datenqualitätsregressionen sofort — eine Fähigkeit, die traditionelle ETL-Pipelines ohne benutzerdefiniertes Tooling in der Regel nicht bieten.

Echtzeit-Aspekte: Streaming vs Batch

Der Vergleich ETL vs ELT bezieht sich traditionell auf Batch-Verarbeitung. Streaming-Architekturen (Kafka, Kinesis, Pub/Sub) führen ein drittes Paradigma ein, bei dem Transformationen während der Übertragung stattfinden.

Batch-ELT bleibt für die meisten Analyse-Workloads im Jahr 2026 die praktikable Wahl. Echtzeit-Streaming fügt Komplexität hinzu, die sich nur für Anwendungsfälle wie Betrugserkennung, Live-Dashboards oder operatives Alerting auszahlt. Für Teams, die Data-Engineering-Interviewfragen bewerten, unterscheidet das Verständnis, wann Batch-ELT ausreicht und wann Streaming notwendig ist, Senior-Kandidaten von Junior-Kandidaten.

Fazit

• ELT ist die Standard-Architektur für cloud-native Datenplattformen im Jahr 2026, angetrieben durch günstigen Speicher und elastische Warehouse-Rechenleistung
• ETL bleibt notwendig für compliance-sensitive Pipelines, Legacy-Integrationen und Edge-/IoT-Deployments, bei denen Daten vor dem Verlassen der Quelle transformiert werden müssen
• Der Fivetran + dbt + Cloud-Warehouse-Stack (Snowflake, BigQuery, Redshift) hat sich als Standard-ELT-Implementierung etabliert
• Hybride Pipelines, die PII bei der Extraktion maskieren und Analysen im Warehouse ausführen, kombinieren die Stärken beider Ansätze
• Das Testing-Framework von dbt schließt die Datenqualitätslücke, die ELT durch das Laden unvalidierter Rohdaten erzeugt
• Batch-ELT deckt die Mehrheit der Analyse-Anwendungsfälle ab; Streaming sollte für Betrugserkennung, operatives Alerting und Sub-Sekunden-Latenzanforderungen reserviert werden
• Die Wahl sollte auf Einschränkungen basieren (Compliance, Datenvolumen, Teamgröße, bestehende Infrastruktur) — nicht auf Branchentrends