dbt Cloud vs dbt Core — A Comparison

dbt Core is a free, open-source command-line tool. dbt Cloud is a hosted platform built around dbt Core that adds scheduling, a web IDE, hosted documentation, and team-oriented features. The underlying dbt run / dbt test execution engine is the same either way — the SQL you write does not change based on which one you pick.

What dbt Core actually gives you

dbt Core is a Python CLI you install with pip install dbt-core dbt-snowflake (or whatever adapter matches your warehouse). You write models, run dbt run, dbt test, and dbt build from your terminal or CI pipeline, and you are responsible for wiring up orchestration yourself — cron, Airflow, Dagster, GitHub Actions, whatever already runs in your stack. There is no bundled scheduler, no hosted web IDE, no managed docs site — you generate and serve `dbt docs` yourself if you want one.

name: dbt-nightly
on:
  schedule:
    - cron: '0 4 * * *'
jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install dbt-snowflake
      - run: dbt deps
      - run: dbt build --target prod
        env:
          SNOWFLAKE_PASSWORD: ${{ secrets.SNOWFLAKE_PASSWORD }}

What dbt Cloud adds on top

dbt Cloud wraps the same engine with a managed scheduler (no separate Airflow deployment needed), a browser-based IDE for writing and previewing models, automatically hosted documentation and a lineage graph UI, built-in CI that runs on pull requests against a temporary schema, and role-based access control for larger teams. The tradeoff is cost — dbt Cloud is priced per seat and starts to matter once you have more than a couple of developers — and a degree of platform lock-in around its job scheduling model.

The decision that actually matters: do you already run an orchestrator?

If your company already runs Airflow or Dagster for other pipelines, dbt Core slots in as one more task in an existing DAG, and paying for dbt Cloud's scheduler duplicates infrastructure you already maintain. If you have no orchestrator and do not want to stand one up, dbt Cloud's built-in scheduling is a legitimate reason to pay for it — building a reliable scheduler from scratch is more work than it looks like.

CLI commands work identically either way

Whether you run dbt Core locally or inside dbt Cloud's IDE, the commands are the same:

dbt run --select stg_orders+     # run this model and downstream
dbt test --select tag:critical   # run only tests tagged critical
dbt build                        # run + test in dependency order
dbt docs generate && dbt docs serve

Wrapping up

Pick dbt Core if you already have an orchestrator and engineers comfortable with CI — you keep full control and pay nothing beyond compute. Pick dbt Cloud if scheduling, hosted docs, and a lower ops burden are worth the per-seat cost, especially for a team without existing pipeline infrastructure. The SQL and the ref()/source() model underneath is identical either way, so switching later is not a rewrite.