ETL vs ELT

Introductie

In Introduction to Data Engineering noemden we kort dat de verschuiving van ETL naar ELT samenviel met de opkomst van goedkope, elastische cloud-compute in data warehouses. Dat is de geschiedenis; dit hoofdstuk behandelt de techniek — wat er precies anders gebeurt tussen deze twee patronen, welke concrete voor- en nadelen daaruit volgen, en hoe je in de praktijk beslist welke aanpak bij welke situatie past. Het is geen achterhaalde discussie: zelfs op platformen die volledig voor ELT zijn ontworpen, zijn er legitieme, terugkerende redenen om alsnog voor ETL te kiezen, met name rond compliance.

De Kernvraag: Waar Vindt Transformatie Plaats?

Beide patronen bestaan uit dezelfde drie stappen — extract, transform, load — het verschil zit in de volgorde en, belangrijker, in waar de transformatiestap fysiek plaatsvindt.

Bij ETL (Extract, Transform, Load) wordt data uit de bron gehaald, getransformeerd op een aparte, dedicated verwerkingsengine (historisch een on-premises ETL-server met tools als Informatica of SSIS, tegenwoordig soms een aparte compute-laag), en pas dan geladen in het uiteindelijke warehouse — in de definitieve, gemodelleerde vorm. Het warehouse ziet nooit de ruwe, ongetransformeerde data.

Bij ELT (Extract, Load, Transform) wordt data eerst, grotendeels ongewijzigd, in het warehouse geladen — dit is exact de bronze-laag uit Medallion Architecture — en pas daarna getransformeerd, met de eigen compute van het warehouse zelf, meestal via SQL (dbt) of Spark. Het warehouse ziet wél de ruwe data, tenminste tijdelijk.

Dit klinkt als een klein verschil in volgorde, maar de gevolgen raken bijna elk aspect van hoe je een pipeline bouwt, onderhoudt en beveiligt.

ETL in Detail: Transform Before Load

Het transformeren gebeurt hier op een aparte engine, losstaand van het warehouse. Dit heeft twee directe consequenties.

Voordeel: gevoelige data kan al gefilterd of gemaskeerd worden vóórdat ze het warehouse bereikt. Als een organisatie wettelijk verplicht is om BSN's of medische gegevens nooit ongemaskeerd in een bepaald systeem te laten belanden, biedt ETL een harde garantie: die maskering gebeurt vóór het laden, dus de ruwe waarde bestaat op geen enkel moment in het warehouse — niet eens tijdelijk, niet eens in een tabel die "bronze" heet en toegang beperkt. Dit is precies waarom veel financiële instellingen en overheidsorganisaties, ondanks de moderne voorkeur voor ELT, bepaalde pijplijnen bewust als ETL blijven bouwen.

Nadeel: transformatielogica leeft buiten het warehouse, vaak in een proprietary tool met een grafische interface. Wijzigingen zijn lastig te versiebeheren (geen nette Git-diff van een drag-and-drop-canvas), lastig te reviewen in een pull request, en de aparte verwerkingsengine is extra infrastructuur die apart geschaald, gepatcht en onderhouden moet worden — precies het probleem dat in Introduction to Data Engineering werd beschreven als de aanleiding voor de opkomst van de rol "data engineer" met echte software-engineeringvaardigheden.

ELT in Detail: Load Before Transform

Bij ELT verschuift transformatie naar ná het laden, uitgevoerd met de compute van het warehouse zelf.

Voordeel: flexibiliteit en eenvoud. Omdat de ruwe data al in het warehouse staat (de bronze-laag), kun je transformatielogica achteraf wijzigen, uitbreiden of zelfs volledig herzien zonder opnieuw te hoeven extraheren uit het bronsysteem — een principe dat we in Introduction to Data Engineering al zagen als reden om bronze altijd te bewaren. Transformatie gebeurt bovendien in SQL (via dbt) of Spark, wat betekent dat het gewoon code is: Git-versiebeheerd, reviewbaar in pull requests, getest via CI/CD — zie CI/CD for Data Engineering.

Nadeel: gevoelige data landt eerst ruw in het warehouse, wat een compliance-overweging is die je expliciet moet adresseren (via kolomniveau-maskering direct in de silver-transformatie, en strikte toegangscontrole op bronze — zie Data Security) in plaats van dat het probleem automatisch is opgelost door de architectuur zelf. Daarnaast kan ELT duurder uitpakken als transformatie-compute niet bewust wordt beheerd: dezelfde zware aggregatiequery die je in een oude ETL-tool op een goedkope, dedicated server liet draaien, verbruikt nu warehouse-credits — relevant genoeg dat we er in Modern Data Platform Architecture een heel kostenvoorbeeld aan wijdden.

Praktisch Voorbeeld: Dezelfde Pipeline, Twee Patronen

Stel: je wilt klantgegevens van een CRM naar een warehouse brengen, waarbij e-mailadressen gemaskeerd moeten worden voor niet-geautoriseerde gebruikers.

De ETL-aanpak — maskering gebeurt vóór het laden, in het extractiescript zelf:

# etl_style_extract.py — maskering gebeurt VOOR het laden
import hashlib

def mask_email(email: str) -> str:
    return hashlib.sha256(email.encode()).hexdigest()[:16] + "@masked.local"

def transform_before_load(raw_customers: list[dict]) -> list[dict]:
    transformed = []
    for c in raw_customers:
        transformed.append({
            "customer_id": c["id"],
            "email_masked": mask_email(c["email"]),
            "segment": c["segment"].upper(),
        })
    return transformed

# Pas NA transformatie wordt er geladen — het warehouse ziet nooit
# de ongemaskeerde e-mailadressen, ook niet tijdelijk.
load_to_warehouse(transform_before_load(extract_from_crm()))

De ELT-aanpak — ruwe data (inclusief het ongemaskeerde e-mailadres) landt eerst in bronze, met beperkte toegang, en maskering gebeurt in de silver-transformatie:

-- Stap 1 (Extract + Load): raw_customers.email bevat het ongemaskeerde adres.
-- Toegang tot raw.customers is beperkt tot het data-engineeringteam.

-- Stap 2 (Transform, in dbt): maskering gebeurt hier, bij het bouwen van silver
CREATE OR REPLACE TABLE silver.customers AS
SELECT
    customer_id,
    SHA2(email, 256) AS email_masked,
    UPPER(segment) AS segment
FROM raw.customers;

Functioneel is de output identiek. Het verschil zit in het risicoprofiel: bij de ELT-versie bestaat er, tussen stap 1 en stap 2, een tabel met ongemaskeerde e-mailadressen — beveiligd via toegangscontrole, maar aanwezig. Bij de ETL-versie bestaat die tabel nooit. Voor de meeste organisaties is toegangscontrole op bronze afdoende; voor sommige (denk aan medische data, financiële transactiedata onder strenge regelgeving) is "bestaat nooit" een harde vereiste die alleen ETL kan garanderen.

Wanneer ETL Nog Steeds de Juiste Keuze Is

Ondanks dat de meeste nieuwe dataplatformen standaard voor ELT kiezen, is ETL geen verouderd patroon dat je nooit meer zou moeten overwegen. Concrete situaties waarin ETL nog steeds terecht de voorkeur krijgt:

Wettelijk verplichte data-minimalisatie. Wanneer regelgeving voorschrijft dat bepaalde ruwe data een systeem nooit mag bereiken, ook niet tijdelijk of achter toegangscontrole, is "transformeren vóór het laden" de enige architectuur die dat daadwerkelijk garandeert.

Extreem grote, zelden gebruikte brondata. Als een bron enorme volumes bevat waarvan je slechts een klein, vooraf bekend deel nodig hebt, kan filteren vóór het laden aanzienlijk goedkoper zijn dan alles laden en pas achteraf filteren — vooral als warehouse-opslagkosten of laadtijd een reële beperking vormen.

Legacy-integraties met vaste, stabiele transformatie-eisen. Een koppeling met een verouderd extern systeem waarvan het contract al jaren niet wijzigt, heeft weinig baat bij de flexibiliteit die ELT biedt — de stabiliteit van een bestaande ETL-tool omzetten naar ELT levert dan vooral migratierisico op zonder concreet voordeel.

Contractuele beperkingen van een externe partner. Sommige dataleveranciers (bijvoorbeeld in de zorg of financiële sector) staan in hun leveringsovereenkomst expliciet niet toe dat bepaalde velden ooit "at rest" in een systeem buiten hun eigen infrastructuur belanden, ook niet tijdelijk en ook niet versleuteld. In die situatie is transformeren (en desnoods volledig weglaten van het betreffende veld) vóór het laden niet optioneel maar contractueel verplicht — een variant van het compliance-argument, maar afkomstig van een externe partij in plaats van interne regelgeving.

Hybride Aanpak: de Praktijk is Zelden Zuiver

De discussie hierboven suggereert een keuze tussen twee uitersten, maar in de praktijk gebruikt vrijwel elk volwassen dataplatform beide patronen tegelijk, voor verschillende bronnen binnen hetzelfde platform. Een typisch voorbeeld: Flowmetric (de case study uit Modern Data Platform Architecture) laadt de meeste bronnen — Stripe, het CRM, event-tracking — via ELT, omdat die data geen bijzondere gevoeligheid heeft en de flexibiliteit van SQL-transformatie in dbt de voorkeur verdient. Voor één specifieke bron — medische verzuimgegevens van het HR-systeem, onder strikte AVG-vereisten — kiest hetzelfde platform bewust voor een ETL-stap: een klein, apart Python-script dat BSN's en diagnosecodes al vóór het laden pseudonimiseert, zodat die gevoelige velden het warehouse nooit ongemaskeerd bereiken.

Dit is geen inconsistentie in de architectuur — het is precies de juiste toepassing van het principe uit dit hoofdstuk: de keuze tussen ETL en ELT is een beslissing per databron, niet een platformbrede religieuze keuze. Een architectuurdocument dat stelt "wij zijn een ELT-platform" mist de nuance die in de praktijk nodig is; een architectuurdocument dat per bron beargumenteert waarom voor ETL of ELT is gekozen, is bruikbaarder en eerlijker over de afwegingen die daadwerkelijk zijn gemaakt.

Tooling en Kostenvergelijking

De keuze tussen ETL en ELT heeft ook een directe doorwerking op welke tools je gebruikt en hoe de kosten zich verhouden.

ETL-tooling — traditioneel Informatica, SSIS, Talend, of specifieke cloud-varianten zoals Azure Data Factory's mapping data flows (die transformatie op een aparte Spark-compute-laag uitvoeren, los van het doelwarehouse). De kosten zitten in twee aparte compute-lagen: de ETL-engine zelf (vaak licentiekosten plus infrastructuurkosten) én het warehouse waar het eindresultaat landt. Voor een klein aantal pipelines met bescheiden volumes is dit vaak overzichtelijk; bij tientallen pipelines wordt de aparte ETL-laag zelf een significante kostenpost én een aparte operationele verantwoordelijkheid (patches, schaalbaarheid, monitoring) naast het warehouse.

ELT-tooling — Fivetran of Airbyte voor de EL-stap (vaak geprijsd per verwerkte rij of per connector), gecombineerd met dbt voor de T-stap (waar de kosten in warehouse-compute zitten, niet in een aparte tool-licentie). Voor de meeste teams is dit financieel voordeliger zodra het aantal bronnen groeit, simpelweg omdat er geen aparte, los te schalen ETL-laag hoeft te worden onderhouden — de kosten schalen mee met wat het warehouse toch al kost. De valkuil is dat transformatiekosten dan minder zichtbaar worden als aparte regel, wat precies de reden is waarom workload-scheiding en kostmonitoring (zie Modern Data Platform Architecture) belangrijker worden naarmate een ELT-platform groeit.

# orchestration.yml — illustratief: hoe een hybride aanpak er
# in een Airflow/Dagster-achtige orchestrator uitziet
pipelines:
  - name: stripe_orders
    pattern: ELT
    steps: [fivetran_sync, dbt_run_staging, dbt_run_marts]

  - name: hr_absence_data
    pattern: ETL
    steps: [python_extract_and_pseudonymize, load_to_warehouse]
    note: "AVG-vereiste: BSN/diagnosecodes nooit ongemaskeerd in warehouse"

Reverse ETL: een Verwante maar Andere Term

Een term die vaak voor verwarring zorgt: reverse ETL is geen derde variant van hetzelfde spectrum, maar een tegenovergestelde beweging — data die van het warehouse terug naar operationele tools stroomt (Salesforce, HubSpot, een supportsysteem), zodat bijvoorbeeld een sales-medewerker in het CRM een door het dataplatform berekende klantscore kan zien. Tools als Hightouch en Census zijn hier gespecialiseerd in. Dit hoort thuis in de serving-laag die we in Modern Data Platform Architecture bespraken, niet in de ingestion-laag — noem het niet "ELT achterstevoren", want de tussenliggende architectuur (extractie uit een warehouse, geen ruwe extractie uit een bron, geen medallion-lagen) is wezenlijk anders.

Best Practices

• Kies ELT als standaard voor nieuwe cloudplatformen, tenzij een concrete, benoembare reden (compliance, extreem volume, stabiele legacy-integratie) voor ETL pleit.
• Documenteer expliciet welke pipelines om compliance-redenen ETL zijn, zodat die keuze niet per ongeluk wordt "gemoderniseerd" naar ELT door een toekomstige engineer die de reden niet kent.
• Beperk toegang tot bronze/raw-tabellen strikt wanneer je voor ELT kiest — dit is de architecturale compensatie voor het feit dat ruwe, mogelijk gevoelige data daar tijdelijk staat.
• Behandel maskering als onderdeel van de silver-transformatie, niet als een losse, makkelijk te vergeten nabewerkingsstap.
• Verwar reverse ETL niet met ELT in documentatie of architectuurdiagrammen — het zijn tegenovergestelde databewegingen met andere doelen.
• Maak de ETL/ELT-keuze per bron expliciet en beargumenteerd, bijvoorbeeld in een orchestratie-config zoals hierboven, zodat een nieuwe engineer in één oogopslag ziet waarom een specifieke pipeline afwijkt van het platformbrede standaardpatroon.

Veelgemaakte Fouten

• Automatisch voor ELT kiezen zonder de compliance-implicaties te overwegen — vooral bij persoonsgegevens of financiële data, waar "het staat achter toegangscontrole" soms niet volstaat als wettelijke garantie.
• ETL-tooling aanhouden puur uit gewoonte, terwijl er geen concrete reden meer is die ELT in de weg staat — wat onnodige infrastructuur en onderhoud oplevert.
• Maskering vergeten of te laat toepassen in een ELT-pipeline, waardoor gevoelige data verder stroomafwaarts (silver, gold, of zelfs een BI-dashboard) terechtkomt dan bedoeld.
• Reverse ETL bouwen als een aparte "omgekeerde ELT-pipeline" in plaats van het te behandelen als onderdeel van de serving-laag, met eigen architectuuroverwegingen.

Performance Tips

• Bij ELT: monitor transformatie-compute apart van ingestion-compute — zie het workload-scheidingsprincipe uit Modern Data Platform Architecture, zodat een zware transformatiejob niet onopgemerkt de warehouse-rekening laat oplopen.
• Bij ETL: schaal de transformatie-engine onafhankelijk van het warehouse — een veelgemaakte performance-fout is een ETL-server die niet meegroeit met toenemend datavolume, terwijl het warehouse zelf ruim voldoende capaciteit heeft.
• Filter zo vroeg mogelijk in beide patronen, ook bij ELT — "laad alles, filter later" betekent niet dat vroege, evident onnodige data (test-records, duidelijk corrupte rijen) per se moet worden meegenomen.
• Meet de daadwerkelijke laadtijd versus transformatietijd voordat je een architectuurwijziging voorstelt — in de praktijk is bij de meeste moderne cloudpipelines de transformatiestap, niet de extractie, de grootste kostenpost.

Interviewvragen

"Wat is het verschil tussen ETL en ELT, technisch gezien?" Let op: waar transformatie fysiek plaatsvindt — op een aparte engine vóór het laden (ETL) versus met warehouse-compute ná het laden (ELT) — niet alleen de lettervolgorde.

"Waarom is ELT de dominante aanpak geworden op moderne cloudplatformen?" Let op: de ontkoppeling van storage en compute die cloud warehouses goedkoop maakt, waardoor transformeren met warehouse-compute niet langer een premium kost zoals bij on-premises systemen.

"In welke situatie zou je bewust voor ETL kiezen op een modern cloudplatform?" Let op: compliance-vereisten waarbij ruwe, gevoelige data een systeem nooit mag bereiken — niet "ETL is ouderwets, dus nooit meer gebruiken".

"Wat is reverse ETL, en hoe verschilt het van ELT?" Let op: reverse ETL stroomt van warehouse terug naar operationele tools (tegenovergestelde richting), hoort bij de serving-laag, en is geen variant van het extract/transform/load-spectrum zelf.

"Hoe zou je gevoelige data maskeren in een ELT-pipeline, gegeven dat de ruwe data al in het warehouse staat?" Let op: maskering als expliciete stap in de silver-transformatie, gecombineerd met strikte toegangscontrole op de bronze-laag als extra beschermingslaag.

"Is het normaal dat een dataplatform zowel ETL- als ELT-pipelines heeft? Is dat geen inconsistente architectuur?" Let op: het besef dat de keuze per databron wordt gemaakt op basis van gevoeligheid en compliance-eisen, niet platformbreed — een hybride aanpak is in de praktijk de norm, geen architectonische smet.

Relevante Documentatie

• dbt Labs: ELT Explained — dbt Labs' eigen uitleg van waarom ELT hun tool-ontwerp bepaalt.
• Snowflake: Data Loading Overview — hoe laadpatronen praktisch werken op een ELT-georiënteerd platform.
• Databricks: What is ETL? — Databricks' perspectief vanuit een lakehouse-architectuur.

Samenvatting

ETL en ELT verschillen in waar transformatie plaatsvindt: vóór het laden op een aparte engine (ETL), of ná het laden met de compute van het warehouse zelf (ELT). Cloud-economics — goedkope, elastische warehouse-compute — hebben ELT tot de dominante aanpak gemaakt, met als bijkomend voordeel dat transformatielogica gewone, versiebeheerde code wordt in plaats van een proprietary tool-configuratie. Toch blijft ETL de juiste keuze in specifieke situaties, vooral wanneer compliance vereist dat gevoelige ruwe data een systeem nooit bereikt, ook niet tijdelijk. Reverse ETL is een gerelateerd maar wezenlijk ander concept — de omgekeerde databeweging, van warehouse naar operationele tools. Met dit onderscheid helder, is het volgende hoofdstuk de logische vervolgstap: hoe je die ELT-transformatie in de praktijk structureert via medallion architecture.