ETL vs ELT: How Modern Data Pipelines Work

ETL and ELT both describe how raw data gets from source systems into a place you can analyze it, and they differ only in the order of one step: whether transformation happens before loading (ETL) or after (ELT). That single reordering has significant consequences for pipeline architecture, storage costs, and how quickly new data becomes queryable.

ETL: transform, then load

Extract, transform, load is the older pattern, built for an era when warehouse storage and compute were both expensive. The pipeline extracts data from a source, transforms it in a separate processing step — cleaning, reshaping, aggregating, joining against reference tables — and only then loads the finished, curated result into the destination warehouse.

The transformation step typically runs on dedicated infrastructure outside the warehouse itself, using a tool purpose-built for the job. This keeps the warehouse doing only what it’s good at (fast queries on clean, structured data), but it means the transformation logic lives in a separate system from the data it’s operating on, and any change to that logic requires re-running the whole extract-transform cycle rather than just re-querying data already sitting in the warehouse.

ELT: load, then transform

Extract, load, transform flips the order: raw data is extracted and loaded into the destination immediately, in whatever shape the source provides it, and transformation happens afterward using the destination’s own compute — typically SQL queries run directly inside a warehouse or lakehouse.

This approach became practical once cloud warehouses made storage cheap and compute elastically scalable — there was no longer a strong reason to avoid storing raw, unrefined data, since storage costs were no longer the bottleneck they used to be. It also means the raw data is preserved unmodified; if a transformation turns out to be wrong, you can rewrite the SQL and rerun it against the same raw records rather than re-extracting from the source system again.

Comparison table

	ETL	ELT
Transform location	Separate processing layer	Inside the destination warehouse
Raw data preserved	Often discarded after transform	Kept, transform is non-destructive
Compute used	Dedicated transformation infrastructure	Warehouse’s own query engine
Best fit	Warehouses with limited compute, strict schemas	Cloud warehouses/lakehouses with elastic compute
Reprocessing	Requires re-extracting from source	Just rerun the transform query
Latency to first landing	Slower — data waits for transform	Faster — raw data lands immediately

Why the order matters in practice

Because ELT loads raw data before transforming it, that raw data is queryable immediately, even before curated tables exist — useful for exploratory analysis or when you need a stopgap answer while the “official” transformed version is still being built. It also plays naturally with a data lakehouse, which is built specifically to hold both raw and transformed data in one place using open file formats rather than requiring a hop out to a separate transformation system.

ETL’s upfront transformation step still matters when the destination genuinely can’t do the transformation work cheaply — a strict, compute-constrained warehouse, or a case where sensitive fields need to be filtered or masked before they’re ever allowed to land in the destination at all, for compliance reasons that make “load raw first” unacceptable regardless of cost.

How both connect to the rest of the pipeline

Neither ETL nor ELT describes how data gets extracted in the first place. That’s frequently handled by change data capture, which streams row-level changes out of a source database as they happen, or by a message broker like Kafka buffering events between the source and the pipeline. ETL and ELT are about what happens to that extracted data next, not how it’s captured.

The transformed result also usually lands in a schema optimized for analytical queries — a columnar store rather than the row-oriented format the source OLTP database uses — since the read patterns for reporting and analytics look nothing like the read patterns of the application that originally produced the data. And any pipeline, ETL or ELT, eventually has to handle schema changes in the source system gracefully, which is the same problem database migrations solve on the application side, just applied to a pipeline instead of a single database.

Which to use

ELT has become the default for teams building on modern cloud warehouses and lakehouses, largely because storage is cheap enough that keeping raw data around is no longer a meaningful cost, and because SQL-based transformation tools running inside the warehouse are easier to test, version, and iterate on than a separate transformation codebase. ETL remains the right call when compliance requires filtering sensitive data before it ever lands in the destination, or when the destination system genuinely lacks the compute to do transformation work itself.

The takeaway

ETL transforms data before loading it, keeping the destination clean but making raw data harder to recover and reprocess. ELT loads raw data first and transforms it afterward using the destination’s own compute, trading a larger raw storage footprint for cheaper reprocessing and immediate access to unrefined data. Cheap cloud storage and elastic warehouse compute have made ELT the more common default, but ETL still has a place wherever data must be filtered or masked before it’s allowed to land at all.