dbt Cloud vs dbt Core: How to Choose (and What the Analytics Engineer Exam Asks)

The modeling fundamentals (ref, tests, macros, snapshots, docs, artifacts) are identical either way, but the operations and collaboration experience differs dramatically.

This article walks through dbt Cloud vs dbt Core from the angles the exam tends to ask about, grounded in the stable official specs, and gives you the checkpoints you need to make a quick selection decision on the job.

Foundations: Where Cloud and Core Sit

dbt Core is an open-source CLI runtime. It compiles your models and dispatches SQL to a data warehouse (Snowflake, BigQuery, Databricks, Redshift, Postgres, etc.) via adapters. It does not include a scheduler, web UI, or RBAC.

dbt Cloud is the managed SaaS: web IDE, job scheduler, run logs, notifications, auth and RBAC, metadata visualization, and PR checks. In both cases the actual compute happens in the warehouse, and the SQL behaves the same.

• Cloud bundles the team development and operations plumbing as a managed service
• Core gives you maximum flexibility; you build CI/CD and scheduling yourself
• Artifacts (manifest.json, etc.) follow the same spec in both

Core connection definition (profiles.yml example: Snowflake)

my_project:
  target: dev
  outputs:
    dev:
      type: snowflake
      account: '{{ env_var('SNOWFLAKE_ACCOUNT') }}'
      user: '{{ env_var('SNOWFLAKE_USER') }}'
      password: '{{ env_var('SNOWFLAKE_PASSWORD') }}'
      role: ANALYST
      database: ANALYTICS
      warehouse: TRANSFORMING
      schema: dev_{{ env_var('USER') }}
      threads: 8
      client_session_keep_alive: true

Execution and Orchestration Design

Cloud bundles job definitions and the scheduler, letting you set execution parameters, schedules, notifications, retries, and concurrency per environment (Development / Deployment). PR-based checks and incremental runs based on the previous artifacts (Slim CI) are also straightforward to configure.

Core has no scheduler, so teams reach for Airflow, Dagster, GitHub Actions, GitLab CI, Azure Pipelines, or cron. The standard pattern is to design incremental runs using state:modified+ together with artifacts (manifest.json, run_results.json).

• Want batch execution, notifications, and retries up fast → Cloud
• Need to plug into an existing orchestrator or want fine-grained dependency control → Core
• Slim CI works in both. With Core you supply the artifact storage yourself

Execution path (Core)

Execution path (Cloud)

Slim CI on Core (minimal GitHub Actions example)

name: dbt Core 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-snowflake
      - name: Restore previous artifacts
        run: |
          mkdir -p ci_state
          # Example: fetch the previous manifest.json from artifacts or storage into ci_state/
      - run: dbt deps
      - run: dbt build --select state:modified+ --state ci_state --profiles-dir . --target dev

Developer Experience and Collaboration

Cloud's web IDE covers connection setup, branch operations, model execution, log inspection, and documentation browsing from the browser. New members onboard quickly, and reviews are highly reproducible.

Core combines a local IDE (VS Code, etc.) with the CLI. The flexibility is great, but you need to design ops that smooth over Python and dependency versions, warehouse network access, secrets, and data sample handling.

• dbt docs generate emits static docs. Cloud includes hosting; with Core you host them yourself
• Build a culture of running models/tests partially on PR checks to make reviews more efficient
• Keep artifacts in version control or persistent storage to make incremental runs reliable

Generate docs and view locally (Core)

dbt docs generate --target dev
# Start a local server temporarily
dbt docs serve --port 8080

Security, Permissions, and Auditing

Cloud provides governance features such as SSO/SAML, RBAC, service tokens, and audit logs (availability depends on your plan). Connection info is isolated per environment and safely managed.

With Core you fill these gaps using surrounding infrastructure. Secrets are typically passed in via environment variables and managed in a cloud secrets manager or Vault. Permission control happens through warehouse role design and the orchestrator's execution permissions.

• On the exam, the rule of thumb "need organizational RBAC/SSO/audit → Cloud" comes up often
• When running Core, separate least-privilege warehouse roles from execution service accounts
• Standardize connection info on env_var references and keep secrets out of the repo

Safe connection via environment variables (profiles.yml excerpt)

outputs:
  prod:
    type: snowflake
    account: '{{ env_var('SNOWFLAKE_ACCOUNT') }}'
    user: '{{ env_var('SNOWFLAKE_USER') }}'
    password: '{{ env_var('SNOWFLAKE_PASSWORD') }}'
    role: '{{ env_var('SNOWFLAKE_ROLE', 'TRANSFORMER') }}'
    database: '{{ env_var('SNOWFLAKE_DB') }}'
    warehouse: '{{ env_var('SNOWFLAKE_WH') }}'
    schema: analytics

Cost, Operations, and Scalability Trade-offs

Cloud incurs a subscription fee but dramatically reduces ops load thanks to the scheduler, IDE, logs/notifications, and UI-based management. For small to mid-sized teams or organizations with strong governance requirements, TCO often comes out lower.

Core itself is free, but you design and maintain scheduling, monitoring, permissions, log retention, documentation publishing, and metadata visualization yourself. It fits organizations with a mature platform or those that need deep customization.

• Fast time-to-value and small ops headcount → Cloud
• Integrate with existing CI/CD and standardize ops → Core
• Both compute in the warehouse. Warehouse cost design (size, auto-resume, credit caps) matters either way

Install adapters with pinned versions (Snowflake / Databricks example)

pip install 'dbt-snowflake==1.8.*'
pip install 'dbt-databricks==1.8.*'
# Use requirements.txt / a lock file for reproducibility

Exam Essentials and a Selection Framework

On the Analytics Engineer exam, beyond the core dbt concepts, questions frequently come from the ops and collaboration angle of Cloud vs Core. Being able to instantly recall where Slim CI, environment separation, permissions, docs/lineage, and scheduling live translates directly into points.

In the field, selection is requirement-driven. Pick Cloud if you prioritize RBAC/SSO, audit, built-in scheduler, and fastest time-to-stand-up. Pick Core if you prioritize integration with an existing orchestrator, fine-grained dependency control, and strict adherence to infrastructure standards. In either case, artifact and state management design is the key to success.

• Instant-recall points: Cloud = scheduler / IDE / RBAC / Lineage UI, Core = OSS CLI / DIY orchestration
• Slim CI = incremental runs using state:modified+ and the previous artifacts (works in both Cloud and Core)
• Both execute SQL in the warehouse. Performance depends on warehouse design and model granularity

Selection checklist (excerpt)

[ ] SSO/RBAC/audit are mandatory -> yes: Cloud is favoured / no: Core is also viable
[ ] You want it inside your existing orchestrator -> yes: Core / no: Cloud saves build effort
[ ] Per-PR incremental runs needed -> both work (compare on ease of state management)
[ ] You want docs/lineage visible immediately -> Cloud wins / Core means self-hosting
[ ] Budget and operating capacity -> estimate TCO (headcount + SaaS + warehouse)

Check with a Question

Frequently Asked Questions