When Databricks announced its acquisition of Neon in May 2025, it cited telemetry showing that over 80% of databases on that platform were created by AI agents, not humans. That statistic raised a broader question for every data platform, including Databricks: if an agent writes your revenue model, who owns the definition? And when the CFO asks how a quarterly number was produced, where does the answer live?

For teams already running on Databricks, the question is whether dbt still justifies its overhead. Databricks is a strong platform for compute, storage via Delta, ML pipelines, and AI feature engineering. The dbt-databricks adapter is maintained by Databricks, and thousands of teams run both in production. But choosing Databricks for compute and choosing it to own transformation logic are two separate decisions that many companies make together without realizing it.

The risks of full consolidation become concrete when you try to leave, audit, or explain. Transformation logic in Lakeflow pipelines or notebooks requires rewriting to move elsewhere, and version control depends on vendor access controls. Lineage in a proprietary catalog records what happened, but open, version-controlled SQL lets you change what happens independently.

dbt offers portability across warehouses, an open runtime (dbt Core v2.0, open sourced June 1, 2026 under Apache 2.0), a platform-agnostic semantic layer, a community of over 100,000 teams, and cost savings via dbt State, which can cut warehouse compute by 30% or more. The boundary: Databricks handles compute and storage; dbt owns transformation logic, semantic definitions, contracts, and testing.

Executives should ask whether they can move 30% of workloads in 90 days, produce an audit trail without Databricks access, keep metric definitions in code, and have a fallback if pricing changes. The risk isn't the partnership—it's blurring the line between the two layers.

Source: dbt Labs Blog