ETL vs ELT: Why ELT Won and When ETL Still Makes Sense

ETL transforms data before loading it into the warehouse. ELT loads raw data first and transforms it inside the warehouse. ELT is dominant in modern stacks because cloud warehouses are fast enough to transform at query time. ETL survives in low-latency or compliance-bound scenarios.

The flip from ETL to ELT is the biggest architectural shift in data engineering of the last decade. This guide explains when each pattern wins, how tools like dbt accelerated the shift, and where ETL still makes sense today.

ETL vs ELT: The Core Difference

ETL runs transforms on a dedicated middle tier — Informatica, Talend, custom Spark jobs — before writing to the warehouse. ELT writes raw data straight to the warehouse and then runs SQL transforms using warehouse compute. The shift moves the compute from a bespoke tier to the warehouse itself.

Why ELT Won

Cloud warehouses changed the economics. Snowflake, BigQuery, and Redshift scale compute independently of storage, so running a transform inside the warehouse costs roughly the same as running it in Spark — but with zero orchestration overhead and SQL as the language. dbt then turned SQL transforms into version-controlled, tested, documented projects.

ELT also preserves raw data. If a transform has a bug, you rerun it against the raw tier without re-extracting from source systems. That reproducibility is impossible with traditional ETL, where the raw data is often discarded after the transform completes.

The organizational shift matters as much as the technical shift. ELT democratizes transforms because SQL is a much larger skill pool than Spark or Scala. An analyst who can write a CTE can contribute to a dbt project on day one, whereas contributing to an Informatica job or Spark pipeline used to require specialist skills. That accessibility alone explains why ELT adoption has been so fast.

Where ETL Still Wins

ETL survives in three scenarios: hard latency requirements (streaming), hard compliance (you cannot land PII in the warehouse at all), and pre-cloud legacy. If you need sub-second transforms or you must mask data before it enters the warehouse boundary, ETL still makes sense.

• •Streaming ETL — Flink or Spark Structured Streaming
• •PII masking — mask before load to reduce regulated surface area
• •Legacy warehouses — on-prem systems without cheap compute
• •Tight egress budgets — transform reduces data volume before load
• •Regulated industries — auditors require transform-then-load

Modern Stack: ELT with Guardrails

The modern pattern is ELT for analytics, ETL for streaming, and contract enforcement at both edges. Fivetran or Airbyte does the E+L, dbt or SQLMesh does the T, and data contracts + PII detection prevent sensitive data from landing in the wrong tier. Data Workers automates the contract enforcement.

For related architecture decisions see what is etl, what is elt, and how to build a data pipeline.

PII handling sits at the boundary. Teams that must keep raw PII out of the warehouse altogether use ETL-style masking in an intermediate tier — Airbyte with transformations, a dedicated redaction microservice, or Kafka with a stream processor that strips sensitive fields before the sink. Teams that can land raw PII but restrict access via column-level masking get the ELT benefits without a custom redaction pipeline.

The compliance side of this decision is often dictated by legal and security teams rather than data engineering. Map your regulatory exposure first (GDPR, HIPAA, SOC 2, PCI) and let those requirements drive the pattern. No amount of ELT elegance will pass an audit if auditors demand that raw PII never crosses the warehouse boundary.

Hybrid ETLT Patterns

A third pattern has emerged that blends both: ETLT. Light transforms happen in flight (field renaming, PII masking, timezone normalization), then raw-ish data lands in the warehouse for heavy transforms in dbt. This gives you ETL's compliance benefits without losing ELT's reproducibility. Tools like Airbyte, Fivetran HVR, and Estuary Flow all support in-flight transforms of this kind.

ETLT is especially useful when source APIs emit massive JSON payloads and you only need a handful of fields. Projecting in flight cuts warehouse storage and compute significantly. Just make sure your transforms are reversible or well-documented, because debugging a bug in an in-flight transform is harder than debugging a dbt model.

The modern ETLT stack typically has three layers of transforms: light in-flight cleaning (ETL tier), staging models that standardize raw data (ELT tier), and business logic in marts (ELT tier). Each layer has a clear owner and a clear purpose, which makes debugging much easier than the old monolithic ETL approach where everything happened in one giant Informatica job.

Cost Implications

ELT cost is dominated by warehouse compute for transforms — typically the single largest line item in a modern data platform budget. ETL cost is dominated by the transform tier (Spark clusters, Informatica licenses, or Flink infrastructure) plus the engineering time to maintain it. ELT tends to win on total cost for small-to-medium teams because you are not paying for a dedicated transform tier; ETL can win at massive scale where dedicated compute is cheaper than warehouse credits for heavy batch jobs.

Watch out for the common ELT cost trap: running dbt run with full_refresh on huge incremental models, which can burn warehouse credits faster than anyone notices. Incremental materializations and warehouse auto-suspend are essential for keeping ELT costs sane.

Common Mistakes

The biggest ELT mistake is dumping raw data and never cleaning it — the lake becomes a swamp. The biggest ETL mistake is over-engineering: forcing every source through a complex transform pipeline when a simple dbt model would do. Match the tool to the actual latency and compliance requirements.

Data Workers pipeline agents own both ETL and ELT flows, apply PII masking automatically, and enforce contracts at load time. Book a demo to see it run.

ETL and ELT are not a religion. ELT wins for cloud warehouse analytics, ETL wins for streaming and compliance, and the modern stack uses both. Pick the pattern that matches the workload and let the warehouse handle the heavy lifting when it can.