Overview
ETL vs ELT
Transform-on-write (ETL) vs transform-in-warehouse (ELT) — and why ELT won in the cloud.
Why it matters
Cheap warehouse compute flipped the cost calculus: load raw, transform in SQL inside the warehouse, version the transformations in git (dbt, SQLMesh).
Going deeper
The paradigm shift introduced by ELT and tools like dbt:
- Idempotent Transformations: In ELT, if a business rule changes (e.g. how 'revenue' is calculated), you just tweak the SQL and rebuild the view on top of the raw data. In ETL, you often had to re-extract the old source data and run it through the external processor again.
- Analytics Engineering: ELT allowed data analysts who only knew SQL to become 'Analytics Engineers'. The transformation layer moved out of complex GUI tools (Informatica) and Java/Scala code, into version-controlled SQL.
- Data Freshness: Loading raw data immediately means analysts have access to the absolute newest events, even if the transformed, polished 'gold' tables aren't fully baked yet.
The acronyms describe where transformation executes before the governed target is published, not whether extraction or transformation exists. ETL is preferable when sensitive fields must be removed before landing, source volumes must be reduced at the edge, or the target cannot process raw formats. ELT is preferable when cheap scalable target compute, immutable raw retention, and SQL-based reprocessing matter. Most production platforms are hybrid: CDC performs light validation and masking in flight, lands a replayable raw layer, then applies versioned transformations inside the analytical platform. Evaluate latency, replayability, data residency, compute cost, and failure recovery rather than treating ELT as a universal successor.
