Quick answer:
ELT stands for Extract, Load, Transform: copy raw data out of your source systems, land it in the data warehouse untouched, and do all the cleaning and modeling afterwards, inside the warehouse itself. It’s the pattern the modern data stack is built on, and the reason tools like Fivetran, Airbyte, and dbt exist as separate products.
The one-line version: get the data in first, make it pretty later.
What is ELT?
In the older ETL pattern, data got cleaned on a middleware server before it was allowed into the warehouse. ELT flips that. The extract-and-load half becomes dumb and reliable: a connector reads the source API or database and writes faithful raw copies into warehouse tables, on a schedule, with no opinions.
The transform half then runs as SQL inside the warehouse. Raw tables in, clean modeled tables out, all powered by the warehouse’s own engine. In most stacks that layer is dbt, which turned “a folder of SQL files” into a discipline with testing, version control, and lineage.
Why did ELT take over?
Two prices collapsed. Cloud storage got so cheap that keeping raw copies of everything stopped being a decision anyone agonized over. And cloud warehouses like Snowflake and BigQuery made compute elastic, so transformation could run on the warehouse without crowding out the analysts.
Once those constraints fell, the old architecture’s costs stood out. Every ETL pipeline coupled extraction logic to transformation logic, so a changed business rule meant re-extracting from source. With ELT, the raw data is already sitting there; changing logic means re-running SQL. That single property (replayability) is worth more than any benchmark.
There’s also a people angle. ETL middleware belonged to specialist engineers. SQL in the warehouse belongs to anyone who can write SQL, which pulled analysts into the pipeline-building business (the “analytics engineer” title comes from exactly this shift).
What does an ELT stack look like in practice?
- Extract + Load: Fivetran (managed, priced per active row) or Airbyte (open source with a cloud option), pulling from SaaS APIs and databases into the warehouse.
- Warehouse: Snowflake, BigQuery, or Databricks holding raw and modeled layers side by side.
- Transform: dbt compiling SQL models, running tests, documenting what feeds what.
- Orchestration: Airflow or Dagster making sure loads finish before transforms start.
Raw tables typically land in a schema nobody queries directly, and modeled tables live in a clean schema that BI tools read. The raw layer is your insurance policy.
What are the downsides?
The bill moves into the warehouse, where it’s easy to ignore until it isn’t. Every dbt run is warehouse compute, and untuned models re-building giant tables hourly are the most common source of surprise Snowflake invoices we see.
Compliance is the other one. Loading raw data means loading everything, including personal data you might not want in the warehouse at all. Teams in regulated industries either mask in transit (which quietly reinvents ETL for those columns) or lean on warehouse-side policies to control access.
What are the benefits and drawbacks of ELT?
Benefits of ELT
Replayability pays for the whole pattern
The raw data sits in the warehouse forever, so a changed business rule is a re-run of SQL, never a re-extraction from sources. Teams that have lived through both describe this as the difference between editing and re-shooting.
Extraction becomes a commodity you buy
Because the load step carries no logic, tools like Fivetran and Airbyte can sell the same connectors to everyone. Nobody hand-codes a Salesforce extractor in 2026 unless they enjoy it.
Analysts join the pipeline team
Transformation in SQL means the people who understand the business logic can implement it, test it, and version it in git. The whole analytics engineering discipline grew out of this one shift.
One engine to tune instead of two
All heavy compute happens in the warehouse, where the scaling, monitoring, and access control already live. No middleware fleet to patch on weekends.
Drawbacks of ELT
The meter runs inside the warehouse
Every transformation is billed warehouse compute, and an untuned model rebuilding a giant table hourly is the classic surprise-invoice generator. Cost discipline has to be designed in, then policed.
Raw means everything, including what you’d rather not hold
Loading first means personal data lands before any masking. Compliant setups need in-flight redaction for the sensitive columns (hello again, ETL) or strict warehouse-side policies, and auditors will ask which.
The raw layer is a maze with no map
Hundreds of vendor-shaped raw schemas accumulate fast. Without naming conventions and a clean modeled layer on top, newcomers query the wrong table and nobody notices for a quarter.
Freshness is chained to batch schedules
Load-then-transform is inherently staged, so “how fresh is this dashboard?” is the sum of 2 schedules. Real-time needs live somewhere else.
Does the ETL vs ELT debate still matter?
Less than the blog wars suggest. ELT won the analytics default so thoroughly that most “ETL tools” you’ll evaluate are ELT tools wearing the older name. The remaining real decisions are narrower: what must never enter the warehouse, what needs to be real-time, and how much transform compute you can afford where.
Treat the acronyms as a description of where work happens, price that honestly for your stack, and you’ll make the right call without the ideology.