Extract-Load-Transform

Company data does not arrive in a shape anyone can analyze. Payments sit in the payments database, taps and clicks sit in an event log, ad performance sits with the ad platform, and every one of them writes dates and currency amounts its own way. Something has to bring these together and put them on a common footing.

For a long time that work happened in transit. Pull from the source, clean it up on an intermediate server, and load only the cleaned result into the data warehouse — the storage layer that holds analysis data in an organized structure. Warehouse storage and compute were expensive back then, so putting only finished data in there was the sensible move.

The cost of that choice showed up later. About six months in, Mia at Pagedeck asked to see signup numbers with internal test accounts included. The warehouse only had the figures with those accounts already filtered out, and the filtered-out rows existed nowhere. Answering the question meant pulling a year of history out of the source system again, which took three days and blocked the decision that had prompted it.

As warehouse compute got cheap and fast, reversing the order became viable. Load everything in close to its original form, then do the cleaning inside the warehouse — that is extract-load-transform (ELT). When a definition changes, nothing has to be pulled from the source again; the warehouse recalculates.

Three stages, and the name is the order.

1. Extract — read the data out of the source. Payment databases, app event logs, and the query endpoints ad platforms expose are the usual sources. Nothing is corrected here; rows come out as they are, which keeps this stage simple enough that one job per source is usually all it takes.
2. Load — write what came out into the warehouse as is. Teams usually carve out an area reserved for raw copies and stack the data there, keeping the source system's column names untouched, so anyone can trace later how a given value arrived.
3. Transform — reshape it inside the warehouse using SQL, the standard language for pulling stored data out under conditions and computing over it.

The transform is rarely one step. It is built as layers.

1. Raw layer — exactly what was loaded. Nobody edits this.
2. Cleaned layer — dates put in one format, payments that arrived in other currencies converted to dollars, test accounts flagged. Flagged, not deleted. Deleting puts you back at the original problem.
3. Metric layer — the tables that actually reach a dashboard. Monthly revenue, signups by channel, and anything else where a metric definition has fixed the counting rule.

Two operational choices come with it: how often the pipeline runs, and whether each run pulls everything or only what is new. With 300 million payment records, reloading everything daily is out, so the job pulls only rows created since yesterday. The catch is that historical rows sometimes get corrected at the source and an incremental pull misses those edits, so most teams also recompute the last month in full about once a week and overwrite it.

It fits teams whose questions are still moving. In a company's first year, the rule for counting signups keeps shifting — as of which moment, dormant accounts in or out. With the raw data sitting in the warehouse, a changed rule costs one rerun of a set of queries. Without it, every changed rule drags a source extraction along behind it.

Many sources also favor this order. Instead of writing transform code per source in the middle, you write only the extraction and handle all the shaping inside the warehouse in one language. The other gain is who can make changes. Editing code on an intermediate server needs an engineer; editing a query in the warehouse is something the analytics side does directly.

There are three limits.

1. It costs money. Data nobody will use gets loaded anyway, and the transform burns warehouse compute, so storage and compute bills rise together. If the source is enormous and only a slice of it ever gets used, reducing it before loading is cheaper, and the gap widens every month the raw copies keep accumulating.
2. Personal data lands in the warehouse. Personally identifiable information (PII) means data that can single out an individual, such as a name or a phone number, and loading raw copies stacks it up in storage. You need masking during load or a separate access split inside the warehouse.
3. You get tied to the warehouse. Transform logic rides on that warehouse's dialect and features, so switching warehouses later means moving the transforms too.

"This one's ELT, so the raw data is still there. I'll change the rule and pull it again."

No source work is needed; the warehouse can recompute it.

"Let's load all the logs first and transform later."

A proposal to run the pipeline in ELT order rather than cleaning in transit.

"Our warehouse bill doubled this month. Let's stop loading the sources nobody queries."

The price of loading everything has shown up on an invoice.

At Pagedeck, Theo builds the extraction job for each source and Mia edits the metric-layer queries herself, which is the division of labor this order makes possible. When she decides that a signup counts only after email verification, she changes one line in the cleaned layer and recomputes the past year without going through Theo. Reprocessing a past window like that to fill it back in is called a backfill.

The common misreading is that ELT supersedes extract-transform-load (ETL) and is therefore always the better choice. It arrived later and current tooling pushes it, so the impression is easy to form. What actually separates them is the price of warehouse compute and the odds that your definitions change. Where the rules are settled and the source runs to tens of terabytes, loading all of it multiplies the bill. Teams do switch on trend and switch back after the first invoice, having paid for a year of logs that no query ever touched.

The other one is assuming that keeping the raw data means the cleaning is optional. Once the load finishes, the data is in the warehouse and looks ready to query. But the transform didn't disappear, it moved — and querying the raw layer directly, with no cleaned layer in between, means each person filters test accounts their own way and the same metric comes back with different numbers. Data quality is something you maintain under either order.