Both move data from source to destination. Where the transformation happens changes everything about cost, flexibility, and how fast you can iterate.
Every data pipeline does three things: extract data from a source, transform it into a usable shape, and load it into a destination. ETL and ELT are the same three steps in a different order, and that reordering — transform before loading, or transform after — has real consequences for cost, flexibility, and how quickly your team can change its mind about what "usable shape" means.
Extract, Transform, Load: data is pulled from the source, transformed into its final shape in a separate processing step, and only then loaded into the warehouse. This was close to mandatory when warehouse storage and compute were both expensive — you transformed data before loading it because loading raw, unrefined data and transforming it in place simply cost too much.
ETL still earns its place today when the raw data volume is large and only a small, well-defined subset is actually needed downstream — transforming (and discarding the rest) before loading avoids paying to store and query data nobody uses. The tradeoff is flexibility: changing the transformation logic means reprocessing the pipeline, not just rewriting a query against data that's already sitting in the warehouse.
Extract, Load, Transform: raw data is loaded into the warehouse first, and transformation happens afterward, using the warehouse's own compute. This became the more common default as cloud warehouses like BigQuery and Snowflake made large-scale compute cheap and elastic — it's no longer prohibitively expensive to store data in something close to its raw form and transform it on demand.
The big advantage is iteration speed: because the raw data is already sitting in the warehouse, changing a transformation is a matter of rewriting a query or a dbt model, not re-running an entire extraction pipeline. It also means the same raw data can support multiple different transformed views for different teams, without extracting it multiple times.
Raw data volume is large and only a small transformed subset is actually needed.
Sensitive data needs to be filtered or masked before it ever reaches the warehouse.
Your transformation logic is stable and doesn't need frequent iteration.
You want to iterate on transformation logic quickly without re-running extraction.
Multiple teams need different transformed views of the same raw data.
You're running on a modern cloud warehouse where compute is elastic and comparatively cheap.
Not always — cheap doesn't mean free, and transforming large raw datasets repeatedly inside the warehouse has a real, ongoing compute cost. ELT is usually the better default today, but ETL still makes sense when raw data volume is large and only a small transformed subset is actually needed.
Yes, and it's common — lightweight transformations (filtering, basic cleaning) happen before loading, while heavier business-logic transformations happen inside the warehouse where they're easier to iterate on and audit.
Not if it's designed properly — raw data lands in a staging layer first, and quality checks run as part of the transformation step inside the warehouse, not as an afterthought. The control point moves, but it doesn't disappear.
ETL — the transformation logic has to be built and maintained outside the warehouse before load, versus ELT where raw data lands first and transformation happens with warehouse compute.
Yes, with a streaming ingestion layer feeding the warehouse continuously — ELT's simplicity actually pairs well with streaming since transformation logic can evolve without touching the ingestion path.
A practical comparison of data warehouses, data lakes, and lakehouses — where each one fits, what they cost, and how to pick the right one.
Read the guide