What is the difference between ETL and ELT?

ETL and ELT are the same three operations, extract, transform and load, executed in a different order. With ETL you extract data from the sources, transform it on an intermediate system and load only the clean result into the data warehouse. With ELT you load it raw into the destination platform and transform it there, typically in SQL. It sounds like an engineering detail; in reality the two orders tell the story of two economic eras of data. ETL was born when warehouse storage was expensive and transforming first meant loading only the bare minimum; the cloud flipped that economy by making storage cheap and compute elastic, so today it almost always pays to load everything as-is into platforms like Snowflake, BigQuery, Databricks or Fabric and transform afterwards, with tools like dbt. The difference is not just technical: with ELT the raw data stays in the destination, so reprocessing history when a business rule changes is a SQL query. ETL almost always keeps a staging area to restart from too, but its raw copy lives outside the analytical platform, so reprocessing there means re-running the job.

Why the order flipped

ETL was born when warehouse storage was expensive: transforming first meant loading only the bare minimum. The cloud flipped that economy: storage became cheap and compute engines elastic, so it pays to load everything as-is and transform afterwards, inside platforms like Snowflake, BigQuery, Databricks or Fabric; tools like dbt made SQL transformation versioned and testable like code. The typical pattern today is exactly this: extraction and loading handled by standard tools, with all the intelligence concentrated in the downstream transformation. ELT is the default on modern platforms partly because the raw data stays in the destination: when a business rule changes you reprocess history in SQL, without re-running extraction against the sources. ETL almost always keeps a staging area to restart from too, but its raw copy lives outside the analytical platform and often in a format nobody queries directly, so reprocessing means re-running the job rather than rewriting a query. It is the pattern the medallion architecture formalizes into layers.

When ETL still makes sense

Classic ETL remains the right choice in specific cases: personal or sensitive data that must be masked before leaving the source system, transformations the destination's SQL cannot express, legacy integrations that work well and do not justify a migration. The caveat on ELT: it moves costs from loading to compute. Loading everything and re-transforming everything on every cycle is convenient but billed on consumption, and without discipline on reprocessing the bill climbs fast. The letter that matters is still the T: where you do it is an architecture choice, doing it well is the real work.