ETL vs ELT: which data integration pattern fits your stack
7 min read Data engineering The Adapters team
ETL transforms data before it lands in the destination; ELT loads raw data first and transforms it inside the destination. Pick ETL when the target is an operational app that needs finished records. Pick ELT when the target is a warehouse and analysts own the transforms.
Key takeaways
- ETL: transform in flight, the destination only ever sees clean records. Standard for app-to-app sync.
- ELT: load raw, transform with SQL or dbt inside the warehouse. Standard for analytics.
- The decision hinges on three things: where queries run, who owns the transforms, and whether the destination validates input.
- Most teams above 5 connected systems end up running both. That is normal, not a design failure.
How ETL works
ETL stands for extract, transform, load. The pipeline pulls records from the source, reshapes them in transit, and writes only the finished result to the destination. The transform layer lives in the pipeline itself, not in the target system.
A concrete run: a Stripe charge arrives with amount: 12900
(integer minor units) and created: 1767225600 (a Unix timestamp). Before
it touches QuickBooks, the pipeline converts the amount to "129.00",
renders the timestamp as an invoice date in the books timezone, and resolves
customer: "cus_9x2" to an existing QuickBooks customer ref. If any step
fails, the record never lands. That is the defining property of ETL: the destination
stays clean because malformed data is stopped at the boundary.
This is why ETL is the default for operational sync. QuickBooks will reject an integer-cents amount, Salesforce will reject a picklist value it has never seen, and NetSuite will silently coerce a string date into something you did not intend. Operational apps validate on write, so the write has to be right.
How ELT works
ELT flips the last two steps: extract, load, then transform. The pipeline copies raw source data into the destination, almost always a warehouse such as Snowflake, BigQuery, or Redshift, and transformation happens afterward in SQL, typically managed with dbt.
The same Stripe charge lands in a raw.stripe_charges table with every
field intact, ugly timestamps and all. A staging model casts types and renames
columns, and a marts model joins charges to customers for the revenue dashboard.
Storage is cheap, so keeping the raw layer costs little, and it buys you something
ETL cannot: when the business changes its definition of MRR next quarter, you edit
one SQL model and rebuild the entire history. No backfill from the source API, no
re-extraction.
ETL vs ELT: the comparison
| Dimension | ETL | ELT |
|---|---|---|
| Where transforms run | In the pipeline, before load | In the destination, after load |
| Typical destination | Operational apps: CRM, books, ERP | Warehouses: Snowflake, BigQuery |
| Raw history kept | No, only finished records land | Yes, the raw layer is the point |
| Redefining a metric | Re-extract and re-run the pipeline | Edit SQL, rebuild from raw |
| Bad data blast radius | Stopped at the boundary | Lands raw, caught in staging tests |
| Who owns it | Ops or platform engineers | Analytics engineers |
| PII handling | Mask or hash before landing | PII lands raw; needs column policies |
| Direction | Any-to-any, including two-way | One-way, into the warehouse |
When ETL wins
- The destination is an app, not a warehouse. Two-way sync between Salesforce and HubSpot, or Stripe into QuickBooks, is ETL by definition: both ends validate, and neither gives you a raw layer to transform in.
- PII must not land raw. If policy says the destination only receives hashed emails, the hashing has to happen in flight. ELT would put plaintext in the raw layer first.
- The destination bills by volume. Filtering test-mode charges and refund reversals before load can cut landed rows 20 to 30% on a typical payments feed.
- Consumers need finished records now. When a rep opens the CRM, the deal amount has to already be in dollars, in the right currency, in the right stage.
When ELT wins
- The questions are not known yet. Raw history means the field nobody cared about last year is queryable the day someone cares.
- Definitions change often. Rebuilding a metric from raw is a one-line dbt change; rebuilding it in an ETL pipeline is a backfill project.
- Your team lives in SQL. Analytics engineers ship faster in the warehouse than in pipeline code, and dbt tests give staging models real guardrails.
The hybrid reality
In practice, teams past a handful of systems run both patterns side by side: ETL keeps the operational apps in sync with each other, and an ELT feed copies the same sources into the warehouse for analytics. The failure mode to avoid is doing analytics over an operational copy, or driving an app from warehouse tables that update nightly.
Two newer labels fit the same map. Reverse ETL is ETL where the
warehouse is the source: pushing a computed segment like
churn_risk_score back into the CRM so reps can act on it. It inherits
every ETL constraint, because the destination is an app that validates on write.
Streaming changes the trigger, not the pattern: a change-data-capture
feed can drive either an in-flight transform or a raw load. If someone proposes
"streaming ELT", ask the same three questions: where do transforms run, who owns
them, and does the destination validate.
Whichever pattern you pick, the mapping layer decides whether records land correctly. The nine rules in our guide to data mapping best practices apply equally to a transform step and a staging model. And if your sources push events, the tradeoffs in webhooks vs polling determine how fresh either pipeline can be.
If you are comparing etl tools for the app-to-warehouse side, look hard at what happens on failure: retries, alerting, and per-record logs are where lightweight pipelines usually fall down. A data integration platform that handles both app-to-app ETL and app-to-warehouse loads from one editor saves you running two systems with two mapping vocabularies.
Run ETL and warehouse loads from one editor
Map Stripe to QuickBooks and Postgres to Snowflake with the same adapters. Flat price from $49 a month, first sync in minutes.