dbt is the undisputed industry standard for analytics engineering. Dataform is a fantastic, free alternative specifically for BigQuery shops.
I've built production data models in both dbt and Dataform — dbt on Snowflake/Redshift projects, Dataform on BigQuery — and while they look superficially similar, the strategic bet you're making is different. dbt is a portable transformation framework with a huge ecosystem; Dataform is a free, native BigQuery feature that Google acquired and integrated into the console. If you're multi-warehouse or care about skill portability, dbt. If you're committed to BigQuery and want a zero-setup transformation layer that just works in the console, Dataform.
At one GCP-heavy company, the analytics team was using Dataform happily — 200 models, column-level lineage, scheduled runs, all inside the BigQuery console, $0 in tool costs. Then the company acquired a business that ran on Snowflake. Suddenly the "we'll just port it" assumption collapsed. We ended up doing exactly that: rewrote the Dataform project in dbt, reran six months of regression tests, and standardized on dbt as the universal transformation tool across the now-multi-warehouse stack. If I'd been in the room at the original decision, I'd have argued for dbt from the start just for the optionality.
On the other hand, I've seen a scrappy three-person analytics team on BigQuery be wildly productive in Dataform in a weekend, with no local setup, no Python environment, no dbt Cloud bill. For that scale and that commitment to BigQuery, it was clearly the right choice.
dbt run, dbt test, dbt build) that compiles Jinja-templated SQL into warehouse-specific SQL, runs it in the correct dependency order, and manages testing and docs. You write .sql files with {{ ref('model') }} macros; dbt resolves the DAG and executes against your adapter (dbt-snowflake, dbt-bigquery, dbt-databricks, etc.). Runs locally or in dbt Cloud, Airflow, GitHub Actions — wherever..sqlx files (SQL + JavaScript config) in a web IDE, version-controlled in a linked Git repo. Google handles compilation, scheduling (built-in), and execution; everything runs inside BigQuery. Column-level lineage and assertions are first-class.Choose dbt if:
dbt_utils, dbt_expectations, dbt_audit_helper, and hundreds moredbt_utils with 100+ battle-tested macros. Dataform has a smaller standard library; you'll write more helpers yourself. For simple projects this doesn't matter; for complex analytics engineering, it adds up.ref() works similarly to dbt's, but macros, tests, and package patterns don't map 1:1. Plan for weeks of porting, not days, if you migrate.@dataform/core CLI supported Snowflake, Redshift, etc. Google deprecated that path. The Dataform you get today is BigQuery-only.For a new multi-warehouse-capable analytics team, default to dbt — the skill portability alone justifies it. For a BigQuery-committed team looking to ship analytics engineering fast with zero infrastructure spend, Dataform is legitimately good and has matured under Google's stewardship. And if you're a BigQuery shop with a large mature dbt project already running, there's no compelling reason to rewrite — dbt-bigquery works well, and the community resources will keep your team productive.
Yes. Since Google acquired Dataform and integrated it into BigQuery, it's completely free as part of your GCP project. You pay only for the BigQuery compute your transformations consume (same as any BigQuery query). There's no separate license fee, no per-seat pricing, and no extra charge for the built-in web IDE, Git integration, or scheduler. This is a meaningful differentiator vs dbt Cloud, which charges $100+ per developer seat per month.
Yes — `dbt-bigquery` is one of the most battle-tested dbt adapters. Many BigQuery teams explicitly choose dbt over Dataform for the ecosystem (packages, Slack community, certifications), multi-warehouse skill portability, and richer tooling (dbt Cloud IDE, semantic layer, docs site). The trade-off is you give up Dataform's native BigQuery integration and pay for dbt Cloud if you want equivalent hosting, IDE, and scheduling — or you self-host dbt Core with Airflow and GitHub Actions.
No — Google has integrated Dataform as a first-class BigQuery feature and continues to invest. However, the legacy open-source Dataform that supported Snowflake, Redshift, and other warehouses has been deprecated. Today's Dataform is GCP-native and BigQuery-only. If you previously used Dataform on a non-BigQuery warehouse, you'll need to migrate — typically to dbt.
dbt's testing is more mature — generic tests (`not_null`, `unique`, `accepted_values`, `relationships`), singular tests (any SQL returning a row fails), and the `dbt-expectations` package (port of Great Expectations). Dataform has **assertions**, which are similar in concept but less diverse. For simple schema-level tests, both are fine. For complex data quality logic, dbt's ecosystem wins. I've yet to find a dbt test I couldn't express in Dataform, but I've often found it 2–3× more verbose in SQLX than in Jinja.
dbt uses Jinja for templating, which is Python-like and familiar if you've used Flask/Django. Macros live in `macros/*.sql` and can be packaged and shared (`dbt_utils` is the canonical example). Dataform uses JavaScript for config and includes (like `.js` files in `includes/`), which is arguably nicer syntactically — real functions, real imports, no whitespace rules. The win for Dataform here is real for JS-comfortable developers. The win for dbt is the hundreds of existing macros you can just install as a package.
Dataform has built-in Git integration and can run compilation/validation on every PR via GitHub Actions or Cloud Build with minimal setup; Google publishes reference CI templates. dbt's CI story is more flexible but requires more glue — you wire up `dbt compile`, `dbt test`, `dbt build` in GitHub Actions or GitLab CI yourself. dbt Cloud's Slim CI feature (test only changed models) is genuinely great but requires the paid plan. Net: Dataform is easier for default CI; dbt is more powerful once you invest the setup time.
dbt scales better for larger organizations, mainly because of ecosystem maturity: more governance patterns, more tooling around code review and lineage, better integration with data catalogs, established analytics-engineer career path. Dataform works fine at small-to-medium scale but has less proven capacity for 50+ analytics engineers with complex governance needs. If you're currently a 5-person BigQuery team that might grow to 50, think carefully — Dataform's simplicity is attractive now, but dbt's scaling story is more mature.