ETL vs ELT: How Cheap Cloud Compute Flipped the Order of Data Pipelines
Why transforming data before loading it made sense when compute was scarce, why cloud warehouses reversed that order, and when the older ETL pattern still wins.
Why transform-before-load made sense in 2005
Extract, Transform, Load — ETL — was the default pattern for a straightforward reason: the warehouses data ultimately landed in were expensive, capacity-constrained systems, and warehouse compute cycles were treated as a scarce resource not to be wasted on cleaning and reshaping raw data. So the transformation step happened on a separate staging server, before the data ever touched the warehouse: extract from source systems, transform (clean, join, aggregate, reshape) on dedicated ETL infrastructure, and only load the final, warehouse-ready tables into the expensive system at the end.
This had a real cost: the staging server needed to be sized for peak transformation load even though it sat mostly idle between batch windows, and every new transformation requirement meant provisioning more of that dedicated infrastructure ahead of time, a slow and expensive process when infrastructure meant physical servers with multi-month procurement cycles. It also meant raw, untransformed data was often discarded after transformation, since storing it was expensive too — so if a transformation bug was discovered later, or the business wanted to ask a new question of the original raw data, it might simply be gone.
What cloud warehouses changed
Cloud warehouses like Snowflake, BigQuery, and Redshift broke the assumption that warehouse compute was scarce and separate from transformation compute, because they made compute itself elastic and cheap — you can spin up a large cluster for twenty minutes to run a heavy transformation and pay only for those twenty minutes, rather than provisioning fixed capacity for a peak load that occurs rarely. This made it economically sensible to load raw data into the warehouse first, exactly as extracted from the source, and run the transformation as SQL queries inside the warehouse itself — Extract, Load, Transform, or ELT.
The practical effect on pipeline design was substantial. Because raw data lands untouched, you always retain a faithful copy of exactly what the source system produced, so any transformation bug can be fixed by simply re-running the SQL against the still-present raw data, rather than needing to re-extract from a source system that may have already moved on or purged its own history. And because the transformation logic is now SQL running inside the warehouse rather than custom code running on separate infrastructure, tools like dbt could turn transformation into a layer of version-controlled, testable SQL models that compile down to warehouse queries — a workflow that simply didn't exist when transformation happened on bespoke ETL servers.
The layered transform: bronze, silver, gold
ELT pipelines commonly organise transformation into successive layers, often called bronze (or raw), silver (or cleaned), and gold (or business-ready) — a naming convention popularised by the medallion architecture. The bronze layer is raw data loaded essentially as-is from source, preserving even malformed or duplicate records because the goal here is fidelity to the source, not usability. The silver layer applies deduplication, type casting, null handling and basic validation, producing a clean but still fairly granular representation. The gold layer applies business logic — joining across domains, aggregating to the grain a dashboard actually needs, applying the star-schema modelling appropriate for BI consumption.
Each layer is a distinct set of tables, and because all three sit inside the same warehouse, an engineer debugging a wrong number in a gold-layer dashboard can trace the value backward through silver to bronze, using ordinary SQL, to find exactly where the discrepancy was introduced — something that was much harder when transformation logic lived scattered across custom ETL scripts with no queryable intermediate state. This traceability, more than the raw performance argument, is often what teams cite as ELT's biggest practical win over the old approach.
When ETL still wins
ELT isn't a strictly better replacement for ETL in every situation; it's a trade-off that favours a different set of constraints. Sensitive data — health records, payment card numbers, anything under strict regulatory handling requirements — often needs to be masked, tokenised, or filtered out before it's allowed to land anywhere, including a cloud warehouse's raw layer, which means the transform genuinely has to happen before load, not after, to satisfy compliance requirements around where unmasked data is permitted to exist at all.
Extremely high-volume streaming sources are another case where pure ELT struggles: continuously loading fully raw, unaggregated event data into a warehouse and only aggregating afterward can be far more expensive than pre-aggregating with a stream processor (like Flink or Kafka Streams) before load, because warehouse compute, while elastic, still costs meaningfully more per unit of work than purpose-built streaming infrastructure for high-throughput simple aggregations. In practice most mature data platforms end up running a hybrid: light transformation (filtering obvious junk, masking sensitive fields, basic pre-aggregation of firehose volumes) before load, with the bulk of business logic and modelling handled as ELT once the data is safely and cheaply sitting in the warehouse.
Frequently Asked Questions
What is the core difference between ETL and ELT?
ETL transforms data on separate infrastructure before loading the finished result into the warehouse; ELT loads raw data into the warehouse first and performs transformation afterward using the warehouse's own compute, typically via SQL.
Why did cloud data warehouses make ELT more practical?
Because cloud warehouses offer elastic, pay-per-second compute rather than fixed capacity, running transformation workloads inside the warehouse became affordable, removing the old incentive to keep transformation on separate, carefully provisioned infrastructure.
What is the medallion (bronze/silver/gold) pattern?
It's a layered approach to ELT transformation where bronze holds raw, largely untouched data, silver holds cleaned and validated data, and gold holds business-ready, aggregated tables suited for dashboards, with each layer traceable back to the one before it.
Does ELT mean you never need to transform data before loading it?
No; cases involving regulated sensitive data that must be masked before it lands anywhere, or extremely high-volume streaming sources better pre-aggregated by dedicated stream processors, still favour transforming at least partially before load.