What Is ELT? ELT vs ETL, and Which One Modern Data Pipelines Use

ELT stands for extract, load, transform: copy raw data from its sources into the warehouse first, exactly as it arrived, then transform it there with SQL into the tables people query. ETL, the older pattern, transforms the data on a separate server before loading only the finished result. The two differ in one word's position and in almost every practical consequence: where the compute runs, whether raw data is kept, who can read the transformation logic, and how much a change costs. Bruin is built around ELT, with ingestr for the load step and SQL and Python assets for the transform step in the same project; dbt covers the transform step alone; Fivetran and Airbyte cover the load step alone.

The two patterns

Why ELT became the default

ETL made sense when the warehouse was the expensive, slow part of the stack and a transformation server was cheap by comparison. Cloud warehouses inverted that around 2016: Snowflake and BigQuery could scan terabytes in seconds and charged per second of compute, so the cheapest place to transform became the destination itself. Three benefits followed.

Raw data is kept. When a metric definition changes, or a bug is found in a model, the raw tables are still there and the fix is a re-run of SQL, not a re-extract from a source that may no longer have the history.

The logic is readable. A transformation in SQL sits in a repository, is reviewed in a pull request, and can be read by an analyst, an engineer, or an AI agent. ETL logic in a visual tool or a Java job is readable by whoever owns the tool.

One system to operate. No transformation cluster to size, patch, or pay for between the source and the warehouse.

What an ELT pipeline looks like

In Bruin, both halves live in one project. The load is an ingestr asset:

# assets/raw/orders.asset.yml
name: raw.orders
type: ingestr
parameters:
  source_connection: shop_postgres
  source_table: public.orders
  destination: snowflake
  incremental_strategy: merge
  incremental_key: updated_at

The transform is a SQL asset that declares what it depends on and what must be true of its output:

/* @bruin
name: mart.orders
type: sf.sql
depends:
  - raw.orders
columns:
  - name: order_id
    checks:
      - name: not_null
      - name: unique
  - name: order_total
    checks:
      - name: non_negative
@bruin */

select order_id, customer_id, status, order_total, ordered_at
from raw.orders
where status != 'test'

bruin run ./pipeline.yml loads, transforms, and checks in dependency order. The same shape with Fivetran and dbt is two products and two schedulers; the reason Bruin keeps both steps together is that the load and the transform are one pipeline and break as one.

When ETL still wins

ELT is not universal. Transform before loading when:

• Data must not land raw. Personal fields that have to be masked or dropped before they reach the warehouse for compliance reasons. Most ELT tools handle this as a small in-flight step during the load, which is ETL in miniature.
• The destination cannot transform. A message queue, a search index, or an operational database that is the target rather than a warehouse.
• Latency is the constraint. Streaming pipelines that enrich events in flight, where a batch transform in the warehouse is too slow.

In practice most pipelines are ELT with a thin ETL layer during the load, and the distinction that matters is whether the raw data is kept and whether the transformations are code. For the walk-through, see how to build your first ELT pipeline with SQL and Python; for the load-step tool choice, the best open-source ELT tools in 2026.