The difference, precisely
Both patterns move data from a source system into an analytical destination; they differ in where transformation happens relative to loading.
ETL (Extract, Transform, Load) transforms data in a separate processing layer before it reaches the destination. The warehouse only ever receives clean, modelled data. ELT (Extract, Load, Transform) loads raw data into the destination first, then transforms it there using the destination compute engine itself, typically through SQL run by a tool such as dbt.
Why ELT became the default
ELT was impractical before cloud data warehouses separated storage from compute and made both cheap and elastic. Older on-premise warehouses had fixed, expensive compute, so transforming data before loading protected that scarce resource. Snowflake, BigQuery, Redshift and Synapse removed that constraint: warehouse compute now scales on demand, so running transformations inside the warehouse is no longer the risk it once was.
- Raw data lands in the warehouse immediately, so historical source data is preserved even if the transformation logic changes later.
- Transformations are written in SQL and run inside the warehouse, removing the need for a separate transformation cluster or ETL server.
- Tools such as dbt turned warehouse-native transformation into version-controlled, tested code, closing the main gap ELT previously had against ETL tooling.
- Iteration is faster: changing a transformation means changing a SQL model and rerunning it, not redeploying a separate ETL pipeline.
When ETL is still the better choice
- Sensitive data that must be masked, tokenised or filtered before it ever reaches the destination, for regulatory or contractual reasons — landing raw PII in a warehouse, even briefly, may not be acceptable.
- Very large volumes where transforming before load meaningfully reduces the data actually transferred and stored.
- Destinations without strong native compute — loading into an operational database or a simpler system that was never designed to run heavy transformations.
- Complex transformations that genuinely need a general-purpose language rather than SQL, such as certain machine learning feature engineering steps.
- Real-time or near-real-time pipelines where transformation happens in-flight (in a stream processor) rather than after landing in a batch destination.
Most real pipelines are a hybrid
In practice, a pure ETL or pure ELT pipeline is less common than a hybrid: light transformation in-flight (masking a sensitive column, standardising a timestamp format) before load, followed by the bulk of business logic modelling — joins, aggregations, metric definitions — as ELT inside the warehouse using SQL. This gets the compliance and volume benefits of transforming early where they matter, and the iteration speed and maintainability of ELT for the modelling layer.
Tooling on each side
- ELT: dbt for transformation logic; Fivetran, Airbyte or custom scripts for extraction and load; a cloud warehouse (Snowflake, BigQuery, Redshift, Synapse) as the destination.
- ETL: Informatica, Talend, or custom Spark or Python jobs for transformation; often paired with Airflow for orchestration between the extraction, transformation and load stages.
- Both patterns increasingly sit inside the same platform — a warehouse doing ELT modelling for analytics, alongside an upstream ETL step handling PII masking before anything lands.
How to choose without defaulting to fashion
ELT is the sensible default starting point for a new cloud data platform because it is faster to build and iterate on, and the tooling ecosystem (particularly dbt) is mature. Depart from that default deliberately, driven by a real constraint — a compliance requirement to mask data before it lands, a genuine volume problem, or a transformation need SQL cannot express well — rather than by habit from a previous on-premise platform or by an assumption that ELT is always correct regardless of context.
Frequently asked questions
Not always. ELT shifts transformation cost onto warehouse compute, which is billed by the warehouse; ETL uses a separate processing layer that is billed separately. Which is cheaper depends on data volume, transformation complexity and the specific pricing model of the warehouse in use — it is worth modelling both for a genuinely large workload.
Yes, and most mature platforms do. A common pattern is light in-flight transformation (masking, standardising formats) before load, followed by the bulk of business logic as ELT inside the warehouse using a tool like dbt.
Not if it is designed properly. Data quality tests can and should run on the raw landed data before it flows into modelled layers, and dbt supports exactly this pattern through source and staging model tests.
No, but it has become close to a default choice because it turns SQL transformations into version-controlled, tested, documented code, which is otherwise the main advantage ETL tools historically had over hand-written SQL scripts.
Not necessarily avoid it entirely, but they usually need a hybrid: sensitive fields masked or tokenised in-flight before landing (an ETL step), followed by ELT for the rest of the modelling that does not touch regulated data directly.
Incrementally, by domain rather than all at once: land raw data for one subject area, rebuild its transformation logic as SQL models in the warehouse, validate the outputs match, and only then retire the old ETL job for that domain.
How we can help
ELT pipelines with tests, lineage and governance built in from day one.
Data Warehouse vs Lakehouse: How to ChooseThe platform decision that usually comes before the ETL vs ELT one.