Rethinking Data Transformation: How dbt Is Redefining the Modern Analytics Stack

By Tony Henein
Director of Analytics & Data Engineering

🚀 The Shift from ETL to ELT

For decades, organizations relied on ETL tools like Informatica, SSIS, and Talend to extract, transform, and load data. The process was simple, but the data was transformed before reaching the warehouse.

The new world of cloud computing flipped that logic. Today's data architecture follows an ELT pattern, Extract, Load, then Transform, where raw data first lands in a scalable warehouse such as Snowflake, BigQuery, Databricks, or Microsoft Fabric, and transformation happens within the warehouse.

This shift gave rise to one of the most influential tools in modern analytics: dbt (Data Build Tool) — and in 2025, dbt itself was reinvented with the launch of the dbt Fusion engine.

🧠 What Makes dbt Different

dbt doesn't extract or load data — it focuses entirely on the "T" (Transform) in ELT. It enables teams to transform raw data into trusted, analytics-ready tables using standard SQL while enforcing software engineering discipline.

Here's how dbt turns pipelines into software-grade systems.

1) SQL as Code

dbt models are written entirely in SQL, making transformation logic both accessible and scalable. Teams can clean, join, and aggregate datasets in simple, modular scripts:

-- models/stg_orders.sql
SELECT
    order_id,
    customer_id,
    CAST(total_amount AS DECIMAL(10,2)) AS total_amount
FROM {{ source('raw', 'orders') }}
WHERE order_status = 'completed';

Each file represents a logical step in your data flow, forming a directed acyclic graph (DAG) that dbt uses to manage dependencies.

2) Runs Inside Your Warehouse

dbt doesn't run on a separate compute engine. It executes directly inside your warehouse, leveraging the scalability, governance, and performance you already pay for. This keeps infrastructure simple and your data secure — no data leaves your warehouse.

3) Lineage, Testing, and Documentation Built In

With dbt, every model can include automated data tests and rich documentation:

version: 2
models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - not_null
          - unique

dbt automatically generates interactive documentation and lineage graphs, allowing anyone — from analysts to executives — to trace how every dataset or KPI is derived.

4) Version Control and CI/CD

dbt brings DevOps discipline into analytics. Every transformation script is versioned in Git, enabling teams to collaborate through pull requests, peer review, and automated testing before deployment. This means your analytics environment evolves predictably, with fewer errors and full auditability.

⚙️ The dbt Fusion Engine: A Ground-Up Rewrite (2025–2026)

In May 2025, dbt Labs unveiled the most significant change to dbt since its inception: the dbt Fusion engine, a complete rewrite of dbt Core in Rust. Fusion is engineered to address the scaling pains that mature analytics teams have hit with the original Python-based engine — slow parse times, weak SQL validation, and runaway warehouse spend.

What's actually new

• Native SQL comprehension: Fusion parses and validates SQL before hitting the warehouse, catching errors at compile time instead of run time. This eliminates entire classes of failed runs.

• Sub-second parsing: Projects with thousands of models that took minutes to parse in dbt-core now compile in seconds.

• State-aware orchestration: Fusion knows what has already been built and what truly needs to be rebuilt — skipping redundant work across environments and CI runs.

• AI-ready metadata: Fusion exposes a richer semantic graph designed for consumption by LLMs, copilots, and downstream agentic workflows.

Real-world impact

In a Feb 2026 engineering post, dbt Labs reported a 64% reduction in dbt-related warehouse compute costs on its own internal analytics platform after migrating to Fusion with state-aware orchestration. For enterprise teams running large dbt projects on Snowflake, BigQuery, or Databricks, this is the kind of structural improvement that changes the cost-to-serve of the entire analytics function.

Licensing — read this carefully

Fusion ships under the Elastic License v2 (ELv2), not Apache 2.0. The classic dbt Core remains Apache-licensed and continues to receive maintenance, but new innovation is concentrated in Fusion. Leaders evaluating long-term strategy should understand which engine their teams are standardizing on and the licensing implications for embedded or resold use cases.

🔌 Microsoft Fabric, Snowflake, Databricks, BigQuery — Fusion Everywhere

Throughout 2025, dbt Labs aggressively expanded the Fusion ecosystem. The Microsoft Fabric integration (announced November 2025) brought first-class Fusion support to Fabric's OneLake and Warehouse experiences, joining existing native integrations across Snowflake, Databricks, BigQuery, and Redshift.

The strategic message is clear: dbt is positioning itself as the universal transformation layer across every major cloud data platform — and the Fusion engine is the runtime that makes that promise credible.

🧱 Six Real-World Patterns: Where Bronze Lands and How dbt Builds Silver & Gold

The diagram above shows the shape of a multi-engine lakehouse. In practice, the architecture an enterprise actually deploys depends on a single upstream decision: where does Bronze land? Once that's settled, dbt's role in building the Silver and Gold layers — and which adapter does the work — falls into one of six recurring patterns.

🟫 Bronze in Databricks (Delta / Iceberg in Unity Catalog)

A1 · Pure Databricks path

Fivetran or Auto Loader drops raw data into bronze.raw_* as Delta tables. The dbt-databricks adapter connects to a Databricks SQL Warehouse and builds Silver models (typed, deduplicated, SCD-2) and Gold models (with OPTIMIZE + ZORDER post-hooks for BI). Orchestration via Databricks Workflows or dbt Cloud. Choose when: ML- and streaming-heavy org with Power BI or Tableau hitting Databricks directly.

A2 · Databricks Bronze → Snowflake Gold via UniForm

Bronze stays Delta in Databricks. Silver is built in Databricks with Delta UniForm enabled, exposing the same files as Iceberg. Snowflake reads those Silver tables through an external Iceberg catalog pointed at Unity Catalog's REST endpoint, and a second dbt project (dbt-snowflake) materializes Gold as native Snowflake tables for sub-second BI. Two dbt projects, one shared Iceberg contract — no copies. Choose when: Engineering and ML live in Databricks, governed business consumption lives in Snowflake.

A3 · One dbt project, dual-engine deployment

Bronze is written directly as managed Iceberg tables in Databricks. A single dbt project compiles Silver models on Databricks (heavy joins, Photon-accelerated) and Gold models on Snowflake (fast aggregations, semantic layer) — both reading the same Iceberg storage. dbt Fusion's engine-aware compilation handles dialect differences; target profiles route which models run where. One lineage graph, one CI pipeline. Choose when: Mature platform team committed to a true multi-engine strategy with a single source of transformation truth.

❄️ Bronze in Snowflake (native or Iceberg)

B1 · Pure Snowflake path

Snowpipe or Fivetran lands raw data in bronze.raw_* as native Snowflake tables. The dbt-snowflake adapter builds Silver as incremental merge models and Gold as dimensional tables — with Dynamic Tables for near-real-time gold metrics where SLAs demand it. Orchestrated via Snowflake Tasks or dbt Cloud. Choose when: Snowflake-first shop with no ML or streaming pressure and the smallest possible operational surface.

B2 · Snowflake Bronze → Databricks for ML via Polaris

Silver is built in Snowflake as Snowflake-managed Iceberg tables registered in Polaris Catalog. Databricks Unity Catalog federates Polaris, making Silver queryable from notebooks and MLflow without copying. Gold splits cleanly: BI-facing gold is built in Snowflake (native tables, fastest BI), while a small dbt-databricks project reads the same Silver Iceberg tables and materializes feature-store gold in Delta for MLflow. Choose when: Snowflake is the governed system of record but you need Databricks for ML without paying the egress and duplication tax.

B3 · Gold zone consolidated on Iceberg for vendor neutrality

Bronze and Silver remain in Snowflake (existing Snowpipe pipelines, native-table performance for transformation joins), but the curated Gold layer is materialized as Iceberg tables written to your own S3 or ADLS bucket via Snowflake's external Iceberg write support, registered in Polaris. Downstream consumers — Databricks, Trino, DuckDB, Athena, Microsoft Fabric — all read the same Gold Iceberg tables. dbt owns the table contracts via model.yml schemas and dbt-checkpoint enforcement. Choose when: Multi-cloud or M&A scenarios where you may need to swap query engines in 2–3 years without rebuilding Gold.

💡 The Pattern Behind the Patterns

Across all six scenarios, the same architectural truth holds: dbt is the transformation control plane and an open table format (Iceberg or Delta-as-Iceberg) is the storage control plane. Where Bronze lands is an ingestion decision; where Gold is consumed is a business decision; everything in between is a question of which adapter dbt should use to enforce the same contract. That's why standardizing on Iceberg — rather than picking a single warehouse — is the most defensible architectural bet leaders can make in 2026.

dbt is the build tool; the modeling methodology is a separate decision. Teams standardizing on dbt frequently implement Data Vault 2.0 patterns for auditable, scalable historization.

💡 Why This Matters for Analytics Leaders

Adopting dbt is more than a tooling choice — it's a cultural shift. It elevates data teams from report builders to data product engineers. Your pipelines become governed, testable, and reproducible, reducing technical debt and improving stakeholder confidence.

Business impact:

• Agility: Faster iteration and deployment cycles.

• Trust: Built-in testing and documentation improve data credibility.

• Governance: Version control and lineage ensure traceability.

• Efficiency: Warehouse-native execution and Fusion's state-aware orchestration dramatically reduce infrastructure costs.

• AI-readiness: Fusion's semantic metadata is designed to feed LLM copilots and agentic analytics workflows.

⚖️ The Fivetran + dbt Merger: What We Now Know

The Fivetran + dbt Labs merger, first announced in late 2025, is now the largest deal in modern data infrastructure this decade. The combined entity controls both the dominant ingestion platform (Fivetran) and the dominant transformation framework (dbt) — an unprecedented concentration of the modern data stack under one roof.

Fivetran's pricing model — charging by Monthly Active Rows and reacting aggressively to schema changes — is widely viewed as expensive at scale. The community concern is that dbt Cloud and Fusion-based offerings could drift toward similar volume-based pricing, leading to higher costs, tighter restrictions, and deeper vendor lock-in.

The community's response has been pragmatic: continued investment in dbt Core, a surge of interest in SQLMesh, and active forks aimed at preserving open transformation tooling — what some have called the "dbt Fear Index."

Leader actions:

• Decide deliberately between Core and Fusion: Don't drift into Fusion (and ELv2) without an architectural review.

• Avoid over-consolidation: Don't tie ingestion, transformation, and orchestration to a single vendor — even if the bundle looks convenient.

• Negotiate hard on contracts: Lock in pricing protections before you're deeply embedded.

• Monitor alternatives: SQLMesh, Coalesce, Dataform, and Airbyte remain credible modular options.

🧭 Strategic Options for Data Leaders

The six patterns above can be summarized in one comparison view. Your choice of where Bronze lands — and which engine builds Silver and Gold — depends on existing investments, team skills, and whether you need to serve both Databricks and Snowflake from the same data. The principle remains: don't standardize on a vendor — standardize on a composable architecture built on open table formats and a shared catalog.

⚡ When dbt Meets Scale: Choosing the Right Engine for the Job

As organizations expand beyond the traditional warehouse model, the question often arises:
"Can dbt handle large-scale ingestion or raw data preparation?"

The short answer: It shouldn't have to — even with Fusion's performance gains.

dbt excels at semantic transformations, testing, and lineage — but it isn't built for massive distributed compute or schema evolution. When teams push dbt to handle ingestion, complex deduplication, or CDC logic, performance and cost can quickly escalate. The limitation isn't in dbt's design — it's in using the wrong tool for the wrong layer.

🧩 Distributed Engines Built for Heavy Lifting

When raw data volume, schema drift, or complex joins enter the picture, a distributed processing engine should lead the way before dbt takes over. Modern choices include:

These engines provide predicate pushdown, partition pruning, schema evolution, and merge-on-read capabilities that dbt's SQL layer alone cannot efficiently perform.

🧠 The Symbiosis Model

The modern architecture isn't dbt or Spark — it's dbt and Spark. A healthy data pipeline layers tools by purpose:

Raw Ingestion  →  PySpark / Glue / Dataflow / Fabric Spark
Curated Layer  →  dbt (Core or Fusion) Transformations
Semantic Layer →  dbt + BI (Power BI, Looker, Tableau)

Each tier plays a distinct role:

• Distributed engines prepare and optimize data at scale.

• dbt defines business rules, ensures testing and lineage, and enforces transformation discipline.

• BI & semantic tools deliver insights and metrics consistently across the organization.

🔭 The Road Ahead

dbt remains a cornerstone of the modern analytics stack — but the landscape is shifting fast. The Fusion engine dramatically raises the performance ceiling. The Fivetran merger raises real questions about openness and pricing. And the rise of AI copilots and agentic analytics is reshaping what a transformation layer is even for.

For analytics leaders, the message is clear:

Build systems that scale with your business — not systems that your business scales to pay for.

Choose openness deliberately. Evaluate Fusion on its merits, not its marketing. Encourage versioned, testable data. Treat your data like code.

That's how you future-proof your analytics ecosystem — and ensure your team remains in control of its own data destiny.