ETL vs ELT¶
1. Decision¶
Choose ELT (Extract, Load, Transform) as the modern standard for cloud data platforms using scalable data warehouses (Snowflake, BigQuery) and analytics engineering tools (dbt) to load raw data first and transform it flexibly inside the target warehouse; choose ETL (Extract, Transform, Load) for legacy on-premise environments, strict PII privacy compliance requiring pre-load masking, or complex stream transformations before reaching target storage.
2. 30-Second Answer¶
Data integration pipelines move data from operational sources to analytics stores. ETL (Extract, Transform, Load) extracts data from source databases, transforms and cleans it on a separate mid-tier ETL processing server (Informatica, Spark, Talend), and loads the final structured data into the target database. ETL was designed for legacy on-premise warehouses where storage and compute were expensive, but creates processing bottlenecks and loses raw source data context. ELT (Extract, Load, Transform) extracts raw data and loads it immediately into high-performance cloud data warehouses (Snowflake, BigQuery) or Lakehouses (Iceberg/S3). Transformations are executed inside the target warehouse using SQL via dbt (data build tool). ELT leverages infinite cloud MPP (Massively Parallel Processing) compute, preserves historical raw data, and accelerates analytics velocity.
3. Decision Matrix¶
| Option | Best For | Avoid When | Data Loss Risk | Transformation Speed | Flexibility | Operational Complexity |
|---|---|---|---|---|---|---|
| ELT (Extract, Load, Transform) | Cloud data warehouses (Snowflake, BigQuery, Databricks), modern analytics engineering (dbt), high-velocity raw data loading, preserving raw history | Strict compliance environments requiring PII masking before data crosses network boundaries | Zero (Raw data is preserved permanently in warehouse staging layers) | Ultra-Fast (Leverages cloud MPP data warehouse compute engines) | High (Data analysts write/modify transformation SQL dynamically in dbt) | Low to Medium |
| ETL (Extract, Transform, Load) | Legacy on-premise data warehouses, strict PII scrubbing before storage, complex stream transformations, resource-constrained target DBs | Modern cloud analytics platforms (Creates middle-tier processing bottlenecks and loss of raw historical data) | High (Transformed data overwrites raw source representation) | Slow (Bounded by mid-tier ETL server CPU/RAM memory limits) | Low (Modifying transformations requires altering ETL pipeline code) | High |
4. Selection Rules¶
| Requirement | Best Choice | Rationale / Example |
|---|---|---|
| Modern Cloud Data Platform (Snowflake + dbt) | ELT | Load raw JSON/Postgres data directly to Snowflake staging; transform via dbt SQL models |
| Strict PII Masking Before Cloud Storage (HIPAA / GDPR) | ETL | Scrub medical patient SSNs and credit card numbers on mid-tier server before loading to cloud |
| Preserve Historical Raw Data for Future Analytics | ELT | Raw data loaded in S3/Snowflake raw schema can be re-transformed 3 years later for new metrics |
| Real-Time Stream Pre-Processing (Kafka Streams) | ETL (Streaming ETL) | Filter, enrich, and format real-time Kafka event streams before writing to S3 |
5. Tradeoffs¶
- Analytical Flexibility vs Upfront Compliance Scrubbing
- Gain (ELT): Analysts can write new transformations on historical raw data at any time.
- Lose (ELT): Raw un-scrubbed data resides in staging schemas (requires RBAC column masking).
- Massive Cloud MPP Scalability vs Dedicated ETL Infrastructure
- Gain (ELT): Leverages Snowflake/BigQuery auto-scaling compute engines for multi-terabyte transforms.
- Lose (ELT): High transformation queries can incur cloud warehouse credit billing costs.
- Raw Data Auditability vs Storage Footprint
- Gain (ELT): 100% full raw audit history preserved in staging tables (
raw_users\(\rightarrow\)stg_users\(\rightarrow\)fct_orders). - Lose (ELT): Requires additional storage capacity to hold raw, staging, and final transformed tables.
- Developer Velocity (SQL/dbt) vs Complex Pipeline Code
- Gain (ELT): SQL-native transformations using dbt enable data analysts to build data models independently.
- Lose (ETL): Requires specialized Data Engineers to maintain Java/Python/Spark ETL code bases.
- Ingestion Latency
- Gain (ELT): Raw data is loaded into the target storage immediately without waiting for heavy transformations.
- Lose (ETL): Data becomes available for analytics only after full transformation pipeline completes.
6. Interview Counter Questions¶
- Why has ELT largely replaced ETL in modern cloud data architectures?
- What role does dbt (data build tool) play in the ELT paradigm?
- How do you handle PII masking and security in ELT when raw data is loaded into the warehouse first?
- What is the Medallion Architecture (Bronze, Silver, Gold layers) in Databricks/ELT?
- When is traditional ETL still mandatory over ELT?
- How does cloud MPP (Massively Parallel Processing) enable ELT execution?
- What is Streaming ETL and how does it differ from Batch ELT?
- How does ELT handle Schema Drift in source operational databases?
- What is the cost impact of running heavy transformations in ELT (Snowflake Credits) vs ETL (Dedicated EMR)?
- How do Data Quality checks (Great Expectations / dbt tests) differ between ETL and ELT?
7. Gold Standard Answers¶
- Decoupled cloud compute/storage (Snowflake/BigQuery) made cloud MPP storage dirt cheap and compute infinitely scalable. Loading raw data first (ELT) is faster, cheaper, and preserves raw history.
- dbt is the "T" in ELT. It manages SQL transformation models, dependency DAGs, testing, and documentation inside the data warehouse, compiling Modular SQL into target warehouse DDL/DML.
- Use Dynamic Data Masking and Role-Based Access Control (RBAC) in Snowflake/BigQuery. Raw PII columns are stored encrypted; unauthorized analyst roles see
XXXX-XXXXwhile authorized roles view plaintext. - Bronze (Raw data loaded as-is), Silver (Cleaned, filtered, joined data), Gold (Aggregated, business-level feature tables optimized for BI dashboards).
- Mandatory when: strict regulatory compliance forbids un-encrypted PII from landing on cloud storage, or when target storage cannot handle non-relational format parsing.
- Cloud MPP engines distribute SQL queries across hundreds of parallel compute nodes (Snowflake virtual warehouses), executing multi-terabyte joins in seconds using internal columnar processing.
- Streaming ETL transforms individual records in-flight (sub-second) before writing to storage. Batch ELT dumps raw data files to storage first, executing periodic SQL batch transformations later.
- ELT ingests raw source tables into variant/semi-structured JSON columns (
raw_json). New source fields land safely without breaking downstream dbt models until explicitly added to staging SQL queries. - ELT uses warehouse compute credits (can be expensive if SQL is un-optimized). Dedicated ETL (EMR/Spark) uses spot instance compute, which can be cheaper for massive heavy non-SQL algorithmic transformations.
- ETL tests data before loading (aborts load on error). ELT loads raw data first, then runs automated test assertions (
dbt test/ Great Expectations) on staging tables, alerting on data quality breaches.
8. Common Mistakes¶
- Writing custom Python/Spark ETL scripts to transform data before loading it into Snowflake (defeats the purpose of ELT).
- Deleting raw historical staging tables in ELT, losing the ability to re-transform historical data when metrics logic changes.
- Loading un-masked PII into ELT staging tables without configuring Column-Level Security / Dynamic Data Masking policies.
- Running un-optimized dbt SQL models that execute full table scans hourly, blowing out Snowflake credit budgets.
- Expecting ELT to handle streaming sub-second transformations before landing on S3 (Streaming ETL is required).
9. Keywords¶
ETL, ELT, Data Build Tool (dbt), Snowflake, BigQuery, Databricks, Medallion Architecture, Bronze Silver Gold, Dynamic Data Masking, Column-Level Security, MPP, Schema Drift, Great Expectations, Streaming ETL.
10. Cheat Sheet¶
- Core Difference: ETL = Transform before loading (Legacy, slow, loses raw history); ELT = Load raw data first, transform inside warehouse using SQL (Modern standard).
- The "T" in ELT: Managed by dbt (data build tool) using modular SQL models and DAG dependencies.
- Medallion Pipeline: Bronze (Raw land) \(\rightarrow\) Silver (Cleaned/Joined) \(\rightarrow\) Gold (Aggregated BI data).
- PII Security: Store raw PII in Bronze/Staging tables, protected by Dynamic Data Masking and RBAC.
- Raw History Advantage: ELT preserves 100% of raw historical source data, allowing re-transformation anytime business metrics change.
- Cost Control: Optimize dbt SQL models (use
incrementalmaterializations) to prevent runaway cloud warehouse credit costs.