ETL transforms data before loading it into the warehouse. ELT loads the raw data first and transforms it inside the warehouse. Use ELT by default on a modern cloud platform, because it keeps the raw data and lets analysts change the logic in SQL. Use ETL when data must be cleaned or masked before it's allowed to land, or when the destination can't do the work.
ETL vs ELT: the difference in one table
| ETL | ELT | |
|---|---|---|
| Order | Extract, transform, load | Extract, load, transform |
| Where the work happens | A separate engine, before the warehouse | Inside the warehouse or lakehouse |
| Raw data kept? | Often not | Yes, by design |
| Changing the logic | Edit the pipeline and reload | Edit a SQL model and rerun |
| Who can change it | Data engineers | Engineers and analysts |
| Fits best | Strict rules on what may be stored; older or limited targets | Cloud warehouses and lakehouses |
Why ETL came first
ETL is the older pattern, and it was a sensible answer to an expensive problem. Warehouse storage and compute used to cost a great deal, so you didn't load anything you weren't going to use. You shaped the data on a separate server and delivered only the finished tables.
That had a price. The moment someone asked a question the finished tables couldn't answer, an engineer had to change the pipeline and reprocess history. If the source system had since discarded old records, the history was simply gone.
What ELT changed
Cloud platforms made storage cheap and compute elastic. Suddenly the warehouse itself was the most capable engine you owned. So the order flipped: land everything raw, then transform with SQL where the data already sits.
Two things follow from that, and they matter more than the acronym.
You keep the raw data. When a definition changes (and revenue definitions always change), you rebuild from the original records instead of going back to a source that may have moved on.
And the logic becomes readable. Transformations written as SQL models in a tool like dbt live in version control, with tests, where an analyst can read and propose changes. The business rules stop being hidden in a pipeline only one engineer understands.
When ETL is still right
ELT is the default, not a law. We still build ETL steps in a few situations.
- Sensitive fields that must be masked or dropped before they reach the platform at all, such as card numbers or health details the warehouse isn't cleared to hold.
- Very large raw feeds where most of the volume is noise and filtering early saves real money.
- Destinations that can't transform well: an operational database, an application, a partner's system.
- Formats the warehouse can't read until something else has parsed them.
Most real pipelines end up mixed. A light transform on the way in for privacy or format, then the heavy modelling inside the platform. Nobody gives you a prize for purity.
The costs nobody mentions about ELT
ELT moves cost; it doesn't remove it. Every transformation now runs on warehouse compute, and a carelessly written model that rebuilds a huge table every hour will show up on the bill.
It also makes it easy to load everything and model nothing. A raw layer with four hundred tables and no documented, trusted layer on top isn't a data platform. It's a more expensive version of the mess you started with. The medallion architecture exists to prevent exactly that.
The fixes are ordinary engineering: incremental models, tests on the data, and someone who owns cost. That's the work described on our data engineering page.
How to choose for your pipeline
- Is the destination a cloud warehouse or lakehouse? If yes, start from ELT.
- Is there data that must not be stored raw? Transform or mask that part before loading.
- Will analysts need to change business logic? That's a strong reason for SQL models inside the platform.
- Is the raw volume mostly waste? Filter early for that feed.
If you're moving off a legacy ETL tool, don't translate the old jobs one for one. Many of them encode workarounds for limits your new platform doesn't have. A migration is the right moment to ask what each job was for.
