ETL and ELT differ in one thing: where the transformation happens. Most of the arguments about which one to use follow from that single difference.
What each one does
ETL (extract, transform, load) pulls data from the source, cleans and reshapes it on a separate processing layer, then loads the finished result into the destination. ELT (extract, load, transform) loads the raw data into the destination first, then transforms it there using the destination’s own compute, usually with SQL.
Why ELT became common
Cloud warehouses separated storage from compute, which made it practical to keep raw data and run transformations in SQL on demand. Tools like dbt are built around that model. Keeping the raw layer also means you can change your transformation logic and rebuild without extracting from the source again.
When ETL is still the better choice
ETL makes sense when data must be cleaned or masked before it reaches the destination, for example removing personal fields so they never land in the warehouse. It also fits when the destination has limited compute, or when the transformation is hard to express in SQL, such as parsing binary files or calling a model. In those cases the transformation belongs in code that runs before the load.
When ELT fits
ELT fits when the transformations are SQL-friendly, when analysts or analytics engineers own the logic, and when you want raw history available for reprocessing. It assumes the destination can run transformations at scale, such as a cloud warehouse or a lakehouse. A small project can use a local engine instead, as covered in dbt and DuckDB versus a cloud warehouse.
The trade-offs people skip
ELT stores raw data, sensitive fields included, in the destination, so access control and retention rules matter more. With ETL, the transformation logic lives in pipeline code outside the warehouse, which can make it harder for analysts to inspect. Cost also shifts rather than disappears: ELT bills transformation compute to the warehouse, while ETL needs its own processing infrastructure. Neither approach is cheaper in every case.
Most real pipelines use both
Many production pipelines do light cleaning or masking before the load and heavier modeling after it. The label matters less than being clear about where each rule lives. Whichever order you choose, the same engineering habits apply: idempotent pipelines so reruns don’t duplicate data, data contracts so schema changes don’t break downstream tables, and a clear choice between change data capture and batch loads.
A quick checklist
- Must any data be masked or removed before it reaches the destination?
- Can the transformations be written in SQL, or do they need code?
- Does the destination have enough compute to run them at scale?
- Will you need to reprocess raw history when the logic changes?
- Who owns the transformation logic, and where can they see it?
If you need a pipeline designed or built, see my ETL and ELT engineering service.
FAQ
Is ELT replacing ETL?
ELT is the default for many cloud analytics setups, but ETL remains the better fit when data must be masked before loading, when compute is limited, or when the transformation doesn’t suit SQL.
Does ELT need a data warehouse?
It needs a destination that can run transformations at scale, such as a cloud warehouse or lakehouse. For small projects, a local engine like DuckDB can do the same job.
Where does dbt fit?
dbt handles the transformation step of ELT. It runs SQL models inside the warehouse, but it doesn’t extract data from sources or load it.
