The three-letter problem
Data integration acronyms have multiplied faster than most teams can keep up with. ETL, ELT, reverse ETL all describe ways of moving data between systems. They are not interchangeable.
Knowing which pattern fits which problem matters because the tooling landscape has split into categories that look similar at first glance. A team that picks an ELT tool for an ETL-shaped problem will spend months working around the wrong architecture. A team that reaches for reverse ETL when the real need is iPaaS will build a pipeline that goes through a warehouse that never needed to be in the loop.
This guide walks through the three patterns, how they relate, and the decision framework for picking one.
ETL: Extract, Transform, Load
ETL is the oldest of the three. It emerged in the 1990s as a way to populate data warehouses from operational databases for analytical reporting.
The core idea: pull data from the source, transform it into the destination’s schema, then load it into the destination. Transformation happens on a dedicated server between the source and the warehouse. Only the transformed output lands in the destination.
When ETL fits
- Moving structured data from operational databases into analytical warehouses
- Scheduled batch jobs where latency is measured in hours
- Regulated environments that require transformation before data touches the destination (PII masking, compliance transforms)
- On-premises or hybrid-cloud deployments that mandate transformation infrastructure outside the warehouse
When ETL does not fit
- Streaming or real-time requirements
- Sources with undocumented or unstable schemas
- High-cardinality transformations that run more cheaply inside a cloud warehouse
ELT: Extract, Load, Transform
ELT reorders the middle letter. Data is loaded into the destination warehouse before it is transformed. Transformations happen inside the warehouse using SQL, often orchestrated by dbt.
Why ELT emerged
Cloud warehouses (Snowflake, BigQuery, Redshift) changed the economics of data transformation in the 2010s. Warehouse compute became cheap and elastic. Separate transformation servers became unnecessary overhead. SQL was the language every analyst already knew, unlike the proprietary scripting languages traditional ETL tools used.
ELT displaced ETL for most new analytical use cases. Raw source data lands untransformed. Transformation runs in the warehouse on demand or on a schedule.
When ELT fits
- Cloud-native analytics at any scale
- Situations where preserving raw source data in the destination has value
- Teams that want analysts and engineers working in SQL rather than proprietary ETL tools
- Any analytics use case starting fresh in 2020 or later
When ELT does not fit
- Regulated workloads that require transformation before data lands
- Situations where the destination is not a warehouse
- Environments without reliable warehouse compute
Reverse ETL: Warehouse to SaaS
Reverse ETL emerged around 2020 to solve a problem ETL and ELT created. Both patterns moved data into the warehouse. Neither moved it back out to the operational tools where teams worked.
Reverse ETL moves data from the warehouse into SaaS apps. The source is a warehouse. The destination is an operational tool. The transformation logic maps warehouse columns to SaaS object fields.
When reverse ETL fits
- Enriched warehouse data needs to be visible in SaaS apps (lifetime value scores in Salesforce, segments in HubSpot)
- Analytical teams want operational distribution of their models
- Sync frequency of minutes is acceptable
When reverse ETL does not fit
- No warehouse exists or the warehouse is not the authoritative source
- The data path goes SaaS-to-SaaS without a warehouse in between
- Sub-second propagation is required
Head-to-head comparison
| Dimension | ETL | ELT | Reverse ETL |
|---|---|---|---|
| Primary source | Operational DBs | SaaS apps and DBs | Warehouse |
| Primary destination | Warehouse | Warehouse | SaaS apps |
| Transform location | Separate server | Inside warehouse | Before sync to SaaS |
| Transform language | Proprietary or Python | SQL (often dbt) | SQL and mapping config |
| Typical latency | Hours (batch) | Minutes | Minutes |
| Compute economics | Fixed infrastructure | Pay-per-query warehouse | Pay-per-record sync |
| Raw data preservation | No | Yes | Not applicable |
| Typical user | Data engineer | Analytics engineer | Analyst or ops |
| Emerged | 1990s | 2010s | 2020s |
Decision framework
| Need | Pattern |
|---|---|
| Move operational DB data to a warehouse, regulated or on-prem | ETL |
| Move SaaS or DB data to a cloud warehouse for analytics | ELT |
| Move warehouse-computed data back into SaaS apps | Reverse ETL |
| Move data between SaaS apps without a warehouse in the middle | iPaaS (none of the three above) |
| Ingest partner data from files and unknown schemas | Intelligent data mapping (separate category) |
How the patterns coexist
Large organizations typically run all three. ELT pulls operational data into the warehouse. SQL transforms model that data. Reverse ETL pushes the modeled output to SaaS tools. For regulated workloads that cannot land raw data in the warehouse, ETL fills the gap.
The patterns are complementary rather than competitive. The confusion comes from vendors positioning products as “the platform” for all three when the architectures underneath are different. Picking the right tool for each pattern is easier than picking one tool that claims to do them all.
Where datathere fits
datathere is not in the ETL, ELT, or reverse ETL category. It sits in a separate one: intelligent data mapping for unknown-schema integration. Partner files, PDFs, supplier catalogs, and undocumented APIs fall outside what ETL, ELT, and reverse ETL assume (known schemas on both sides). That problem requires AI-driven mapping, not a new direction for warehouse data movement.
For teams that need both warehouse-oriented data movement (ETL/ELT/reverse ETL) and partner data handling, the two tools coexist. They solve different problems.
FAQ
Is ETL obsolete now that ELT exists?
For cloud-native analytics, ELT has largely replaced ETL. For regulated workloads that require transformation before data lands in the destination, or for on-prem-only environments, ETL still fits. “Obsolete” is too strong; “niche” is accurate.
Can one tool do ETL, ELT, and reverse ETL?
Several vendors claim to. In practice the underlying architectures differ, and a single tool usually specializes in one pattern while bolting others on as features. Evaluation matters more than category branding.
Is reverse ETL the same as data activation?
Data activation is a broader term that includes reverse ETL along with related patterns like customer data platforms and event streaming. Reverse ETL is the most common activation pattern but not the only one.
What about streaming?
Streaming (Kafka, Flink, and related) is a separate category focused on event-driven data movement rather than batch or micro-batch patterns. Some streaming platforms can be used for ETL-like workloads, but the programming model and typical use cases differ enough that treating streaming as a fourth pattern is more accurate than fitting it into ETL, ELT, or reverse ETL.