A team is moving to a cloud data warehouse with elastic compute. Their new pipeline copies raw source data into staging tables in the warehouse first, then runs SQL models inside the warehouse to clean and reshape it. Which approach is this, and why does it suit the platform?

Extract, load, transform (ELT) loads raw or lightly processed data into the target first and performs transformations there, typically with SQL, often managed by a tool such as dbt. It suits cloud data warehouses because their compute can be scaled elastically and is designed for large set-based operations, so pushing transformation into the warehouse avoids a separate transformation server, keeps raw data available for reprocessing when business rules change, and shortens the time to land new sources. The scenario's sequence, raw data into staging tables and then SQL models inside the warehouse, is ELT. Describing it as ETL with a separate engine contradicts the scenario, since nothing is transformed before loading. The reasoning that loading raw data removes the need to classify or protect sensitive fields is false; raw data still contains PII and must be classified, access-controlled and possibly masked, and ELT arguably increases that obligation because unfiltered data now sits in the warehouse. The claim that cloud warehouses cannot transform tables they store is simply wrong; running SQL on stored tables is their core function. Exam caveat: when data must never land in the target in raw form, ETL is the safer choice. Operational check: confirm that staging schemas are restricted to the pipeline account and that transformation models are version-controlled and tested before deployment.