What ETL means
Extract, Transform, Load: data is pulled from the source, cleaned and reshaped on a separate processing server or ETL tool, and only the finished, transformation-complete result is loaded into the destination warehouse. This was the standard pattern when warehouse compute was expensive and tightly provisioned — every bit of transformation work done outside the warehouse was cost saved inside it.
What ELT means
Extract, Load, Transform: raw data is loaded into the warehouse first, essentially unmodified, and the transformation happens afterward as SQL running directly inside the warehouse. The raw layer typically persists (this is effectively the "Bronze" layer in a Medallion Architecture), so transformation logic can be corrected and rerun against the original data without re-extracting from the source.
Why cloud warehouses flipped the order
Platforms like Snowflake, BigQuery, and Databricks made large-scale SQL compute cheap, elastic, and billed by actual usage rather than fixed server capacity. That removed the core incentive behind ETL — minimizing processing on an expensive, separately-provisioned transform layer — because the warehouse itself could now cheaply absorb that work. Loading raw data first also simplified pipelines: extraction and loading became a largely mechanical, one-size-fits-all step, while all the business logic lived in version-controlled SQL that could be tested, reviewed, and rerun independently.
SQL-based transformation example
-- Raw data loaded as-is into a staging table (the "L" in ELT)
SELECT * FROM raw_orders LIMIT 5;
-- order_id | raw_amount | raw_status | ingested_at
-- Transformation happens afterward, entirely in SQL (the "T" in ELT)
CREATE OR REPLACE VIEW clean_orders AS
SELECT
order_id,
CAST(raw_amount AS DECIMAL(10,2)) AS amount,
UPPER(TRIM(raw_status)) AS status,
ingested_at
FROM raw_orders
WHERE raw_amount IS NOT NULL;Because the raw table still exists, a bug in this transformation logic can be fixed and rerun instantly against the same raw data — no need to re-pull anything from the source system.
When ETL still wins
- Compliance-driven masking — when sensitive data must never be stored, even temporarily, in its raw form in the destination system.
- Limited-compute destinations — some target systems genuinely can't absorb heavy transformation workloads efficiently.
- Non-SQL transformation logic — complex custom code, unstructured text processing, or non-tabular data that SQL doesn't express well.
Side-by-side comparison
| Aspect | ETL | ELT |
|---|---|---|
| Where transformation runs | Separate processing layer | Inside the warehouse, in SQL |
| Raw data retained? | Usually not | Usually yes, as a staging/bronze layer |
| Best fit | Compliance masking, limited-compute targets | Modern cloud warehouses with cheap elastic compute |
| Typical tooling | Dedicated ETL platforms | SQL + transformation frameworks like dbt |
Key takeaways
- ETL transforms before loading; ELT loads raw data first and transforms it with SQL inside the warehouse.
- Cheap, elastic cloud warehouse compute is what made ELT the modern default.
- ELT's retained raw layer makes fixing and rerunning transformation logic much cheaper than re-extracting from source.
- ETL still wins for compliance masking, limited-compute destinations, or non-SQL transformation needs.