dbt Core vs dbt Cloud: What Is Actually Different

dbt Core and dbt Cloud run the same transformation engine under the hood. The SQL models, YAML configurations, ref() calls, and DAG logic work identically in both. What differs is the operational layer around them — how you run jobs, collaborate with teammates, manage credentials, and monitor pipeline health.

Choosing between them is mostly a question of team size, budget, and how much infrastructure you want to manage yourself.

What dbt Core Is

dbt Core is the open-source project. It is a Python package that you install and run from the command line. Your models, configurations, and compiled SQL all live on your local machine or in a CI/CD environment you set up.

pip install dbt-snowflake

dbt init my_project
dbt run
dbt test
dbt docs generate

Everything dbt does — compiling models, running SQL against your warehouse, generating documentation — is available in dbt Core for free. The project is Apache 2.0 licensed and actively maintained on GitHub.

The things you have to handle yourself with dbt Core:

• Scheduling runs (via cron, Airflow, Prefect, Dagster, or another orchestrator)
• Managing credentials securely (environment variables, secrets managers)
• Hosting documentation (somewhere your team can access it)
• Monitoring and alerting (custom tooling or your orchestrator’s UI)
• CI/CD pipeline setup for pull request validation

What dbt Cloud Is

dbt Cloud is a managed platform from dbt Labs. It hosts the dbt runtime, provides a browser-based IDE, built-in job scheduling, credential management, and a documentation portal. You do not install anything locally — you log in at cloud.getdbt.com and work from there.

The core dbt engine is identical to dbt Core. The difference is that dbt Cloud wraps that engine with managed infrastructure and tooling that many teams would otherwise have to build themselves.

dbt Cloud pricing in 2025 has three tiers:

• Developer — free for a single developer, includes the IDE and basic scheduling
• Team — paid, adds multi-user access, seat-based pricing, SSO
• Enterprise — custom pricing, adds private deployments, advanced RBAC, audit logs

Feature-by-Feature Comparison

Running dbt Core in CI/CD

dbt Core fits naturally into GitHub Actions, GitLab CI, or any other CI/CD pipeline. A common pattern validates model changes on pull request open:

name: dbt CI

on:
  pull_request:
    branches: [main]

jobs:
  dbt_run:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'

      - name: Install dbt
        run: pip install dbt-snowflake

      - name: Run dbt in dev
        env:
          DBT_SNOWFLAKE_ACCOUNT: ${{ secrets.SNOWFLAKE_ACCOUNT }}
          DBT_SNOWFLAKE_PASSWORD: ${{ secrets.SNOWFLAKE_PASSWORD }}
        run: |
          dbt deps
          dbt build --target dev --select state:modified+

The state:modified+ selector runs only models that changed in this PR plus their downstream dependents. This keeps CI costs low and runs fast even on large projects.

dbt Cloud’s Slim CI

dbt Cloud offers a similar capability out of the box called Slim CI. When you open a pull request, dbt Cloud automatically:

1. Clones your repo at the PR branch
2. Compares the current state to the last successful production run
3. Runs only the models that changed and their downstream dependencies
4. Posts a comment on the PR with pass/fail results

Setting this up in dbt Cloud takes a few minutes in the UI. Setting up the equivalent in dbt Core with GitHub Actions takes maybe 30 minutes of workflow YAML but gives you more control over exactly what runs.

The dbt Cloud IDE

The dbt Cloud browser IDE is the biggest quality-of-life difference for developers who are not already set up with a strong local environment. It provides:

• Syntax highlighting and autocomplete for SQL and YAML
• A file tree for your project
• A lineage panel that updates as you write ref() calls
• A preview pane to run queries against your warehouse without building the model
• Integrated dbt CLI commands (run, test, compile) from the browser

For teams where not everyone is comfortable setting up a local Python environment, the Cloud IDE lowers the barrier to writing and testing dbt models significantly.

Semantic Layer Differences

The dbt Semantic Layer (powered by MetricFlow) is available in both, but with important differences.

In dbt Core, you can define semantic models and metrics in YAML, validate them with mf validate-configs, and query them with the mf query CLI. This is fully functional for local development.

In dbt Cloud, you additionally get:

• The Semantic Layer API endpoint that BI tools (Tableau, Hex, Mode, Thoughtspot) can connect to directly
• Saved query exports that materialize metric combinations as tables
• Usage analytics showing which metrics are being queried and by whom

If your reason for using the Semantic Layer is to give BI tools consistent metric access, you need dbt Cloud — the API for external tool connections is only available there.

dbt Explorer vs dbt Docs

Both Core and Cloud let you generate and view lineage documentation. The experience differs.

dbt docs generate && dbt docs serve in dbt Core creates a static HTML site with a lineage graph. It is useful and shows everything, but it requires you to re-run dbt docs generate to update it, and you have to host it yourself if you want teammates to access it.

dbt Explorer in dbt Cloud is a live view that updates automatically after every run. It shows:

• Full project lineage with source and exposure nodes
• Column-level lineage tracing specific fields through the DAG
• Run history and health status per model
• Recommendations for models with no tests or documentation

For teams with more than a handful of models, Explorer is substantially more useful than the static docs site.

Which to Choose

Use dbt Core if:

• You are learning dbt and exploring on your own
• You already have Airflow, Prefect, or Dagster handling orchestration
• Your team is technical and comfortable managing CI/CD pipelines
• Budget is a constraint and the free features cover your needs
• You want maximum control over how dbt integrates with your stack

Use dbt Cloud if:

• You have multiple analysts or engineers collaborating on the same project
• You want scheduling and monitoring without building that infrastructure yourself
• Your analysts are not comfortable with the command line
• You need BI tools to connect to the Semantic Layer API
• The time saved on infrastructure setup is worth the subscription cost

Use both together if:

• Developers build and test locally with dbt Core
• dbt Cloud runs production jobs, hosts documentation, and provides the Semantic Layer API
• Pull requests trigger Slim CI in dbt Cloud for automated testing

This hybrid pattern is extremely common in 2025. dbt Core gives developers a fast local iteration cycle, while dbt Cloud handles the production operational concerns without additional infrastructure work.

Credential Management

One practical difference worth calling out: how each approach handles database credentials.

In dbt Core, credentials go in profiles.yml (usually at ~/.dbt/profiles.yml). Sensitive values should be read from environment variables:

my_profile:
  target: dev
  outputs:
    dev:
      type: snowflake
      account: "{{ env_var('SNOWFLAKE_ACCOUNT') }}"
      user: "{{ env_var('SNOWFLAKE_USER') }}"
      password: "{{ env_var('SNOWFLAKE_PASSWORD') }}"
      database: analytics
      schema: dbt_dev
      warehouse: transforming

In dbt Cloud, you enter credentials in the UI. They are stored encrypted and never exposed in code or config files. This is simpler and avoids the common mistake of accidentally committing profiles.yml with real passwords to a git repository.

Summary

dbt Core and dbt Cloud solve the same transformation problem with the same engine. The question is how much of the surrounding infrastructure you want to own. dbt Core gives you complete control and costs nothing. dbt Cloud removes operational burden and adds collaboration features, at a cost that scales with team size.

Most mature data teams end up using dbt Core locally and dbt Cloud for production — getting the flexibility of local development with the operational reliability of a managed platform.