ETL and ELT describe the same three steps, extract, transform, load, in a different order, and the difference sounds like a technicality until it's the thing determining how expensive a data pipeline is to change six months from now.
ETL transforms data before it's loaded into the destination warehouse, using a separate processing step or tool. That was the practical default for a long time because early data warehouses weren't built to handle heavy transformation workloads efficiently, so doing the work upstream made sense.
ELT loads raw data first and transforms it inside the warehouse itself, using the warehouse's own compute. Modern cloud warehouses like Snowflake, BigQuery, and Redshift are genuinely built to handle that workload well, which is the real reason ELT became the more common default: the constraint that originally justified ETL mostly stopped applying.
The practical advantage of ELT is change cost. Since raw data is preserved in the warehouse, a transformation can be rewritten and rerun against history without re-extracting from the source system, which matters a lot in practice because transformation logic changes far more often than anyone expects when a pipeline is first built. ETL, by contrast, often means re-running the whole pipeline from the source to change how a single field gets calculated.
ETL still earns its place in specific cases: when source data contains information that legally or contractually can't be stored raw before being masked or filtered, or when the destination system genuinely can't handle the volume of raw data efficiently. For most modern analytics pipelines built on a capable cloud warehouse, ELT's lower change cost makes it the more practical default, with the transformation logic kept in version-controlled code, commonly via a tool like dbt, rather than buried in a black-box ETL job.
