Most Dataform versus dbt comparisons are a feature table and a shrug. They are also, as of this year, out of date: the ground under dbt moved in 2026, and the honest answer to “which should we use” has changed with it.
This is a technical comparison for teams who have to actually pick one. Both tools do the same core job, the T in ELT: take raw tables in a warehouse, turn them into modelled tables through version-controlled SQL, with dependencies, tests and scheduling. They differ in language, ecosystem, ownership and where the risk sits.
What changed in 2026, and why it matters to your decision
Two things, both on the dbt side.
Fivetran and dbt Labs completed an all-stock merger on 1 June 2026, first announced in October 2025. The combined company is led by Fivetran’s George Fraser as CEO with dbt’s Tristan Handy as President, approaches 600 million dollars in ARR and serves more than 80,000 data teams. Both parties have publicly committed to keeping dbt Core under Apache 2.0. The reasonable community concern is not licence rug-pulling but attention: engineering investment naturally drifts towards the commercial product, leaving Core on bug fixes and security patches.
dbt rebuilt its engine in Rust, the Fusion engine, released as dbt Core v2.0 in alpha under Apache 2.0, free to install and run including in production. Alongside it came dbt State, a caching layer that only rebuilds what changed and is claimed to cut infrastructure cost by 30 percent or more, and dbt Wizard, an assistant for authoring and refactoring models with project context.
The practical read: dbt is investing hard and consolidating, which is good for capability and adds vendor-concentration risk. Dataform has not moved much, which is either stability or stagnation depending on your temperament.
The decisive difference: warehouse lock-in
Everything else is preference. This one is structural.
Dataform supports BigQuery. Only BigQuery. It is a Google Cloud service built around BigQuery’s compute and storage, with no cross-cloud portability. If you are on Snowflake, Databricks or Redshift, the comparison ends here and the answer is dbt.
dbt runs against all of them through adapters. That multi-warehouse support is its single biggest structural advantage, and it is worth something even if you are on BigQuery today, because it is insurance against a warehouse migration you have not planned yet.
Language: JavaScript versus Jinja
Dataform uses SQLX, an extension of standard SQL. A SQLX file is a config block plus a query body, with JavaScript available for scripting and reuse. dbt uses SQL files with Jinja templating and macros.
-- Dataform: SQLX
config {
type: "incremental",
schema: "analytics",
description: "Daily sessions by channel",
assertions: {
uniqueKey: ["session_date", "channel"],
nonNull: ["session_date", "sessions"]
}
}
SELECT
session_date,
channel,
COUNT(*) AS sessions
FROM ${ref("stg_events")}
WHERE 1=1
${when(incremental(), `AND session_date > (SELECT MAX(session_date) FROM ${self()})`)}
GROUP BY 1, 2-- dbt: SQL + Jinja
{{ config(materialized='incremental', unique_key=['session_date','channel']) }}
SELECT
session_date,
channel,
COUNT(*) AS sessions
FROM {{ ref('stg_events') }}
{% if is_incremental() %}
WHERE session_date > (SELECT MAX(session_date) FROM {{ this }})
{% endif %}
GROUP BY 1, 2Structurally almost identical. Both use a ref() function to declare dependencies rather than hardcoding table names, and both parse those references to build the DAG and execution order.
The honest comparison: JavaScript is a real language and most analytics engineers can already read it, whereas Jinja is a templating language people tolerate rather than enjoy. Dataform’s ergonomics here are genuinely nicer. But the divergence is a one-way door. There is no clean migration path between JavaScript-based SQLX and Jinja-based dbt, so the language choice is effectively a commitment.
One Dataform constraint worth knowing before you plan anything clever: Node.js modules are not supported, only the V8 runtime. Reaching for an npm package to solve a problem is not an option.
Testing: assertions versus dbt’s test framework
Dataform uses assertions, defined in the SQLX config block or in separate files, checking conditions like uniqueness and non-null. They are inserted into the dependency tree after table creation, so a failing assertion can stop downstream models.
dbt has generic tests, singular tests and a large package ecosystem, most notably dbt-utils and dbt-expectations, which give you distribution checks, referential integrity and row-count comparisons without writing them yourself. dbt’s test framework is more mature, and the gap widens the more sophisticated your data quality requirements get.
Dataform also cannot run unit tests manually, which stings if you were hoping to develop test-first.
Orchestration and operations
Dataform’s model is repository (the project, connected to a service account), workspace (a virtual editable copy that compiles in real time before you commit), release configuration (compilation settings: project override, table prefixes, schema suffixes, variables) and workflow configuration (schedules that run a release configuration). That release and workflow split is a genuinely good environment model, cleaner than dbt’s convention-driven targets.
You can schedule with workflow configurations, Cloud Composer, or Workflows plus Cloud Scheduler, and trigger from Cloud Build. One sharp edge: a scheduled run is skipped if the previous run has not finished at the next trigger. If your pipeline occasionally overruns, you will silently lose runs rather than queue them.
dbt Core has no scheduler at all; you bring Airflow, Dagster, Cloud Composer or dbt Cloud. More assembly, but no ceiling.
Cost
Dataform is free within Google Cloud. You pay only for BigQuery compute and storage, which you were paying anyway. For a BigQuery-native team this is a real and often decisive advantage.
dbt Core is free and open source. dbt Cloud is a paid platform, and the Fivetran merger has introduced genuine uncertainty about future pricing and packaging. If total cost of ownership is the deciding factor and you are on BigQuery, Dataform wins outright.
The part nobody puts in the feature table: hiring
dbt is the industry standard. Analytics engineers arrive knowing it, there is a large body of packages and patterns to copy, and “we use dbt” is a recognisable line in a job advert. Dataform is a smaller world; you will be training people and solving problems without a Stack Overflow answer waiting.
For a two-person analytics team inside a Google-shop company, that matters little. For a team you intend to grow to ten, it matters a lot, and it is the argument that most often decides the question in practice.
How we would actually choose
Choose Dataform if you are committed to BigQuery, want zero additional tooling cost, prefer JavaScript to Jinja, value the native GCP integration and IAM model, and your team is small enough that ecosystem size is not a constraint. It is a well-built, low-ops tool and the free-inside-GCP argument is strong.
Choose dbt if you are on any other warehouse, might migrate warehouse, need the mature testing ecosystem, want the documentation and lineage tooling, or are hiring analytics engineers who should be productive on day one. The Rust engine also makes dbt considerably faster than it was, which removes an old argument against it.
The trap to avoid, in either direction, is picking on syntax preference. Both tools produce the same tables. What differs is the ten-year cost: portability, hiring, ecosystem and who owns the roadmap. Pick for that, then get on with modelling your data, which is the part that actually creates value.
If you are choosing between them, or inherited a transformation layer nobody understands, get in touch. We build these for a living and are happy to tell you when the answer is the tool we did not sell you.
