How ETL Works
ETL stands for extract, transform, load. Data is pulled from source systems, transformed in a separate staging environment, and then loaded into the warehouse in its final, clean form. The transformation step — deduplication, type conversion, business-rule application, aggregation — happens outside the warehouse on dedicated compute resources.
This approach made sense when warehouse compute was expensive and limited. By doing the heavy lifting before loading, you kept the warehouse lean and reserved its resources for queries rather than transformation. ETL pipelines are typically orchestrated by a scheduling tool that runs each step in sequence and handles failure recovery at each stage.
The drawback is complexity. A separate transformation environment means additional infrastructure to maintain, monitor, and scale. Changes to business logic require modifying the transformation layer, reprocessing affected data, and reloading it — a slower iteration cycle than modifying a query inside the warehouse.
ETL pipelines also introduce a failure surface outside the warehouse. If the transformation environment goes down, data stops loading even though the warehouse itself is healthy. Monitoring, alerting, and failover for the transformation layer are additional operational responsibilities that the team must carry alongside warehouse operations.
How ELT Works
ELT stands for extract, load, transform. Data is pulled from source systems and loaded into the warehouse in raw or lightly processed form. Transformation happens inside the warehouse itself, using SQL or the warehouse-native processing engine to clean, join, and reshape data into analytical models.
Cloud-native warehouses with scalable compute made this approach practical. The warehouse can spin up resources for transformation, run the job, and scale back down — so the cost is bounded by the work performed rather than by a fixed staging environment. For teams that think in SQL, ELT keeps all transformation logic in one place, which simplifies debugging, version control, and iteration.
The tradeoff is that raw data occupies warehouse storage until transformation runs, which can increase storage costs. Transformation queries also consume warehouse compute credits, so poorly written transformation logic or unoptimized queries can spike the bill. The cost-drivers guide on this site covers how to manage these costs as data volume grows.
Version control is another ELT advantage. Because transformation logic is written in SQL inside the warehouse, it can be stored in a repository, reviewed in pull requests, and tracked across changes just like application code. This traceability is harder to achieve with external ETL tools that store logic in proprietary formats.
Cost and Performance Tradeoffs
ETL reduces warehouse compute usage because transformation happens elsewhere, but it adds the cost and operational burden of a separate processing layer. If your organization already operates an ETL platform, the incremental cost may be low. If you are building from scratch, standing up a transformation environment adds engineering time and infrastructure spend.
ELT simplifies the pipeline architecture by consolidating everything inside the warehouse, but it shifts transformation compute costs to the warehouse bill. If your warehouse pricing is usage-based, large transformation jobs can create cost spikes that are hard to predict. If your warehouse runs on reserved capacity, you need to size that capacity for both transformation and query workloads.
For most teams starting a new warehouse project today, ELT is the simpler path because it avoids the separate infrastructure and keeps the engineering workflow unified. For teams with existing ETL infrastructure and pipelines that already work, switching to ELT may introduce more disruption than benefit. Evaluate based on what you have, not on which acronym is trending.
Choosing Based on Your Infrastructure
If your warehouse is a legacy on-premises system with limited compute capacity, ETL is often the practical choice because the warehouse cannot absorb transformation workloads alongside analytical queries without degradation. The separate transformation layer protects query performance by keeping heavy processing off the warehouse engine.
If your warehouse is a cloud-native platform with elastic compute, ELT leverages that scalability by letting the warehouse handle both transformation and querying on demand. The simplicity of a single environment for all data processing reduces operational complexity and makes it easier for a small team to manage the pipeline end to end.
Hybrid environments — where some sources feed through existing ETL pipelines while new sources load directly via ELT — are common during migration. This is a valid transitional state, not a failure to choose. Migrate sources to ELT incrementally as engineering capacity allows, and retire legacy ETL pipelines once the warehouse handles those sources natively. The migration checklist on this site covers sequencing for transitions between pipeline architectures.
Pipeline choice depends on your warehouse platform, data volume, and team skills — neither approach is universally superior.