dbt Core vs dbt Cloud: what you actually pay for

dbt Core is free, and it is the part that does the work. Everything dbt Labs charges for sits around it: a place to write models, a scheduler to run them, continuous integration, hosted documentation, a metrics layer and the governance a larger company asks for. So "dbt Core vs dbt Cloud" is the wrong comparison to make. The honest one is dbt Cloud versus dbt Core plus the things you must run yourself — and whether you already have somebody to run them.

I build data platforms on my own, so I sit firmly on the self-hosted side of this: Dagster orchestrates my production pipelines, ClickHouse serves them, and I have written about letting Claude Code write dbt models. That does not make the managed product bad value. It makes the cost visible, which is the thing most of these comparisons skip.

One naming note. dbt Labs renamed the hosted product from "dbt Cloud" to the dbt platform, and renamed parts of it too — the IDE is Studio, Explorer became Catalog. Searchers still type "dbt Cloud", so I use that below; the docs and the pricing page say "dbt platform".

The short answer

Run dbt Core if you already have an orchestrator and a platform engineer. You get the whole transformation framework for nothing, the scheduling is an hour's work in a system you already run, and CI is a GitHub Actions file. This is the right call for small teams, cost-sensitive teams, and anyone who wants no vendor in the critical path.

Pay for dbt Cloud if analysts who will not open a terminal need to ship models, if you have enough developers that a browser IDE and a hosted scheduler pay for themselves in setup time, if you want the Semantic Layer or cross-project references, or if compliance needs single sign-on and audit logs. It is also the right call when nobody owns infrastructure, because a pipeline with no owner fails quietly either way — and at least the paid one has someone to call.

Neither choice changes what your models compile to. That is the useful thing to hold on to.

What each one is

dbt Core is a command-line tool, Apache 2.0 licensed. It takes SQL files with Jinja templating, resolves the dependency graph between them, compiles them to plain SQL, runs them against your warehouse in the right order, and runs your tests. It does not store data and it does not schedule anything. It runs when something runs it.

dbt Cloud (now called the dbt platform) is the hosted product built on that engine. At the time of writing it includes the Studio IDE and Canvas for development, a job scheduler, continuous integration on pull requests, hosted documentation, dbt Catalog for discovery and lineage, dbt Insights for exploratory querying, the dbt Semantic Layer, an AI agent called dbt Wizard, notifications, and the access-control features larger companies need. dbt Mesh — cross-project ref() calls between separate dbt projects — is a platform feature on the Enterprise tiers.

dbt Fusion is the newer engine, rewritten in Rust — and the reason the licence question got complicated for a year. More below.

At a glance

	dbt Core	dbt Cloud (dbt platform)
Transformation engine	Yes, free, Apache 2.0	The same engine
Cost shape	Free software; your engineer's time	Per developer seat, plus usage limits per plan
Development	Your editor, plus the VS Code extension	Studio IDE in the browser, or Canvas
Scheduling	You bring one: Dagster, Airflow, cron	Built-in scheduler
CI on pull requests	You write it: GitHub Actions and state deferral	Built in, with deferral
Documentation	dbt docs generate plus static hosting	Hosted docs and Catalog
Semantic Layer	Not available	Starter and above
Cross-project refs (Mesh)	Not available	Enterprise and Enterprise+
SSO, RBAC, audit logs	Your own identity provider, if at all	Enterprise tiers
Who fixes it at 3am	You	You, but with support to call

What dbt Cloud costs, as of September 2026

Read these off the dbt pricing page before you plan around them: they move, and the plans changed during 2026.

At the time of writing the page lists four plans. Developer is free: one developer seat, 3,000 successful models built per month, one project. Starter is $100 per user per month: up to five developer seats, 15,000 successful models built per month, 5,000 queried metrics per month, one project. Enterprise and Enterprise+ are custom-priced, both listing 100,000 successful models built per month and 20,000 queried metrics per month, with 30 projects on Enterprise and unlimited on Enterprise+.

Two features of that structure matter more than the headline number. First, it is per seat and metered: "successful models built per month" is a usage limit, so a team that adds models or moves a schedule from daily to hourly moves its own bill. Second, the things people most often say they want dbt Cloud for — the Semantic Layer, Catalog, Mesh — sit on the higher plans, so the realistic comparison for those teams is against a custom-priced contract, not against $100.

What self-hosting dbt Core actually takes

This is the list the "dbt Core is free" argument leaves out. None of it is hard. All of it is real.

An orchestrator. Something has to run dbt build on a schedule, retry it, and show you what failed. Dagster, Airflow, Prefect, or plain cron and GitHub Actions for a small project. I run Dagster, and if you want to see the shape of a solo-run platform there is a full teardown in building a data platform on my own. If you already have an orchestrator, dbt is one more job in it and this line costs you an afternoon. If you do not, you are adopting a second system alongside dbt, and that is the single biggest reason teams end up paying.

CI that does not rebuild the world. This is the piece people assume is exclusive to the paid product, and it is not. The trick is state comparison: keep the manifest.json from your last successful production run, and on a pull request build only the models that changed and their children, deferring everything else upstream to production.

name: dbt CI
on: pull_request

jobs:
  build-changed:
    runs-on: ubuntu-latest
    env:
      DBT_PROFILES_DIR: ./ci
      WAREHOUSE_PASSWORD: ${{ secrets.WAREHOUSE_PASSWORD }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
      - run: pip install dbt-core dbt-snowflake
      - run: dbt deps

      # The manifest your last production run uploaded
      - name: Fetch production state
        run: |
          mkdir -p prod-artifacts
          aws s3 cp s3://my-dbt-artifacts/manifest.json prod-artifacts/

      - name: Build only what changed, plus downstream
        run: |
          dbt build --select "state:modified+" \
                    --defer --state prod-artifacts \
                    --target ci

The matching half is one step at the end of your production job that uploads target/manifest.json back to that bucket. --state points at the directory holding the manifest, not at the file. Recent dbt versions also accept DBT_ENGINE_STATE and DBT_ENGINE_DEFER as environment variables if you would rather not pass flags. Check the flag names against the current docs before you copy this: the selection syntax has been stable for years, the deferral flags less so.

Docs hosting. dbt docs generate writes a static site. Serve it from S3, GitHub Pages or your own box, behind whatever auth you already use. This is genuinely a small job. What you do not get for free is Catalog's column-level lineage.

Secrets and environments. Warehouse credentials in a secrets store, not in profiles.yml in the repo. Separate development and production targets writing to separate schemas, so a developer's run cannot overwrite a production table. Both are standard practice and both are your job.

Alerting. A failed run has to reach a person. Your orchestrator almost certainly has a Slack or email hook; wire it on day one, and make sure the message says which model and which test. The most expensive dbt failure is the quiet one, where a test failed at 2am and a dashboard has been wrong ever since.

An owner. The honest requirement. All of the above is perhaps a week to set up properly and then a small, irregular tax: version upgrades, a broken adapter, a CI runner that needs a bigger box. If nobody's job description contains that tax, it will not get paid, and you will find out through a stale number in a board deck.

What Fusion and the Fivetran merger change

Both are recent enough that the answer you remember is probably out of date. Here is what the companies have actually said.

Fusion is dbt's engine rewritten in Rust. Beyond speed, it parses SQL properly rather than treating it as text, which is what makes column-level lineage, type checking and a built-in linter possible. When it launched it was under the Elastic License v2 — source-available, not open source — and that worried people, reasonably.

On 1 June 2026 dbt Labs relicensed the Fusion runtime to Apache 2.0 and shipped it as dbt Core v2, in the dbt-core repository. The two engines now share one foundation. The first stable release, 2.0.0, was tagged on 14 September 2026, so treat it as new. dbt Labs has said Core v1 "is not going away tomorrow, or any time soon", and v1.12 was still getting releases that same week. There are two distributions: the full dbt one, and a strictly Apache 2.0 dbt OSS one for organisations that require it. Some of the more advanced features — full language-server support, SQL comprehension, column-level lineage — need a login to a dbt platform account, though a free account is enough for those. That login is the new shape of the free/paid line, so read the current availability table rather than assuming.

The merger. Fivetran and dbt Labs announced their combination on 13 October 2025 and completed it on 1 June 2026. The public commitment, in dbt Labs' own licensing FAQ, is that the combined company "will continue maintaining the open source version of the dbt framework (i.e. dbt OSS) under the Apache 2 license indefinitely". Relicensing Fusion from ELv2 to Apache on the day the merger closed is evidence pointing the same way.

What is not known: how the combined company will price the platform in two years, and how dbt will sit alongside SQLMesh. Fivetran bought its maker, Tobiko Data, in September 2025, then contributed SQLMesh to the Linux Foundation in March 2026, so that project is now vendor-neutral — the full story is in SQLMesh vs dbt. I would not speculate past that, and I would not let it change a decision you need to make this quarter — the licence on the thing you would self-host is Apache 2.0 today, and an Apache 2.0 release cannot be taken back.

When dbt Cloud is worth paying for

• Analysts write models and will not use a terminal or git from the command line. The browser IDE is the whole product for them.
• You have enough developers that hosted scheduling, CI and docs are cheaper than the engineer-weeks to build and own them.
• You want the Semantic Layer, so metrics are defined once and queried the same way from every BI tool.
• Multiple teams need separate projects with cross-project ref() — that is dbt Mesh, and there is no self-hosted equivalent.
• Compliance needs SSO, role-based access control and audit logs, and you would otherwise build them.
• Nobody owns infrastructure. This is the decisive one. Do not choose Core to save money and then discover the saving was funded by an engineer who never agreed to it.

When dbt Core is the right call

• A platform engineer exists, and an orchestrator already runs.
• The team is small — a handful of people comfortable with git, a repo and a terminal.
• Cost matters, and seat growth is the thing you are guarding against.
• Your warehouse is unusual, or you are running dbt against something the hosted product supports poorly.
• You want nothing between your code and your warehouse: no vendor in the critical path, no pricing change you did not choose.

The hidden cost on each side, and how to price both

Both sides of this decision have a cost that does not appear in the pitch.

On dbt Cloud, it is growth. Seats multiply as analysts join. Usage limits tighten as models and run frequency grow — and both tend to grow quietly, one model and one schedule change at a time. The bill you sign is rarely the bill you pay in year two.

On dbt Core, it is your engineer. Setup is maybe a week. After that it is a tax that never arrives as an invoice, which is why it is easy to ignore until the person carrying it leaves.

You can put numbers on both sides. For the paid side: seats you will have in twelve months, times the list price for your plan, times twelve, plus what the usage limits do when your model count and run frequency grow — ask for the overage terms in writing before you sign. For the self-hosted side: hours to build it once, plus hours per month to keep it running, times a fully-loaded hourly cost for whoever does that work. I set out how I think about that second number in what data engineering costs and how I price it. Do both sums on your own inputs. The gap is usually not close, in one direction or the other, and which direction it goes is decided almost entirely by whether the orchestrator and the owner already exist.

A word on the alternatives

SQLMesh is the serious alternative framework. It understands your SQL at the column level, so it can tell a real change from a cosmetic one and avoid rebuilding everything downstream of a comment edit, and its virtual data environments make a full staging copy cheap. It is a different model, not a drop-in swap, and it is now owned by Fivetran as well. Dataform is free and built into BigQuery; if you are entirely on BigQuery and want scheduled SQL transformations without a bill, it deserves a look before dbt Cloud does. There are also third-party platforms that host dbt Core jobs for you — narrower than the dbt platform, and usually cheaper, if scheduling and an IDE are all you wanted.

If you want to check the rest of your stack while you are at it, the data platform teardown is the checklist I use — free, no email. And if you want someone who runs this kind of platform in production to cost both sides against your actual setup and write the answer down, that is what a data platform audit is for. The scoping call below is free.