ETL vs ELT and Transformation Placement

## The three operations Every analytics pipeline does three things. **Extract** reads data out of a source system — an application database, a SaaS API, a partner's file drop. **Load** writes it into the target analytical store. **Transform** reshapes it: fixing types, deduplicating, joining across sources, applying business rules, aggregating. ETL and ELT are the same three operations. They differ only in whether the transform happens *before* the load or *after* it. ## ETL: transform between the systems In ETL, data is extracted into a separate processing tier, transformed there, and only the finished result is written to the target. That processing tier is real infrastructure someone owns: a dedicated server running a vendor's engine, a graphical mapping tool, a distributed processing cluster, or hand-written code on a scheduled box. The target sees only rows that already conform to the intended model. That has consequences. The target stores curated output only, so it stays small and tidy. The source-shaped data never lands anywhere queryable — often it exists only as bytes in flight. The transformation is written in whatever language the processing tier speaks. And the pipeline's throughput is the capacity of that tier, which has to be sized, patched, monitored and paid for whether or not it is busy. ## ELT: transform inside the target In ELT, extraction writes source-shaped data straight into the target with minimal change, and all the reshaping runs afterwards as statements the target executes — typically SQL reading tables and writing tables inside the warehouse or lakehouse. Business logic becomes queries, and those queries run on the same engine that serves analysts. The consequences invert. Raw data is in the platform and can be inspected and re-read. Transformations are set-based operations over columns rather than procedural row-at-a-time processing. There is no separate cluster to operate. The target's bill now covers transformation as well as reporting. And because the untouched input is retained, any downstream table can be rebuilt by re-running the logic against data that is still there. ## What actually moves The shorthand is "the L and the T swap places", but the substantive change is that *the compute doing the transformation* moves — from a system the data team operates into the system that already holds the data. Everything else follows from that one relocation: who pays, what language the logic is written in, whether the raw survives, and how much data has to cross a network. ## Why the raw copy is the decisive difference In ETL, the transformed output is usually the only surviving representation of that day's data. If the business rule was wrong, the correct history may no longer be obtainable: operational sources update rows in place, purge old records, and rate-limit or bill for large re-reads. In ELT, the landed extract is still sitting there, so correcting logic is a re-run rather than a re-extraction. Interviewers care much more about this property than about the letters. ## "ELT" does not mean "nothing happens before the load" Even an ELT pipeline does technical work in flight: decompressing files, decoding character sets, parsing a nested payload into a tabular shape, assigning types, partitioning by ingestion time, and frequently masking or tokenising restricted fields that policy forbids from landing in raw form. What moves to the target is the *business* transformation — cross-source joins, deduplication, derived metrics, conformed naming. A candidate who says "ELT means we don't transform" has misread the pattern. ## When each pattern still fits ELT is the modern default when the target is an elastic columnar analytical engine that can absorb raw volume cheaply and scan it fast. ETL is still the right answer when the target cannot transform at reasonable cost (a small operational database, a fixed-capacity appliance); when the raw data legally may not land in the target; when raw volume is enormous relative to the useful slice, so moving all of it is the dominant cost; or when the work is not expressible in the target's query language at all — parsing binary formats, calling an external service per record, running a model. Most real stacks are hybrids: an EL connector lands raw, in-warehouse SQL builds the models, and a handful of jobs that genuinely need a general-purpose engine run outside and write their results back in. ## Neighbouring vocabulary **EL** on its own describes a connector that only lands data and leaves modelling to someone else — the first half of ELT. **Reverse ETL** is a different pattern entirely: pushing modelled warehouse tables back out into operational SaaS systems so sales and support tools can use them. Neither is a variant of the ETL-versus-ELT choice.