ETL vs ELT in 2026: Architectuur van datapipelines uitgelegd

ETL vs ELT bepaalt hoe data door een pipeline stroomt, en de keuze tussen beide benaderingen beïnvloedt de kosten, snelheid en flexibiliteit van het gehele dataplatform. Beide acroniemen beschrijven dezelfde drie bewerkingen — Extractie, Transformatie, Laden — maar de volgorde van transformatie en laden verandert de volledige architectuur.

Hoe ETL-pipelines data verwerken

In een ETL-pipeline doorloopt data een speciale transformatielaag tussen extractie en laden. Een staging-server of verwerkingsengine ontvangt ruwe data van bronsystemen, past opschoning, filtering, aggregatie en schema-mapping toe, en schrijft het getransformeerde resultaat naar de doeldatabase.

Deze architectuur ontstond toen opslag duur was en rekenkracht vast. Transformatie vóór het laden verminderde opslagkosten en zorgde ervoor dat alleen schone, gestructureerde data het warehouse bereikte.

# 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)

De transformatie vindt plaats op een aparte server. Als de pipeline halverwege de transformatie faalt, bereiken er geen onvolledige data het warehouse. Deze isolatie is een voordeel voor gereguleerde sectoren waar ruwe data nooit in bepaalde omgevingen mag bestaan.

Hoe ELT-pipelines cloudwarehouses benutten

ELT keert de laatste twee stappen om. Ruwe data belandt eerst in het warehouse, waarna transformaties worden uitgevoerd binnen het warehouse met behulp van de eigen compute-engine. Snowflake, BigQuery, Redshift en Databricks bieden allemaal de verwerkingskracht om transformaties op schaal uit te voeren zonder een aparte staging-server.

-- 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 is de standaard transformatielaag geworden voor ELT-pipelines. Het voert SQL-modellen direct in het warehouse uit, beheert versiebeheer voor elke transformatie en bouwt een afhankelijkheidsgrafiek die ervoor zorgt dat modellen in de juiste volgorde worden uitgevoerd.

Architectuurvergelijking: ETL vs ELT naast elkaar

| Dimensie | ETL | ELT | |----------|-----|-----| | Locatie transformatie | Aparte staging-server | Binnen het bestemmingswarehouse | | Data in warehouse | Alleen opgeschoond en gestructureerd | Ruwe data + getransformeerde lagen | | Opslagkostenmodel | Lagere warehouse-opslagkosten | Hogere warehouse-opslagkosten, maar cloudopslag is goedkoop | | Rekenkostenmodel | Dedicated ETL-server (altijd actief) | On-demand warehouse-compute (betalen per query) | | Schema-flexibiliteit | Schema gedefinieerd vóór laden | Schema-on-read, flexibele iteratie | | Herverwerking | Nieuwe extractie uit de bron vereist | Transformaties opnieuw uitvoeren op opgeslagen ruwe data | | Latentie | Hoger (transformatie als knelpunt) | Lager (eerst laden, dan asynchroon transformeren) | | Dataversheid | Beperkt door pipelinesnelheid | Bijna realtime mogelijk | | Compliance | Ruwe data bereikt het warehouse nooit | Ruwe data opgeslagen in warehouse (encryptie/maskering nodig) | | Typische tools | Informatica, Talend, SSIS, eigen scripts | Fivetran + dbt, Airbyte + dbt, Stitch + dbt |

De tabel onthult een duidelijk patroon: ETL ruilt flexibiliteit voor controle, terwijl ELT controle ruilt voor flexibiliteit. Geen van beide benaderingen is universeel superieur.

Wanneer ETL de juiste keuze blijft

ETL is niet verouderd. Verschillende scenario's vereisen dat data wordt getransformeerd voordat deze het warehouse bereikt.

Regelgevende compliance: AVG, HIPAA en PCI-DSS vereisen soms dat persoonlijk identificeerbare informatie (PII) nooit in ruwe vorm in bepaalde systemen mag bestaan. Een ETL-pipeline kan gevoelige velden maskeren, hashen of verwijderen voordat ze worden geladen.

Vaste doelschema's: Legacy-systemen met rigide schema's — mainframedatabases, ERP-systemen, API's van derden — vereisen data in een exact formaat. Transformatie vóór het laden garandeert compatibiliteit zonder het doelsysteem aan te passen.

Kleine datavolumes: Bij verwerking van slechts enkele duizenden records per dag brengt het opzetten van een cloudwarehouse voor ELT onnodige infrastructuurkosten met zich mee. Een eenvoudig Python-script of een Apache Spark-pipeline die ETL uitvoert, is goedkoper en eenvoudiger.

Netwerk-beperkte omgevingen: IoT-edge-deployments of air-gapped netwerken profiteren van lokale datatransformatie, voordat kleinere, opgeschoonde payloads naar een centraal systeem worden verzonden.

Wanneer ELT betere resultaten oplevert

ELT domineert moderne dataplatformen om goede redenen — en de cijfers van 2026 bevestigen deze trend. De markt voor datapipelinetools wordt geschat op 48,3 miljard dollar in 2030, waarbij clouddeployment meer dan 71% van de marktomzet genereert.

Iteratieve analytics: Bedrijfsvereisten veranderen voortdurend. Met ELT blijven ruwe data permanent in het warehouse. Wanneer een nieuwe metriek nodig is, leest een nieuw dbt-model uit dezelfde ruwe laag — zonder hernieuwde extractie.

Hoge datavolumes: Cloudwarehouses schalen compute onafhankelijk van opslag. Het laden van terabytes aan ruwe data kost slechts enkele centen per gigabyte in Snowflake of BigQuery. Transformaties draaien op elastische rekenkracht die meeschaalt met de werkbelasting.

Cross-source joins: Ruwe data uit CRM, betalingsverwerkers, productanalytics en marketingplatformen komen allemaal in hetzelfde warehouse terecht. Joins over verschillende bronnen heen gebeuren in SQL zonder dat er aangepaste extractielogica per combinatie nodig is.

ML-feature-engineering: Data-science-teams hebben toegang nodig tot ruwe, granulaire data. Vooraf geaggregeerde ETL-output beperkt welke features kunnen worden afgeleid. ELT behoudt elk veld, waardoor data-engineering-teams feature stores direct vanuit ruwe tabellen kunnen opbouwen.

De moderne ELT-stack: Fivetran, dbt en het warehouse

Het dominante patroon in 2026 volgt een drielagenarchitectuur: ingestion, transformatie en 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-laag: Fivetran of Airbyte extraheert data uit bronsystemen en laadt ruwe records in het warehouse. Meer dan 600 kant-en-klare connectoren elimineren aangepaste extractiecode. Fivetran alleen al bedient meer dan 6.300 klanten met een ARR van 300 miljoen dollar — een bewijs van hoe gestandaardiseerd deze laag is geworden.

Transformatielaag: dbt-modellen organiseren SQL-transformaties in staging-, intermediaire en mart-lagen. Elk model wordt geversiebeheerd, getest en gedocumenteerd. De ref()-functie beheert afhankelijkheden automatisch.

Consumption-laag: BI-tools (Looker, Tableau, Metabase) en ML-platformen lezen uit de mart-tabellen. Reverse-ETL-tools zoals Census of Hightouch duwen warehousedata terug naar operationele systemen.

De in 2025 aangekondigde fusie van Fivetran en dbt signaleert verdere consolidatie van de ingestion- en transformatielagen in één enkel platform.

Hybride pipelines: ETL en ELT gecombineerd

Praktijkarchitecturen gebruiken zelden puur ETL of puur ELT. Hybride pipelines passen lichte transformaties toe tijdens de extractie — PII-maskering, deduplicatie, formaatstandaardisatie — en voeren vervolgens zware analytische transformaties uit binnen het warehouse.

# 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

Deze hybride aanpak voldoet aan compliance-eisen aan de extractiegrens en behoudt tegelijkertijd de analytische flexibiliteit van ELT binnen het warehouse.

Prestaties en kosten in de praktijk

De kostenmodellering hangt af van het specifieke platform en het datavolume. Enkele benchmarks uit productiepipelines illustreren de verschillen.

| Metriek | ETL (EC2 + RDS) | ELT (Fivetran + Snowflake + dbt) | |---------|-----------------|-----------------------------------| | Maandelijkse ingestion (1 TB/dag) | $ 2.400 (c5.4xlarge) | $ 1.800 (Fivetran op basis van gebruik) | | Transformatie-compute | $ 2.400 (dedicated server) | $ 600–1.200 (Snowflake on-demand) | | Opslag (ruw + getransformeerd) | $ 200 (EBS) | $ 460 (Snowflake-opslag) | | Engineering-onderhoud | 40+ uur/maand | 5–10 uur/maand | | Totale maandelijkse kosten | ~$ 5.000 + engineeringtijd | ~$ 3.000–3.500 + minimale engineering |

Het verschil in engineering-onderhoud is het meest significant. Aangepaste ETL-pipelines breken wanneer bronschema's wijzigen, API-limieten verschuiven of datavolumes onverwacht pieken. Beheerde ELT-platformen zoals Fivetran en Airbyte lossen deze problemen automatisch op.

Datakwaliteit en teststrategieën

ELT-pipelines vereisen expliciete datakwaliteitscontroles omdat ruwe data zonder validatie het warehouse binnenkomen. dbt biedt ingebouwde testmogelijkheden die problemen opvangen voordat ze zich naar dashboards verspreiden.

# 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

Elk dbt-model zou schema-tests moeten bevatten. Het uitvoeren van dbt test na elke transformatie-build detecteert datakwaliteitsregressies direct — een mogelijkheid die traditionele ETL-pipelines doorgaans missen zonder aangepaste tooling.

Realtimeoverwegingen: streaming vs batch

De vergelijking ETL vs ELT is traditioneel van toepassing op batchverwerking. Streaming-architecturen (Kafka, Kinesis, Pub/Sub) introduceren een derde paradigma waarin transformaties plaatsvinden tijdens het transport.

Batch-ELT blijft de praktische keuze voor de meeste analytische werkbelastingen in 2026. Realtime streaming voegt complexiteit toe die alleen rendeert voor use cases zoals fraudedetectie, live dashboards of operationele alerting. Voor teams die data-engineering-interviewvragen evalueren, onderscheidt het begrip van wanneer batch-ELT volstaat versus wanneer streaming noodzakelijk is, senior kandidaten van junior kandidaten.

Conclusie

• ELT is de standaardarchitectuur voor cloud-native dataplatformen in 2026, gedreven door goedkope opslag en elastische warehouse-rekenkracht
• ETL blijft noodzakelijk voor compliance-gevoelige pipelines, legacy-integraties en edge-/IoT-deployments waar data moet worden getransformeerd voordat deze de bron verlaat
• De Fivetran + dbt + cloudwarehouse-stack (Snowflake, BigQuery, Redshift) is de standaard moderne ELT-implementatie geworden
• Hybride pipelines die PII maskeren tijdens extractie en analyses in het warehouse uitvoeren, combineren de sterke punten van beide benaderingen
• Het testframework van dbt dicht het datakwaliteitsgat dat ELT introduceert door ruwe data zonder validatie te laden
• Batch-ELT dekt de meerderheid van de analytische use cases; reserveer streaming voor fraudedetectie, operationele alerting en sub-seconde latentievereisten
• Kies op basis van beperkingen (compliance, datavolume, teamgrootte, bestaande infrastructuur), niet op basis van trends in de sector