Why did cheap warehouse compute make ELT the default over ETL?

## The change was economic, not conceptual ETL was not a mistake. It was the correct design for the targets that existed when it became standard. A warehouse ran on a fixed appliance whose capacity you bought years in advance; storage on it was expensive and rationed; and its query engine was tuned to serve reports, not to grind through raw source data. Under those constraints, landing raw data in the warehouse was unaffordable and transforming inside it competed directly with the reports. So teams bought a second engine to do the reshaping and sent the warehouse only the finished, small, modelled result. Every one of those constraints was relaxed by the cloud analytical engines that followed, and the default flipped. ## Storage stopped rationing the raw copy When table data sits on commodity object storage billed per gigabyte-month, keeping a full source-shaped copy of everything you ingest goes from a budget line someone has to defend to a rounding error against the compute bill. That single change is what makes the L-before-T possible at all: ELT's whole premise is that landing everything raw is affordable. ## Compute became elastic and set-based Two properties matter. First, **elasticity**: transformation capacity is rented while a statement runs rather than provisioned for the yearly peak and idle the rest of the time. A nightly rebuild that needs a large cluster for forty minutes pays for forty minutes. A dedicated ETL tier sized for the same peak is paid for continuously. Second, **columnar, massively parallel execution**: reading three columns of a wide table touches only those columns' data, and the engine splits the scan across many workers automatically. Ordinary analytical work — filter, join, group, window — is exactly what these engines are built for, and they typically beat a general-purpose processing tier at it without anyone tuning partitions or memory. ## Extraction became a commodity Once transformation moved into the target, the extract step no longer had to know anything about the model. It only has to land the source faithfully. That is a solved, buyable problem: managed connectors, log-based change capture, and file drops all just deliver rows. Teams stopped spending their scarcest engineers on plumbing whose only job was to move bytes, and the *E* and *L* collapsed into a single commodity step that someone else operates. ## Transformation became reviewable SQL This is underrated in interviews. When the logic is SQL executed by the warehouse, it lives in text files in a repository. It can be diffed in a pull request, tested, documented, and rebuilt from scratch by anyone with warehouse access. Compare that to a proprietary graphical mapping whose meaning lives inside a vendor tool and whose change history is whatever the tool records. Moving the transform into the target also moved it into normal software engineering practice, and it widened the pool of people who can safely change a pipeline from "the data engineering team" to "anyone who writes SQL". ## Reprocessing became cheap Because the input survives, a bug in a business rule is corrected by editing a statement and re-running it over data that is still sitting in the platform. In an ETL pipeline that discarded its input, the same fix requires going back to sources that update rows in place, purge history, throttle large reads, or bill for them. Teams that have lived through one bad restatement rarely give up the raw copy again. ## What still has to happen before the load ELT-first does not mean everything lands untouched. Restricted fields — payment credentials, health identifiers, anything a policy or regulation forbids storing in raw form — are masked, tokenised or dropped in flight, because "we will clean it up after it lands" is not a defence once it has landed. Formats the target cannot parse are converted first. And when the raw volume dwarfs the useful slice, filtering before the move is the cheaper design regardless of fashion. ## The bill that came with the default The honest counterweight: ELT converts a fixed, visible cluster cost into a variable, diffuse per-query cost. A separate ETL tier at least made you decide, once, how much transformation capacity the company was buying. In an ELT stack, every new model quietly adds recurring compute, nobody's individual query looks expensive, and the total grows with headcount. That is why cost attribution per model and disciplined incremental rebuilds show up so quickly on mature ELT platforms — the pattern removed a constraint that had also been acting as a governor.