You have seen the table. ETL transforms before loading, ELT transforms after. ETL needs its own compute tier, ELT borrows the warehouse’s. ETL is rigid, ELT is flexible. Verdict: ELT.
The verdict is correct, and it has been correct for most teams since cloud warehouses made compute elastic. Which raises a question the table does not answer: if this is settled, why does every data team still argue about where transformations belong?
Because “ETL or ELT” was never the real decision. It is a question about letter order. The real decision is where in the pipeline you draw the transform line — and there are three places to draw it.
What actually changed
For most of data warehousing’s history, warehouse compute was a fixed, expensive resource you had bought in advance. Loading raw data into it was wasteful: you were spending scarce compute storing rows you might never model, so you cleaned and shaped them first, on cheaper hardware, and loaded only the finished result.
Cloud warehouses broke that constraint. Storage became cheap, compute became elastic and billed by the second, and “land it now, decide later” stopped being expensive. That is the entire shift. ELT did not win on elegance — it won because the thing that made ETL necessary stopped being true.
What survived the shift is the part nobody labels: some transformations still have to happen before the data lands. Not for performance. For reasons no pricing model changes.
Three places, not two
In flight — before it lands. Whatever you are not allowed to store, or cannot afford to store. Card numbers, national IDs, anything under a retention rule. Once raw data is in the warehouse it is in your backups, your clones, your dev environment and your breach surface. Masking after landing does not undo landing.
On landing — raw to cleaned. Everything that is true about the data regardless of who consumes it. Types, timestamps in one timezone, deduplication, trimming the columns nobody will ever read. This layer has no opinions about the business; it makes the raw data usable without deciding what it means.
In the model — cleaned to meaning. Where “active user” gets its definition, where revenue joins to currency, where a business rule becomes SQL. This is the layer that should change often, and the only one that should encode a decision someone could disagree with.
Most working pipelines use all three. The industry calls that ETLT when it names it at all, which is rarely, because it does not fit on a comparison slide.
What belongs where
| Transformation | Where | Why there |
|---|---|---|
| Mask or drop PII | In flight | Landing it raw makes it yours to protect and yours to breach |
| Drop payload fields nobody models | In flight | Cheapest row is the one you never store |
| Cast types, normalise timestamps | On landing | True regardless of use; every consumer needs it done once |
| Deduplicate on natural key | On landing | A duplicate is wrong for everyone, not just one report |
| Define “active user” | In the model | Someone can disagree with it, so it must be versioned and reviewable |
| Currency conversion for reporting | In the model | The rate, the date and the rounding rule are all business decisions |
The failure mode in each direction is specific. Push model logic down into landing and every consumer inherits a definition they never agreed to. Push landing work up into the model and every downstream query re-does the same casting, and pays for it every time.
What the comparison tables leave out
ELT is the right default. It also has three costs that no table lists, and it is worth naming them from a company that builds ELT pipelines for a living.
Raw data is a liability as well as an asset. “Keep everything, decide later” is genuinely useful — until a retention request arrives and the answer has to cover every copy. Storage is cheap; obligations are not.
Your compute bill is now your transform bill. In ETL, an inefficient transformation was slow. In ELT it is a recurring charge that scales with volume, and it hides inside a warehouse invoice nobody reads line by line. This is not hypothetical — it is why incremental loading and dependency-aware orchestration matter more in ELT than they ever did in ETL.
Transformation debt becomes invisible. “Transform later” quietly permits “transform never.” A badly modelled table produces answers all the way up until someone checks one, and by then twelve dashboards depend on it.
None of this argues for going back. It argues for treating the transform line as something you decide deliberately rather than inherit from an architecture diagram.
How to decide
Three rules, in priority order.
- Anything you are not permitted to store goes in flight. This one is not a trade-off and not negotiable.
- Anything true of the data regardless of use goes on landing. If two teams would both want it done, it belongs before either of them.
- Everything that encodes a decision goes in the model, in version control, where it can be reviewed and where the definition is agreed once and used everywhere.
Then put checks at the boundaries between the three, because a silent schema change upstream invalidates everything downstream of it regardless of which layer did the work.
The takeaway
ELT won the argument the comparison tables were having. That argument ended years ago, and repeating it does not help anyone build a pipeline.
The question worth asking about any transformation is not which letter comes second. It is: does this belong before the data lands, in the layer that makes it usable, or in the layer that decides what it means? Get those three boundaries right and the acronym stops mattering.
That is how Datablast is built — ingestion that can drop or mask on the way in, a landing layer that is the same for every consumer, and a modelling layer where definitions live in version control instead of in someone’s memory.
Originally published on datablast.io in March 2024. Rewritten and expanded September 2026.
See it on your own data
20 minutes, your questions, a live walkthrough.