dbt Cloud vs dbt Core

Analogy categoryAnalogies

dbt Core and dbt Cloud execute the exact same open-source engine — the same Jinja-templated SQL compiles to the same warehouse-native statements and the same DAG resolution logic runs models in dependency order. The difference is entirely in what surrounds that engine: dbt Core is a pip-installable CLI you run from your own terminal, CI runner, or orchestrator, while dbt Cloud is a hosted SaaS product from dbt Labs that wraps the same core with a browser IDE, a managed scheduler, hosted documentation, and an admin API. Choosing between them is an infrastructure decision, not a modeling-language decision.

🏏

Cricket analogy: It's like choosing to practice in your own backyard net you set up and maintain versus joining the National Cricket Academy in Bengaluru, where the same batting technique is taught but the nets, bowling machines, and physios are provided for you.

What dbt Core Requires You to Manage

Running dbt Core means you own the entire operational surface: you install dbt-core and the relevant adapter (dbt-snowflake, dbt-bigquery, etc.) into a Python environment, you write and maintain profiles.yml for warehouse credentials, and you are responsible for scheduling dbt run and dbt test somewhere — cron, Airflow, Dagster, GitHub Actions, or a container orchestrator. There is no built-in web UI, no hosted docs site unless you deploy dbt docs generate output yourself (e.g., to S3 or GitHub Pages), and no managed run history; every operational concern that dbt Cloud automates becomes your team's responsibility, in exchange for zero licensing cost and full control over the execution environment.

🏏

Cricket analogy: It's like a franchise team that scouts, trains, and manages its own players entirely in-house rather than outsourcing to an academy — Chennai Super Kings running their own fitness camps rather than sending players to a third party for conditioning.

What dbt Cloud Adds

dbt Cloud layers a managed job scheduler, a browser-based IDE with an integrated git workflow, hosted and auto-refreshed documentation, run history with logs and artifacts retained per job, and role-based access control on top of the identical dbt Core engine. It also exposes a Discovery API and Admin API for programmatic access to run metadata, and its Cloud CLI (dbt Cloud CLI) lets developers run commands locally that execute against dbt Cloud's remote compute rather than a local Python environment, which is useful for large warehouses where local compilation and execution would be slow. The tradeoff is a subscription cost and less flexibility to customize the orchestration layer compared to self-hosting.

🏏

Cricket analogy: It's like the BCCI providing centralized video review, umpiring review systems, and a dedicated broadcast infrastructure around a match — the cricket itself is the same, but the surrounding operational layer is fully managed.

yaml

# profiles.yml required only for dbt Core (self-managed connection config)
my_dbt_project:
  target: dev
  outputs:
    dev:
      type: snowflake
      account: xy12345.us-east-1
      user: "{{ env_var('DBT_USER') }}"
      password: "{{ env_var('DBT_PASSWORD') }}"
      role: transformer
      database: analytics
      warehouse: transforming_wh
      schema: dbt_dev
      threads: 4

# dbt Cloud instead stores this connection config in the web UI per project/environment,
# and developers authenticate via the browser IDE or the dbt Cloud CLI without a local profiles.yml

dbt Cloud has a free Developer plan limited to a single seat with no scheduled jobs, useful for evaluation but not production orchestration. Production use of dbt Cloud's scheduler requires a paid Team or Enterprise plan; dbt Core remains fully free at any scale, provided you supply your own orchestration.

dbt Core and dbt Cloud run the identical open-source transformation engine and DAG logic.
dbt Core is a self-hosted CLI you install with pip; you must supply your own scheduler, credential storage, and docs hosting.
dbt Cloud is a managed SaaS layer adding a browser IDE, scheduler, hosted docs, run history, and RBAC.
dbt Cloud's Discovery API and Admin API expose run metadata programmatically; the Cloud CLI runs commands against remote compute.
dbt Core has zero licensing cost but higher operational burden; dbt Cloud reduces operational burden at a subscription cost.
profiles.yml is only needed for dbt Core; dbt Cloud stores connection configuration in its own project/environment settings.
The choice is an infrastructure decision — it does not change how models, tests, or macros are written.