What Is ELT? Extract, Load, Transform Explained

What is ELT? It was supposed to be the fix for traditional ETL, which was slow, rigid, and expensive to maintain. So the industry flipped the order: load raw data into a cloud warehouse first, transform it there, skip the staging environment entirely. Faster setup, cheaper infrastructure, more flexibility. Fivetran built a billion-dollar business on this premise, and for data teams loading Snowflake, it works.

But ELT inherited the one assumption nobody questioned: everything still goes through a warehouse. For a 20-person team syncing Stripe to HubSpot, ELT means provisioning a warehouse you do not need, writing SQL models you do not want to maintain, and waiting for transformations to finish before data reaches the tools your team actually uses.

This guide covers what ELT is, how it differs from ETL, what it actually costs to run, and where the line falls between "ELT is the right tool" and "you are overengineering a simple data flow."

What ELT is and how the extract-load-transform process works

ELT stands for extract, load, transform. It reverses the last two steps of the traditional ETL process, and that reversal changes the architecture significantly.

The three stages:

1. Extract. Pull raw data from sources: SaaS APIs, databases, event streams, flat files. This step is identical to ETL. Connectors handle authentication, pagination, rate limiting, and incremental extraction.

2. Load. Write the raw, untransformed data directly into a cloud data warehouse (Snowflake, BigQuery, Redshift, Databricks). No staging area, no intermediate processing. The data lands in the warehouse exactly as it left the source, preserving the original schema and field types.

3. Transform. Once data is in the warehouse, use SQL-based tools (dbt is the standard) to clean, restructure, join, and enrich it. Transformations run on the warehouse's compute engine, which scales elastically. You write SQL models that define the output tables your analysts and dashboards consume.

The key difference from ETL: transformation happens inside the warehouse, not before it. This means you load data once in its raw form and can run multiple transformations against it for different use cases without re-extracting from the source.

ETL vs ELT: why ELT won the cloud migration but kept the warehouse dependency

ETL dominated data integration from the 1970s through the 2010s. Transformation had to happen before loading because on-premise warehouses were expensive, storage was limited, and you needed to clean data before committing it to disk.

Cloud warehouses broke that constraint. Storage became cheap. Compute became elastic. Suddenly it was faster and cheaper to load raw data first and transform it on-demand using the warehouse's own processing power.

ELT won on three fronts:

ELT is genuinely better than ETL for modern data teams. Fivetran's guide is right about that: loading raw data first gives you more flexibility, faster time-to-insight, and lower infrastructure costs than pre-load transformation.

But both ETL and ELT answer the same question: how do I get data into a warehouse? The warehouse is the end state. Every connector, every dbt model, every transformation schedule exists to make data queryable by analysts. That is the right architecture for analytical workloads. It is the wrong architecture when the consumer is not an analyst with a SQL editor but a sales rep opening a CRM contact.

The hidden cost of ELT: warehouse compute, dbt models, and transformation sprawl

ELT marketing emphasizes what you skip (staging environments, pre-load schemas), not what you still pay for.

Warehouse compute. Snowflake charges per second of compute. BigQuery charges per byte scanned. Running dbt models across 10 source tables twice daily costs $500-1,500/month for a small team. Costs scale with data volume and transformation complexity, not with the value you extract.

dbt model maintenance. dbt models are SQL files that define how raw data becomes queryable tables. A typical ELT setup has 20-50 models. Each one needs to be updated when a source API adds or removes fields, when business logic changes, or when a new downstream consumer needs a different data shape. This is data engineering work, and it compounds over time.

Transformation sprawl. Teams start with five clean models. Six months later, they have 47 models, 12 of which are undocumented, 3 of which reference deprecated source tables, and 1 that takes 22 minutes to run because it joins six tables without a filter. Nobody wants to delete any of them because "someone might be using it."

Connector costs. Fivetran charges by monthly active rows. Airbyte requires self-hosted infrastructure. Both scale with data volume. A team loading 500,000 rows/month across 5 connectors pays $300-800/month for the extraction layer alone.

The latency tax. ELT runs on schedules. Extract runs hourly. dbt models run after extraction completes. By the time transformed data is queryable, it can be 2-4 hours behind the source. For dashboards, that is fine. For operational tools where your support team needs current billing data, it is not.

A realistic ELT stack for a 20-person team: Fivetran ($500/month) + Snowflake ($800/month) + dbt Cloud ($100/month) = $1,400/month. Add Hightouch or Census ($500/month) if you need warehouse data back in your operational tools. Total: $1,900/month plus 15+ hours of engineering time per month to maintain models, debug schema drift, and investigate failed syncs.

When ELT is the right choice and when direct sync replaces it entirely

ELT earns its complexity when three conditions are true:

1. The consumer is an analyst. Data warehouse tables, SQL queries, Looker dashboards, dbt-powered reports. If the end consumer writes SQL, ELT is the right delivery mechanism.

2. You need cross-system joins. Combining Stripe revenue data with HubSpot deal data with product usage events requires a central store where you can join across sources. That is what warehouses do.

3. You need historical analysis. Warehouses retain every version of every record. ELT preserves raw data, letting analysts query historical states that source systems no longer expose.

ELT does not earn its complexity when the goal is keeping operational tools in sync. If the data flow is "Stripe subscription status needs to appear in HubSpot," the ELT path looks like this:

1. Fivetran extracts Stripe data into Snowflake.

2. dbt transforms it into a clean customers model.

3. Hightouch reads the model and pushes subscription_status to HubSpot.

Three tools, three billing relationships, 2-4 hours of latency, and a warehouse running compute for data that no analyst will ever query. The direct sync path: connect Stripe to HubSpot, map subscription.status to subscription_status, sync every 15 minutes. One tool, one step, minutes of latency.

This is not a theoretical distinction. For every operational data flow you route through a warehouse, you pay warehouse compute on data that exists only to pass through on its way to another tool.

How to move data between tools without an ELT pipeline or a warehouse

If your data flows are operational, skip the warehouse layer:

Start with the destination, not the source. Ask: where does this data need to end up? If the answer is "a dashboard" or "a SQL query," use ELT. If the answer is "HubSpot," "Intercom," or "Mailchimp," use direct sync.

Connect sources to destinations directly. Your Postgres database stores the customer data your app writes. Stripe stores billing events. These are already your sources of truth. They do not need to be extracted into a warehouse before reaching your CRM.

Map fields instead of writing SQL. ELT requires dbt models to define the shape of output data. Direct sync requires a field mapping: plan_name in Stripe maps to plan_name in HubSpot. That is configuration, not code.

Sync on a schedule that matches the use case. Every 15 minutes keeps operational tools current. Your CRM is never more than 15 minutes behind the source system. For a support rep checking billing status, that is functionally real-time.

Oneprofile handles this entire flow. Connect your database or any SaaS tool, map fields to any destination, and data syncs on a schedule you control. Property-level change tracking means only changed fields are written, reducing API calls by 95%+ compared to full-snapshot approaches. No warehouse prerequisite. No dbt models. No reverse ETL to push data back out.

For teams that also need analytics, both approaches coexist. Run ELT into Snowflake for your data team. Run direct sync for your operational tools. Each destination gets the architecture it needs, and you stop paying warehouse compute for data that is just passing through.