Dataform vs dbt: A technical comparison for 2026. 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... 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. 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, 2 Structurally 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.

dbt Labs named Snowflake Data Integration Product Partner of the Year. dbt Labs, a leader in standards for AI-ready structured data, announced today at Snowflake Summit 2026 that it has been named the 2026 Data Integration Snowflake Product Partner of the Year, in addition to being recognised for Snowflake's CoCo Adoption Award for leading adoption and delivering customers transformative results via Snowflake's coding agent and control plane for builders. dbt Labs is being recognised for its achievements as part of the Snowflake AI Data Cloud, helping joint customers unlock production-grade workflows that are built on a reliable, governed and trusted data foundation, ready to run AI agents reliably, at scale. dbt has become a preferred transformation and context engine for customers' AI and analytics use cases, with over 75% of customers with Snowflake accounts using dbt and powerful tools like the dbt Semantic Layer, the dbt Fusion engine, and dbt MCP server to unlock a faster developer experience and execute new and complex AI use cases. With 90% of joint customers actively using Snowflake Cortex AI, dbt is an integral part of their AI journey, delivering the reliable data foundation that enables these organisations to take full advantage of Snowflake's AI functionality. "Trust in data is the most widely prioritized organisational objective, and Snowflake Marketplace is a powerful resource to connect enterprises to dbt and its latest features that bring structure, governance, and velocity to what data teams are building in the AI era," said Shawn Toldo, Vice President, WW Partner Organisation at dbt Labs. "This award underscores our mutual dedication to supporting our joint customers and delivering remarkable results, allowing for data-driven innovation at scale to expand the reach of data and AI capabilities." This is the fourth consecutive year that Snowflake selected dbt Labs as a Snowflake partner award winner, which is a testament to the depth and durability of their collaboration and the impact of this longstanding partnership. The companies are united in their mission to help customers cost-effectively build AI-powered insights and data assets, ultimately driving deeper organisational trust in data and the teams that power it. With transactions on the Snowflake Marketplace growing by approximately 30% year over year, dbt Labs is helping customers utilise their full spend from Snowflake contract commitments to ensure optimal ROI. "dbt Labs has been an incredible partner to us over the years and we're proud to name them as Snowflake's 2026 Data Integration Partner of the Year," said Amy Kodl, SVP, Worldwide Alliances & Channels. "The work their team is doing with the AI Data Cloud ecosystem continues to deliver strong results for our joint customers." Joint customer WHOOP is a testament to this continued collaboration. As the WHOOP team grew, they used the dbt platform as a scalable solution to ensure clean and well-governed data was being migrated into Snowflake. dbt provided the foundation that gave all stakeholders at WHOOP access to reliable data, which allowed the team to use Snowpark to build the WHOOP AI/ML financial forecasting model. What once was a major roadblock is now streamlined, saving time for the WHOOP analyst and data engineering teams to focus on more strategic initiatives.

SelectZero now integrates with dbt. Published On: May 28, 2026 SelectZero now ingests metadata from both dbt Core and dbt Cloud. Your dbt models, sources, seeds, snapshots, tests, and lineage flow into the SelectZero catalog and merge with metadata from every other system you connect - your BI tools, ETL jobs, operational databases, and warehouses. dbt teams get a single place to see how their models are actually used downstream. Data teams outside dbt get visibility into what dbt is doing upstream. Everyone gets one catalog, one lineage graph, one source of truth. The problem dbt users keep running into. dbt is excellent at what it does. You version your transformations, test them, document them, and ship them with confidence. The dbt docs site gives you a clean view of your project: models, sources, tests, lineage between them. But your dbt project is not the whole picture. It is a slice in the middle. Upstream, data arrives from operational databases, SaaS systems, files, message queues, and CDC pipelines. Downstream, your models feed dashboards, reports, reverse-ETL jobs, ML pipelines, and exports to other teams. dbt sees the part it owns. It does not see where the source tables actually come from, and it does not see where the marts actually end up. This creates familiar pain: * An analyst changes a column in a core model and breaks a Power BI report nobody linked to the dbt project. * A platform team deprecates a source table without realising six dbt models depend on it. * Compliance asks "where does this PII column end up" and dbt docs can answer for the warehouse but not for the BI layer or the export jobs. * New engineers spend weeks learning which dbt models are actually important versus abandoned. dbt docs solve the in-project problem. SelectZero solves the cross-system problem. What the integration actually does. SelectZero connects to your dbt project and ingests the standard dbt artifacts: manifest.json, run_results.json, and catalog.json. For dbt Cloud, SelectZero pull these from the Cloud Admin API and enrich them with metadata from the Discovery (GraphQL) API, using a service token. For dbt Core, SelectZero read the same three artifacts from S3 or any S3-compatible object store - point your CI job at a bucket and SelectZero'll pick them up from there. From those artifacts SelectZero extract: * Models, sources, seeds, and snapshots as first-class catalog objects, tagged with their dbt project, schema, and materialization. * Column-level lineage linking each dbt model to the warehouse table it materialises and through to its upstream sources and downstream consumers, so a column in a mart connects back through staging to the raw source it came from. * Tests registered as SelectZero test cases, with the latest pass/fail outcomes pulled from run_results.json so dbt test history shows up next to the rest of your data-quality runs. * Source freshness captured from the manifest and attached to the source. * Descriptions, tags, and meta fields from your schema.yml files (merged with column comments from catalog.json), so the documentation you already wrote shows up in the catalog without duplication. The result is that every dbt object appears in the SelectZero catalog with a dbt badge, and its lineage connects on both sides: backwards into the warehouse tables and operational sources that feed it, forwards into the BI dashboards, reports, and downstream consumers that depend on it. The built-in dbt explorer. Alongside the unified catalog view, SelectZero ships a dedicated dbt explorer: a tree of every model, source, seed, snapshot, and test in your project, grouped by type, with a detail panel that shows columns, dependencies, the compiled metadata, and the latest run status for whatever you click. If your team already lives in dbt docs, the explorer gives them something they recognise - but with everything else SelectZero knows about that object one click away. Concrete value by audience. For dbt developers. You stop guessing at downstream impact. Before you change a model, you can see every Power BI report, Tableau dashboard, Looker explore, reverse-ETL sync, and ad-hoc consumer that touches the columns you are about to modify. dbt's -defer and state comparison tell you what changed inside the project. SelectZero tells you who outside the project will feel it. You also get a public surface for your work. The descriptions and tests you write in schema.yml are visible to business users who would never open a dbt docs site - they search the catalog, find your model, and trust it because the tests next to it are green. For data platform and governance teams. dbt becomes a transparent part of the estate instead of a black box that produces tables. You can answer "where does customer email show up" in one query, across operational DBs, dbt models, marts, BI tools, and exports. PII tags follow dbt lineage automatically. Access reviews, retention policies, and data contracts apply uniformly whether a column lives in a source table, a dbt staging model, or a downstream report. For BI and analyst teams. When a dashboard breaks or a number looks wrong, you trace it backwards through SelectZero's lineage into the exact dbt model and the exact source table, with the latest test results and freshness right there. No more "ask the dbt team" tickets to find out why a metric shifted. For leadership and compliance. One catalog covers the whole estate. Audit questions about data flow, ownership, and quality get answered from a single system instead of stitched together from dbt docs, warehouse metadata, BI tool catalogs, and tribal knowledge. dbt test results land where the rest of your DQ lives. Every dbt test SelectZero find in the manifest is registered as a SelectZero test case against the column or model it covers. Each time SelectZero sync run_results.json SelectZero attach the latest outcomes as test-case executions, so dbt tests live in the same execution history as every other SelectZero check. Failed runs and stale models surface immediately in the catalog, not after someone notices a broken dashboard. Row-level issues are immediately available to users with the right privileges. dbt Core and dbt Cloud, same experience. SelectZero support both. * dbt Cloud users provide an account ID and a service token. SelectZero pulls artifacts from the Admin API and enriches the model graph through the Discovery (GraphQL) API. Access and Discovery URLs are configurable, so regional dbt Cloud instances work out of the box. * dbt Core users point SelectZero at an S3 or S3-compatible bucket (with an endpoint override for MinIO, R2, GCS-with-HMAC, etc.) where your CI uploads manifest.json, run_results.json, and catalog.json. No agent, no local file path, no extra service to host. The catalog experience is identical from there. If you run a mixed setup - multiple dbt projects across Core and Cloud - they all land in the same SelectZero catalog and lineage graph. Getting started. * Add your dbt project in Settings | dbt. Pick dbt Cloud (account ID + service token) or Artifacts (S3 bucket + credentials), and link the warehouse connection it builds against. * Connect at least one upstream source (your warehouse or operational DB) and one downstream consumer (BI tool, reverse-ETL, or export job). The value of cross-system lineage scales with what is connected. * Open the catalog or the dbt explorer. Your dbt models are there, with tests, freshness, descriptions, and full upstream/downstream lineage. That is the whole setup. No changes to your dbt project, no new YAML, no required tags or conventions. SelectZero reads what dbt already produces. Closing. dbt gave the industry a great pattern for transformation. SelectZero extends that pattern across the rest of the estate. For teams running dbt who care what happens to data before it arrives and after it leaves, the integration is built for exactly that. Interested in hearing more? Book a Demo Explore SelectZero