Dataform vs dbt in 2026: Which Should You Run, and Where Agents Fit

Choose Dataform if you run only on BigQuery and want transformation built into Google Cloud at no extra license cost. Choose dbt if you use more than one warehouse, need the larger package ecosystem, or want the tooling that AI coding agents already know best. Dataform is a Google Cloud product (Dataform docs), and dbt is an open-source framework with a commercial cloud offering (dbt docs).

Key Takeaways

• •Dataform targets BigQuery and is part of Google Cloud; dbt Core supports many warehouses through adapters.
• •Both tools compile SQL into a dependency graph, run it in the warehouse, and support assertions or tests. The core idea is the same.
• •dbt has the larger community, package ecosystem and volume of public examples, which matters when an AI coding agent writes your models. This is our opinion, not a measured benchmark.
• •Dataform wins on setup cost and native Google Cloud integration. dbt wins on portability and ecosystem.
• •Neither tool answers 'what breaks if I change this column?' across your whole stack. That is where agents and shared context come in.

Dataform vs dbt: the short version

Both tools do the T in ELT. You write SQL files that reference each other, the tool builds a dependency graph, and it runs the statements in your warehouse in order. Neither moves data. Neither replaces your orchestrator completely, though both include scheduling of some kind.

The differences that matter in practice are which warehouses you can target, how much you pay, how you test, and how much help you can get from the community and from AI tooling. The table below summarizes our read of each, based on the public documentation.

Check current pricing and feature limits on each vendor's pages before you decide. Both products change quickly and we do not want to quote you a stale number.

Where Dataform wins

If your warehouse is BigQuery and your team already works in Google Cloud, Dataform removes a vendor and a bill. Repositories, scheduling, and access control sit next to the warehouse you already govern with IAM. For a small team, that is a real reduction in moving parts.

SQLX is also easy to read. A config block at the top of a file declares the output type, tags and assertions, and the rest is SQL. Engineers who dislike Jinja often find this cleaner. JavaScript includes cover most reuse needs without a templating language.

Finally, the open-source Dataform CLI and core library exist, so you are not forced to use the console. You can keep your project in Git and run it in CI.

Where dbt wins

dbt wins on portability. If you might move from BigQuery to Snowflake or Databricks, or you already run more than one warehouse, a dbt project carries over with adapter-level changes. A Dataform project is tied to BigQuery.

dbt also wins on ecosystem. The package hub, the community answers, the conference talks and the hiring pool are all larger. When you search for an error message, you will find more dbt results. That advantage compounds when you ask an AI coding agent for help, because public examples are what these models learn from. We cannot give you a measured accuracy gap, and we are not going to invent one, but the direction is clear to us from daily use.

dbt Labs has also invested in agent tooling. They shipped agent skills aimed at coding agents such as Claude Code, so an agent can follow dbt conventions for models, tests and docs instead of guessing. See the dbt Labs documentation for what is currently available.

Testing and data quality compared

Both tools check data as part of the run. Dataform uses assertions: a query that returns rows when something is wrong. dbt uses tests: built-in generic tests such as not null, unique, accepted values and relationships, plus custom singular tests written as SQL. Recent dbt versions also support unit tests on model logic.

In both cases the checks run when the project runs. They catch bad data after a transformation, not before a schema change lands upstream. That gap is worth noticing. A test tells you something failed. It does not tell you why, who owns the upstream table, or which dashboards are affected.

Orchestration and scheduling

Dataform includes workflow configurations and scheduling inside Google Cloud, and it can be triggered from Cloud Composer or other schedulers through its API. dbt Core has no scheduler of its own. Teams run it from Airflow, Dagster, Prefect or CI, or buy dbt Cloud for hosted jobs.

If you want one managed place to schedule SQL on BigQuery and nothing else, Dataform is simpler. If you already run Airflow or Dagster for ingestion and ML jobs, dbt slots into that orchestrator more naturally and gives you one scheduler for everything.

Where AI coding agents fit

Most of our readers now write transformation code with Claude Code or Cursor open beside the repo. Both tools work with that workflow because both are plain text files in Git. The difference is how much the agent already knows. For dbt, an agent has seen a great deal of public code and has official skills to follow. For SQLX, it has seen less, so we find it more often needs a reference file or an explicit instruction about syntax.

The harder problem is not writing the model. It is knowing what a change affects. Questions like 'What's the blast radius if I drop this column?' or 'Is the customer_id join safe after the migration?' need lineage, ownership and recent history, and neither framework holds that across your ingestion, warehouse and BI layers.

This is where we fit. Our Pipeline Agent works with dbt, Airflow, Dagster, Prefect and Fivetran, and every Data Workers agent is an MCP server, so you call it from Claude Code or Cursor. We chain it with catalog and quality agents so a change to a model can be checked against downstream consumers before you merge. Our open-source edition is read-only by default, so you can try it on a real project without handing an agent write access. We cover how this works in our other posts on Claude Code for data engineering.

We should be honest about the limits. If your project is Dataform, our dbt-oriented support will not help as much today. Check what is supported before you plan around it.

How to decide

• •Pick Dataform if you are BigQuery-only, small, already in Google Cloud, and want the fewest vendors.
• •Pick dbt Core if you want portability, a large package ecosystem, and the freedom to choose your own orchestrator.
• •Pick dbt Cloud if you want hosted jobs, a managed IDE and metadata features, and are willing to pay a subscription.
• •Stay where you are if your current setup works. Migrating transformation layers is real work, and the payoff is rarely the tool itself.

If you do migrate from Dataform to dbt, the SQL bodies move easily. The work is in translating config blocks, JavaScript includes, assertions and scheduling. Plan to rewrite those by hand or with an agent, and review each model's output against the old one before you cut over.

We also compared the wider tooling landscape in our posts on catalog and observability alternatives. Choosing a transformation tool is only one decision. The next one is how you keep track of what it builds.

Frequently Asked Questions

Is Dataform free? Dataform itself has no separate license charge on Google Cloud, but you pay for BigQuery compute, storage and any related services it uses. Check the Dataform documentation and Google Cloud pricing for current terms.

Can dbt run on BigQuery? Yes. dbt has a BigQuery adapter, so you can use dbt Core on BigQuery today. That is the usual choice for teams that want BigQuery now and portability later.

Is dbt better than Dataform? Not in every case. dbt is better for multi-warehouse teams and for ecosystem depth. Dataform is better for BigQuery-only teams that want a native, low-overhead option. It depends on your warehouse and team.

Which is easier for an AI coding agent to work with? In our experience, dbt, because there is more public code and official agent skills to draw on. Both are text in Git, so either works with Claude Code or Cursor. This is our opinion, not a benchmark.

Can I migrate from Dataform to dbt? Yes. The SQL carries over with small edits. Config blocks, JavaScript includes, assertions and scheduling need to be translated, and you should compare outputs model by model before switching.