ELT swaps the last 2 steps, loading raw data first and transforming it inside the warehouse.
It relies on the warehouse's own computing power, which can be large and paid for by use.
The raw data stays in the warehouse, so every transformation can be rebuilt from it.
Extraction and loading are often handled by ready-made connectors that copy whole sources.
Transformations are written as SQL that builds clean tables from raw ones.
These SQL models are layered, from lightly cleaned staging tables to final tables for reports.
dbt is a widely used tool that manages these models, runs them in order and tests the results.
Tests check things such as unique keys and no blanks in required columns after every run.
Writing transformations as code makes them reviewable, repeatable and easy to change.
Because analysts know SQL, they can own transformations without a separate engineering team.
Raw data in the warehouse includes everything, so access to sensitive columns must be controlled.
Warehouse costs rise with heavy transformations, so careless models can be expensive.
Storing raw and transformed copies uses more space, though warehouse storage is usually cheap.
In practice, ELT is a common pattern with cloud warehouses.
The usual mistake is loading raw data and never building tested models, leaving analysts to clean it again in every query.