dbt Core vs dbt Cloud: What You Are Actually Buying, and When to Stop Building It Yourself

The dbt Core versus dbt Cloud question gets answered with pricing pages, which is the wrong place to start. Both run the same dbt. The models compile to the same SQL, the tests are the same tests, and your warehouse cannot tell the difference.

What you are choosing is who maintains the scaffolding around dbt: scheduling, CI, docs hosting, credentials, and the environment analysts write in. That is a real product with a real price, and it is also a thing a competent platform team can assemble in a week. Whether that week — and the maintenance after it — is worth the license is the entire decision.

What is identical

Models, sources, seeds, snapshots, tests, macros, packages, ref(), the manifest, and the compiled SQL. Adapters are the same. Your project directory is portable between them with no changes.

This matters because it means the decision is reversible. Migrating from Cloud to Core is a scheduling and CI project, not a rewrite. Nobody is locked in at the transformation layer, and any vendor suggesting otherwise is selling something.

What Cloud actually gives you

flowchart TD
  repo[Git repo with dbt project] --> core["dbt Core CLI"]
  core --> you{"Who runs it?"}
  you -->|Cloud| c1[Hosted scheduler]
  you -->|Cloud| c2[Browser IDE]
  you -->|Cloud| c3["CI on every PR"]
  you -->|Cloud| c4[Hosted docs + lineage]
  you -->|Core| s1["Airflow / Dagster"]
  you -->|Core| s2["Local editor + venv"]
  you -->|Core| s3["GitHub Actions"]
  you -->|Core| s4["Docs on S3 / Pages"]

Same project, same SQL. Four pieces of scaffolding you either buy or build.

The browser IDE. This is the feature people underrate. An analyst who is comfortable in SQL but not in git, virtualenvs, and profile YAML can open a branch, write a model, preview it, run tests, and open a pull request — without you installing Python on their laptop or debugging their ~/.dbt/profiles.yml on a call.

If your dbt project is maintained by three data engineers, this is worth nothing to you. If it is maintained by fifteen analysts across three business units, it is most of the value of the product.

CI that works without you maintaining it. Cloud’s CI spins up a schema per pull request, runs the modified models and their children, and reports back on the PR. You can build the same thing with Actions — I described exactly how in Slim CI with state:modified+ and –defer — and the part people underestimate is keeping the production manifest artifact fresh and available. It is not hard. It is a thing that breaks quietly and that someone has to own.

Hosted docs and lineage. dbt docs generate produces a static site either way. Cloud hosts it with auth attached. Self-hosting it on S3 behind SSO is a small project you will do once and then be mildly annoyed by.

Credential management. Warehouse credentials live in the platform with role-based access instead of in your orchestrator’s secret backend. A convenience, not a capability.

What Core gives you

Cost at scale. Cloud is priced per developer seat. Below roughly a handful of contributors, the license is usually cheaper than the engineering time to replicate it. Above a couple of dozen — many of whom run dbt twice a month — the arithmetic reverses hard.

One orchestrator owning the whole graph. This is my main argument, and it is architectural rather than financial.

Your dbt run is not an isolated event. It depends on ingestion finishing, and things depend on it afterwards: reverse ETL, BI extract refreshes, ML feature builds, exports to a partner. If dbt runs on Cloud’s own schedule at 06:00 and your loads run in Airflow, you have two schedulers and a padded time gap where a correctness guarantee should be. That gap fails silently the first time a load runs long.

Running dbt Core inside Airflow or Dagster makes the dependency explicit. Better still, express it with datasets and data-aware scheduling so downstream work triggers on completion rather than on a clock. Dagster goes further by modelling dbt models as assets in the same graph as everything else, which is covered in Dagster assets in production.

# dbt Core in GitHub Actions: the CI half of what Cloud sells,
# assuming a production manifest is published somewhere fetchable.
name: dbt slim ci
on: pull_request

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - run: pip install dbt-core dbt-snowflake

      - name: Fetch production manifest
        run: |
          aws s3 cp s3://acme-dbt-artifacts/prod/manifest.json ./state/manifest.json

      - name: Build only what changed, defer the rest
        env:
          DBT_SCHEMA: ci_pr_${{ github.event.number }}
        run: |
          dbt build \
            --select state:modified+ \
            --defer --state ./state \
            --target ci \
            --fail-fast

That file plus a nightly job that uploads manifest.json is the core of Slim CI. It is genuinely not much. It is also one more thing in your repo that will break when dbt changes an artifact schema.

Full control of the environment. Custom Python dependencies, private packages, a specific adapter version, a pre-hook that talks to your secrets manager. Core is a Python package; you own the image.

No adapter or version gating. You upgrade when you decide to.

The decision

The pattern that predicts the answer better than headcount or budget is who writes models.

• Data engineers only, orchestrator already in place → Core. You have the skills, the scheduler, and the CI. Cloud’s IDE solves a problem you do not have.
• Analysts contributing across the business → Cloud. The IDE and managed CI remove the exact friction that otherwise makes you the bottleneck for every model change.
• Small team, no platform engineer, wants to ship this quarter → Cloud. Buying the scaffolding is the right call when nobody is free to build it.
• Large contributor count, strong platform team → Core, with the seat money spent on the orchestrator instead.

There is also a legitimate hybrid: Cloud for development and CI because analysts live there, with production runs triggered from your orchestrator via the Cloud API. You keep one system owning the dependency graph while analysts keep the IDE. It costs more than either pure option and solves a real problem.

Pitfalls

Two schedulers, one project. Cloud jobs on a cron plus Airflow DAGs on another cron is the failure I see most. One system owns the graph. The other triggers it or does nothing.

Building Slim CI without owning the manifest. The artifact has to be produced by production runs and reachable by CI. Teams set this up, then a production job fails for a week and CI silently compares against a stale manifest.

Buying Cloud to fix project structure. A hosted IDE does not fix a project with 400 models in one folder and no staging layer. That is a project structure problem, and it follows you to any platform.

Assuming Cloud manages warehouse cost. It runs your SQL. Your credits are still decided by materializations, threads, and model design — see dbt performance at scale.

Letting the IDE become the only environment. If nobody on the team can run dbt locally, your debugging options during an incident narrow to whatever the browser shows you.

Ignoring seat creep. Occasional contributors accumulate. Review seat count against actual commit activity every quarter.

FAQ

Is dbt Core going away or getting worse? Core is the engine both products use, and the ecosystem depends on it. That said, some newer capabilities land in the hosted product first — check where the specific feature you need lives before building a plan around it.

Can I self-host something that looks like Cloud? Partly. There are open-source docs hosts and orchestrator integrations, and Dagster’s dbt support gives you lineage in a UI. Nobody has replicated the browser IDE for analysts, which is the piece that is genuinely hard to rebuild.

How do I run dbt Core in Airflow properly? Not with a single BashOperator running dbt build for the whole project — one failure and you re-run everything. Either split by selector into meaningful task groups, or use a library that expands the dbt graph into Airflow tasks so retries are per model.

Does Cloud lock me in? Not at the project level. Your models are files in your repo. What you would rebuild on exit is scheduling, CI, and docs hosting — a project measured in days, not quarters.

What about SQLMesh instead? Worth evaluating for greenfield work, particularly the virtual environment and plan model. It is not a reason to migrate a healthy dbt estate, which I argued in SQLMesh plans and virtual environments.

What this means for data engineers

Decide by who writes models and who owns the orchestrator. If analysts across the business contribute and you have no platform engineer to spare, Cloud buys you a working environment immediately and that is a legitimate purchase. If your contributors are engineers and Airflow or Dagster already owns the pipeline graph, Core inside that orchestrator is both cheaper and architecturally cleaner, because ingestion, transformation, and everything downstream sit in one dependency graph instead of two calendars.

Whichever you pick, one system owns the graph. That single rule prevents more incidents than the choice itself. The dbt commands sheet and dbt best practices apply identically on both.