← Concepts

阅读中文版本

ETL Versus ELT

ETL transforms data before loading into the warehouse; ELT loads raw data first and transforms it inside the warehouse using its compute.

data

Definition

ETL (extract, transform, load) moves data through a transformation engine before it reaches the target warehouse, historically because storage and compute there were scarce and expensive. ELT (extract, load, transform) lands raw data in cheap cloud storage or the warehouse first, then runs transformations with the warehouse own elastic compute. The choice follows the economics of where compute is cheapest and who owns the transformation logic.

Context and scope

Architecture decision for every analytics platform: ETL suits strict pre-load cleansing and legacy warehouses, while ELT suits cloud warehouses and lakehouses.

Common misconceptions

  • ELT means no transformation layer — the transformations simply move into SQL models inside the warehouse
  • E L T and ETL are just acronym order — the order determines where compute, cost, and governance live
  • One approach is universally modern — regulated or bandwidth-constrained pipelines may still need pre-load ETL

Anti-patterns

  • Loading sensitive raw data widely accessible with no column-level controls because "we will transform later"
  • Running every heavy transform in the warehouse when it could have been pushed down to the source
  • Mixing both approaches ad hoc so lineage becomes untraceable

Related concepts

Authoritative source

https://en.wikipedia.org/wiki/Extract,_transform,_load

What it is

In ETL a dedicated tool reads sources, reshapes records — joins, cleanses, masks — and only then writes results to the warehouse. In ELT the raw extract lands immediately in the warehouse or object storage; transformations run afterward as SQL or dataframe jobs using the warehouse own compute. Both end with queryable, modelled tables; they differ in where work happens and in what the warehouse first receives.

Why it matters

The old constraint was that warehouse storage and CPU were precious, so transforming before load saved both. Cloud warehouses inverted that: storage is cheap, compute is elastic, and SQL is expressive. ELT keeps raw history available for replay, lets analytics engineers own models in version control, and scales transformation with the same engine that serves queries.

Choosing between them

Default to ELT when the platform is a modern cloud warehouse, storage is cheap, and trusted SQL tooling exists. Choose ETL when data must be masked or aggregated before it may leave a regulated zone, when bandwidth is the bottleneck, or when the target cannot run transformations. Many mature platforms run ELT inside the platform and a thin ETL only at the sensitive boundary.