dbt vs Traditional ETL

Analogy categoryAnalogies

Traditional ETL tools such as Informatica PowerCenter, SSIS, or Talend extract data from sources, transform it in a dedicated processing engine outside the warehouse, and load the finished result into the warehouse. dbt inverts the last two steps: raw data is loaded into the warehouse first, untransformed, and dbt then runs SQL transformations directly inside the warehouse's own compute engine, an approach known as ELT rather than ETL. This single architectural inversion is responsible for most of the practical differences in cost, speed, tooling, and team ownership between the two approaches.

🏏

Cricket analogy: In T20 cricket, teams switched from the old Test-match mindset of grinding through overs to an aggressive powerplay-first approach, similarly to how ELT front-loads raw data extraction and pushes the heavy transformation work later, inside the warehouse.

Transformation Location and Compute Cost

In traditional ETL, transformation logic runs on a dedicated server or cluster that the ETL vendor licenses and that a data engineering team must size, patch, and scale independently of the warehouse. In dbt's ELT model, every transformation is a SQL SELECT statement executed by the warehouse's own elastic compute, whether that's Snowflake's virtual warehouses, BigQuery's slots, or Redshift's cluster, so there is no separate infrastructure to provision and cost scales with the same billing model as the rest of analytics workloads. The tradeoff is that a poorly written dbt model can spike warehouse compute costs in a way that's immediately visible on the cloud bill, whereas a poorly written ETL job just runs slowly on its own dedicated hardware without affecting anything else.

🏏

Cricket analogy: A stadium that owns its own floodlights versus one that rents them for each match has different cost and maintenance tradeoffs, the same way owning dedicated ETL infrastructure versus using the warehouse's elastic compute has different cost tradeoffs.

Version Control, Testing, and Team Ownership

Traditional ETL tools like Informatica typically store transformation logic as proprietary XML workflows edited in a GUI, which makes diffing changes in Git, code review, and automated testing awkward or impossible without vendor-specific plugins. dbt models are plain SQL and YAML files that live in a normal Git repository, so every transformation change goes through a pull request with a visible diff, and dbt's built-in test framework (not_null, unique, relationships, custom SQL tests) runs the same way a software test suite does. This also shifts ownership: traditional ETL is usually the exclusive domain of a centralized data engineering team, while dbt's SQL-based, Git-native workflow lets analysts and analytics engineers who know SQL but not Python or Java contribute transformations directly.

🏏

Cricket analogy: Modern cricket coaching uses video analysis software that every assistant coach can review and annotate, replacing the old model where only the head coach held tactical knowledge, mirroring how dbt's Git-based SQL opens transformation work to more than just a centralized engineering team.

When Traditional ETL Still Makes Sense

dbt does not replace every ETL need — it only handles the T in ELT, meaning extraction and loading from source systems into the warehouse are still handled by separate tools like Fivetran, Airbyte, or custom scripts. Traditional ETL platforms also retain an edge for complex, non-tabular workflows such as processing unstructured files, calling external APIs mid-pipeline, or orchestrating heavyweight machine learning feature pipelines, where dbt's SQL-only execution model and warehouse-native constraint become limiting rather than helpful. Organizations with strict on-premises data residency requirements or legacy mainframe sources may also find that a traditional ETL tool's mature source connector library outweighs dbt's transformation-layer benefits.

🏏

Cricket analogy: Even in the T20 era, Test cricket still exists because five-day matches test different skills that shorter formats can't replace, similarly to how dbt doesn't replace every ETL need — extraction and loading still require dedicated tools.

sql

-- Traditional ETL: transformation happens BEFORE load, outside the warehouse
-- (pseudocode representing an Informatica/SSIS mapping)
-- extract -> transform (dedicated ETL server) -> load (finished table)

-- dbt / ELT: raw data is loaded first, transformation happens AFTER, inside the warehouse
-- models/marts/finance/fct_orders.sql
select
    o.order_id,
    o.customer_id,
    o.order_date,
    sum(oi.quantity * oi.unit_price) as order_total
from {{ ref('stg_orders') }} o
join {{ ref('stg_order_items') }} oi on o.order_id = oi.order_id
group by 1, 2, 3

A useful mental shortcut: in ETL, the 'T' happens in a black box before data lands in the warehouse. In dbt's ELT, the 'T' happens in the warehouse, in version-controlled SQL you can read, test, and diff.

dbt implements ELT, not ETL — raw data loads into the warehouse first, then dbt transforms it there.
Transformation compute in dbt is the warehouse's own elastic compute, not a separate dedicated ETL server.
dbt models are plain SQL/YAML in Git, enabling pull requests, diffs, and code review that GUI-based ETL tools struggle with.
dbt's built-in testing framework brings software-engineering-style test suites to data transformations.
dbt only covers the T — extraction and loading still need tools like Fivetran or Airbyte.
Traditional ETL retains an edge for unstructured data, mid-pipeline API calls, and legacy/mainframe source connectivity.
Cost models differ: ETL has dedicated infrastructure cost, dbt's cost scales with warehouse compute usage.