🔀 ETL vs ELT: How Cheap Cloud Compute Flipped the Pipeline Order

About this simulation

For decades, data pipelines followed ETL: Extract from source systems, Transform on a dedicated, fixed-capacity server, then Load the clean result into the warehouse. Transform capacity was expensive and scarce, so it had to happen before loading — and it was the bottleneck. Cheap, elastic cloud compute (Snowflake, BigQuery, Redshift and friends) flipped that order: ELT loads raw data straight into the warehouse first, then transforms it there using compute that scales out on demand.

How it works

• ETL mode — records queue at a fixed-capacity transform engine between extraction and loading. Its throughput never changes, no matter how much cloud compute you have.
• ELT mode — raw records load straight into the cloud warehouse, then transform in parallel across the warehouse's elastic compute nodes.
• The two latency bars update live from the same complexity value, so you can see exactly where each architecture spends its time.
• Adding compute nodes only speeds up ELT's in-warehouse transform — it does nothing for the ETL engine, which is fixed capacity by design.

Controls

• ETL / ELT — switch which pipeline order is currently animated.
• Data volume — how many records per batch flow through the pipeline.
• Transform complexity — how heavy the transformation logic is (joins, aggregations, dedup).
• Cloud compute nodes — parallel workers available inside the warehouse for ELT's in-place transform.
• ↺ Reset pipeline — clears in-flight records. Drag to rotate, scroll to zoom.

Did you know?

Cloud columnar warehouses made storage and compute separately scalable and billed by the second, which is exactly what made "load first, transform later" economical — before that, transforming inside the warehouse would have meant paying premium database compute for work a cheap ETL box could do instead.