One line
Regulations force ETL when raw data cannot legally land in the warehouse.
Two words
Compliance pressure.
Business analogy
If the law says you must wash vegetables before they enter the kitchen, you can’t store them dirty in the fridge—even if the fridge is powerful enough to clean them later.
Why teams fall back to ETL under regulation?
Examples:
- Personal health information
Financial identifiers
Government‑classified fields
Location data tied to individuals
If the raw payload violates:
- GDPR
HIPAA
PCI‑DSS
FedRAMP
SOC2
…then ELT becomes illegal.
ETL solves this by stripping or masking sensitive fields before landing.
2) Data residency laws
Some countries require:
- data to be transformed anonymized aggregated before it crosses
borders.
ELT would land raw data in a global warehouse first, which breaks the rule.
ETL lets you:
transform locally
remove identifiers
then ship the safe version
3) “Right to be forgotten” conflicts
If raw data lands in a lakehouse, you must delete it everywhere.
In ELT:
- raw zone bronze silver gold backups replicas
This becomes a compliance nightmare.
ETL avoids this by never storing the sensitive raw version.
4) Vendor risk and auditability
Some industries require:
- deterministic transformations auditable pipelines fixed logic
controlled environments
ELT encourages:
- ad‑hoc SQL multiple consumers touching raw data uncontrolled
transformations
ETL centralizes logic in a controlled pipeline.
5) Data minimization principle
GDPR Article 5 says:
“Only collect what is necessary.”
ELT stores everything first, then filters later.
ETL filters before storage, satisfying the principle.
How teams decide (the real decision tree)
Step 1 — Can raw data legally land in storage?
Yes → ELT
No → ETL
Step 2 — Does the data contain regulated identifiers?
Yes → ETL
No → ELT
Step 3 — Do we need cross‑border movement?
Yes → ETL
No → ELT
Yes → ETL
No → ELT
Step 5 — Do we need raw data for ML or RCA?
Yes → ELT
No → ETL
The hybrid truth (what modern teams actually do)
Most mature organizations end up with:
ETL for regulated data
ELT for everything else
This is the “compliance‑first” architecture.
Summary:
Why ETL still exists (and why regulation is the real reason)
Everyone loves to say “ELT won.” Modern warehouses are powerful. Compute is cheap. Storage is infinite. But regulation doesn’t care how powerful your warehouse is. When raw data cannot legally land in storage, ELT stops being an architecture choice and starts being a compliance violation.
Why teams fall back to ETL in regulated environments:
• Some raw data is legally “toxic” (PHI, PCI, classified fields, precise location data)
• Data residency laws require transformation before crossing borders
• “Right to be forgotten” becomes unmanageable once raw data fans out
• Auditors demand deterministic, controlled, and auditable transformations
• GDPR’s data minimization principle conflicts with “store everything first”
So the real decision tree is brutally simple:
Can raw data legally land in storage?
→ Yes: ELT
→ No: ETL
The mature outcome isn’t ideological. It’s practical.
ETL for regulated data.
ELT for everything else.
That’s not legacy thinking.
That’s compliance-first data architecture.
If you’re designing modern platforms and ignoring this distinction, you’re not being modern—you’re being lucky.
Infect, Governance and compliance had pushed me to dive deeper into the semantics of data. One of my original efforts in that direction is DAIS‑10.
https://github.com/usman19zafar/DAIS-10-Continuum
