BI tools are increasingly expected to integrate with dbt rather than maintain separate transformation logic. The default assumption in modern data stack assembly has shifted toward dbt as the foundation layer that BI tools read from.
Previously, the BI tool maintained its own semantic modeling (LookML, Tableau’s data model), its own calculated fields, its own version of business logic, independent of the dbt transformation layer. When the semantic layer lives in dbt, when metrics are defined in YAML alongside models, and when tests and documentation are generated from the same codebase, a BI tool that maintains a parallel modeling layer creates metric drift by design.
The Evidence
The strongest signal is what new BI tools choose to build on.
Lightdash is the clearest case. It reads directly from your dbt project YAML, auto-generating dimensions and metrics from model metadata. There is no separate modeling layer. What you define in your dbt project is exactly what appears in the BI tool. No drift between transformation and presentation, no “sync” step, no parallel definitions.
Evidence takes a similar philosophy in a different direction: reports built with SQL + Markdown, deployed as static sites, version-controlled alongside the dbt project. The BI output lives in the same repo as the transformation logic.
Omni was founded by ex-Looker engineers who explicitly wanted to fix Looker’s relationship with dbt. Its YAML-like modeling and Git versioning are designed to align with dbt workflows rather than replace them.
Even the legacy tools are adapting. Looker shipped a dbt Semantic Layer connector. Tableau added one in Tableau Cloud 2025.2. Power BI’s PBIR format (default since January 2026) makes report definitions folder-based and Git-friendly. The direction is clear, even if the adaptation is slow and these tools carry architectural assumptions from a different era.
The Fivetran-dbt Labs Merger
The defining event that makes dbt’s centrality structural rather than cultural: the Fivetran-dbt Labs merger closed in late 2025, creating a combined entity with roughly $600M ARR and 10,000+ customers. George Fraser (Fivetran CEO) leads the combined company; Tristan Handy serves as President. dbt Core remains open source.
This matters because it unifies data movement and data transformation under one roof. Fivetran handles ingestion. dbt handles transformation, testing, documentation, and the semantic layer (via MetricFlow, now Apache 2.0). The combined platform spans from source extraction through metric definition — everything below the BI visualization layer.
The acquisitions that led here are telling:
- Fivetran acquired Census (May 2025) for reverse ETL — pushing transformed data back to operational tools
- Fivetran acquired Tobiko Data (September 2025) — the team behind SQLMesh, a dbt alternative, now folded into the dbt ecosystem
- MetricFlow went Apache 2.0, removing licensing friction for adoption
The combined company now controls the pipeline from source to metric. BI tools that don’t integrate with this stack are swimming against the current.
What “dbt-Native” Actually Means
There’s a spectrum of dbt integration, and the differences matter:
Built on dbt. Lightdash and Evidence treat the dbt project as their source of truth. No parallel definitions. The dbt DAG is the BI tool’s data model. Changes to dbt models automatically update what’s available in the BI layer.
Connected to dbt. Looker, Tableau, and Steep consume metrics from the dbt Semantic Layer API (via JDBC, GraphQL, or REST). They maintain their own modeling and visualization layers but can pull governed metrics from dbt. This is integration, not unification — you still have two systems, but they talk to each other.
Parallel to dbt. Metabase, Preset/Superset, and most legacy tools operate independently. They query the warehouse tables that dbt produces, but they don’t read dbt metadata, don’t consume dbt metrics, and define their own semantic concepts (if any). This works, but it means your metric definitions in dbt and your metric calculations in the BI tool can diverge silently.
The practical question for any team evaluating BI tools: where on this spectrum do you want to be? If you’ve invested in dbt’s modeling layer — naming conventions, documentation, tests, semantic models — choosing a BI tool that ignores all of that work is throwing away value.
The Consolidation Signal
The modern data stack is consolidating around fewer, larger platforms. The Fivetran-dbt merger is the most visible example, but the pattern is broader:
- Hex acquired Hashboard (May 2025) to add semantic modeling to its notebook interface
- Omni acquired Explo (September 2025) for embedded analytics
- ThoughtSpot acquired Mode (July 2023) for code-first analytics
- Sigma hit $1.5B valuation and $100M ARR, becoming Snowflake’s and Databricks’ BI Partner of the Year
The direction is toward integrated platforms rather than best-of-breed point solutions. And in this consolidation, dbt sits at the center — the transformation and semantic layer that everything else connects to.
This doesn’t mean you need to go all-in on dbt-native BI. Metabase is still the best choice for teams prioritizing non-technical self-service. Looker’s enterprise governance is still unmatched in maturity. But the architectural gravity is pulling toward dbt as the foundation, and BI tools that resist this pull will increasingly feel like they’re fighting the ecosystem rather than participating in it.
73% of BI implementations fail to deliver ROI in the first year (SR Analytics). The primary failure modes are poor data modeling, missing governance, and unclear metric definitions — problems in the transformation layer, not the visualization layer. A well-structured dbt project with governed metrics and a clean semantic layer reduces these failure modes across BI tool choice.