In Short: The Same Letters, a Different Centre of Gravity
ETL and ELT name the same three activities - extract data from sources, transform it into analytical shape, load it somewhere useful - and disagree only about where the transformation happens. ETL transforms in flight: a middleware tool reshapes data before it lands, and only the finished product arrives. ELT lands raw data first and transforms inside the destination, using the platform's own engine.
The industry's shift to ELT was not fashion; it followed two hard changes - storage became too cheap to justify discarding raw data, and platform engines became too fast to justify a separate transformation tier. Understanding that reasoning tells you exactly when each pattern still applies.
Why ELT Won the Default
Raw history survives. Landing first means you keep what actually arrived. When transformation logic changes - and it always changes - you re-derive from bronze instead of re-extracting from sources that may no longer hold the history. Pure ETL throws the original away by design.
The platform engine does the work. Spark and modern SQL transform at scales that made dedicated ETL servers obsolete: the compute is already there, priced by consumption, elastic on demand.
One codebase, closer to the data. Transformations live in the platform - notebooks, SQL, dataflows - versioned and tested alongside everything else, rather than locked in a middleware tool's proprietary designer.
Schema-on-arrival tolerance. Sources change without permission. ELT absorbs the change at landing and fixes it in transformation; in-flight ETL breaks at 2am instead.
Medallion architecture is this philosophy made explicit: bronze is the L, silver and gold are the T, and the whole lakehouse pattern assumes it.
Where Classic ETL Still Earns Its Keep
The exceptions are real and worth naming, because they are compliance- and cost-shaped rather than nostalgic.
- Transform-before-land obligations: masking or dropping sensitive fields that must never touch the analytical platform unprotected - a governance requirement, not a preference
- Firehose economics: telemetry sources where landing everything raw is genuinely wasteful; filter or aggregate at the edge (though event stores have raised the bar for what counts as too much)
- Legacy targets: destinations that expect finished data and cannot host transformation
Even in these cases, the modern implementation is usually light transformation on the way in plus ELT thereafter - a hybrid, not a return to the middleware era.
What This Looks Like in the Microsoft Stack
Extraction and loading: Data Factory pipelines for scheduled movement, mirroring for replication without pipelines, shortcuts for not moving data at all - the modern L is often not a copy. Transformation: notebooks, SQL and Dataflows Gen2 inside Fabric, organised as medallion layers; on the Databricks side, LakeFlow plays the same roles with the same philosophy.
The takeaway for anyone planning pipelines: default to ELT, treat every transform-before-land as an explicit, justified exception, and let the raw layer be the insurance policy it is. The two letters swapped because the economics did; the economics are not swapping back.
Sources and Further Reading
Frequently asked
Extract, Transform, Load versus Extract, Load, Transform. Same three activities; the order is the philosophy. ETL transforms data in flight, before it lands in the destination. ELT lands raw data first, then transforms inside the destination platform using its engine.
Economics and engines: lake storage became cheap enough to keep raw data, and platform engines (Spark, modern SQL) became powerful enough to transform at scale in place. Landing raw first also preserves history - you can re-derive when logic changes, which pure ETL cannot.
Medallion is ELT with discipline: bronze is the loaded raw data, silver and gold are the transformations, run inside the platform. If you build bronze-silver-gold in Fabric or Databricks, you are doing ELT by construction.
When data must be shaped or filtered before it may land: masking sensitive fields for compliance, trimming firehose sources where landing everything is wasteful, or feeding legacy targets that expect finished data. The pattern survives at the edges, chosen deliberately.
Fabric's Data Factory (pipelines and Dataflows Gen2) handles extract and load plus orchestration; transformation runs in notebooks, SQL and dataflows inside the platform; mirroring covers replication-style loading with no pipeline at all. On Databricks, LakeFlow plays the equivalent role.
