ELT vs ETL: choosing a pipeline pattern
When to transform in-flight and when to land raw data first.
The distinction in one paragraph
ETL transforms data before it lands in the warehouse; ELT lands raw data first and transforms it inside the warehouse with SQL. The acronyms are old, but the trade-off is current: transform-in-flight gives you control and compactness, land-raw-first gives you auditability and flexibility.
Why ELT became the default
Modern columnar warehouses made in-warehouse transformation cheap, and storage prices made keeping raw copies a non-issue. With raw data preserved, you can re-derive any downstream table when logic changes — no re-extraction, no asking the source system for last quarter again.
Raw-first also makes debugging honest: when a metric looks wrong, you can trace it from the dashboard back through each transformation to the exact source rows.
Where ETL still wins
Three cases: PII you're not allowed to land (mask or drop in-flight), high-volume telemetry where you only need aggregates, and integrations where the source format is so gnarly that a typed, validated landing zone saves everyone downstream.
In practice: both, deliberately
Most real platforms run a hybrid: light in-flight cleanup (typing, deduplication, PII handling) and substantive business logic in the warehouse where it's versioned and testable. DataSquares Pipelines supports both — transform steps in the pipeline for the in-flight work, SQL models in the warehouse for the rest.
The pattern to avoid is accidental hybrid: business logic scattered across pipeline steps and warehouse views with no rule for what lives where. Decide the boundary once and write it down.
See it on your data
A 30-minute walkthrough beats a thousand words.