ETL versus ELT in cloud data platforms

WHAT THIS TESTS This checks whether you understand the ordering of transformation versus loading and why modern cloud platforms shifted toward ELT.

A GOOD ANSWER COVERS In ETL, data is extracted from sources, transformed in a dedicated processing engine, and then the cleaned, modeled result is loaded into the target. This was the norm when warehouses were expensive and inflexible and you only wanted to store final, conformed data. In ELT, data is extracted and loaded in raw form into a powerful cloud warehouse or lake first, and transformation happens afterward inside that system using its elastic compute, usually with SQL or tools like dbt. ELT's advantages in the cloud are significant: object storage and warehouse storage are cheap so keeping raw data is affordable, ingestion is faster because you defer heavy processing, you retain the raw source so you can re-derive new models later without re-extracting, and you exploit the massively parallel compute of engines like BigQuery, Snowflake, or Redshift. The tradeoff is that raw, possibly sensitive data lands in the platform, so governance, access control, and sometimes pre-load masking still matter.

COMMON WRONG ANSWERS Claiming ELT is universally superior with no downsides, ignoring compliance cases where sensitive fields must be masked before loading. Saying the only difference is word order. Forgetting that ELT depends on the target having strong in-place compute. Assuming ETL is obsolete; it remains valid for constrained targets and heavy pre-load cleansing.

LIKELY FOLLOW-UPS Where does dbt fit. How do you handle PII in an ELT model. When would you still pick ETL.

ONE CONCRETE EXAMPLE A team lands raw event JSON directly into Snowflake, then runs dbt models to clean and aggregate it into reporting tables. Months later a new metric is needed, and because the raw data is retained they build it without re-ingesting from the source systems.