A direct comparison of dbt Cloud and dbt Core across orchestration, development environment, CI/CD, the Semantic Layer, team size fit, and cost — with guidance on the inflection points where Cloud creates enough value to justify the spend.
dbt Core is the open-source command-line tool that runs dbt transformations. dbt Cloud is the SaaS product built on top of it. The distinction matters for teams deciding where to invest: every feature in dbt Core is free; dbt Cloud adds managed orchestration, a development IDE, CI/CD integration, the Semantic Layer, and team collaboration features at a monthly cost per developer seat.
This is not a feature comparison for its own sake. It is a framework for answering: at what team size and use case does dbt Cloud's value justify its cost?
What dbt Core Gives You
dbt Core is the dbt transformation engine. You get:
- The full dbt transformation framework: models, tests, snapshots, seeds, analyses, macros, packages
- All adapters (Snowflake, BigQuery, Redshift, Databricks, Postgres, and 30+ others)
- Command-line execution: dbt run, dbt test, dbt build, dbt docs generate
- Everything required to build, test, and document a production dbt project
What dbt Core does not include: a web IDE, a managed scheduler, CI/CD integration, a hosted documentation server, the Semantic Layer, or team collaboration features. You bring your own orchestration (Airflow, Dagster, Prefect, cron), your own CI/CD (GitHub Actions, GitLab CI), your own development environment (local machine, VS Code), and your own documentation hosting.
For a solo analyst or a small team with an existing orchestration platform, dbt Core with GitHub Actions CI and Airflow scheduling handles most production requirements.
What dbt Cloud Adds
**dbt Cloud IDE:** A browser-based development environment with syntax highlighting, autocomplete, lineage graph exploration, integrated test runs, and a query console. The alternative is VS Code with the dbt Power User extension and a local CLI setup. For teams where developers do not want to manage local Python environments, the Cloud IDE removes setup friction.
**Job scheduling:** dbt Cloud runs jobs on a schedule or via API trigger. You define jobs (dbt build --select ...), set a schedule (cron or interval), and dbt Cloud executes and reports results. The alternative is running dbt from Airflow, Dagster, or Prefect — which all support dbt natively and are more capable orchestrators for complex pipeline dependencies.
**CI/CD integration:** dbt Cloud's CI feature runs dbt in a slim_ci mode on pull requests — running only modified models and their downstream dependents against a temporary schema. This is genuinely valuable for large projects where running the full project on every PR takes 30+ minutes. The alternative is implementing this yourself in GitHub Actions with dbt's --select state:modified+ syntax.
**Hosted documentation:** dbt Cloud serves dbt docs (the lineage graph and column documentation) as a hosted website. The alternative is generating docs with dbt docs generate and deploying the static site to GitHub Pages, Netlify, or S3.
**dbt Semantic Layer:** The dbt Cloud Semantic Layer (powered by MetricFlow) allows defining business metrics in dbt YAML and querying them via a consistent SQL interface from connected BI tools (Tableau, Looker, Hex, Lightdash). This is a dbt Cloud-exclusive feature — it is not available in dbt Core. For organisations that want a dbt-managed semantic layer with BI tool integration, this is a significant differentiator.
**Explorer:** The dbt Cloud Explorer provides a visual interface for browsing the dbt project structure, exploring lineage, and searching across models, tests, and documentation. Useful for organisations with large projects (100+ models) where navigating via CLI is cumbersome.
Team Size and Use Case Fit
**Solo analyst or two-person team with existing orchestration:** dbt Core. You have the technical ability to manage local environments, you already use Airflow or GitHub Actions, and the dbt Cloud monthly cost ($50–100/month per developer seat on Team plan) is not justified by the convenience features.
**Small team (3–8 people) without existing orchestration:** Consider dbt Cloud. The managed scheduler eliminates the need to set up and maintain Airflow or a similar orchestrator. The Cloud IDE reduces onboarding time for new team members. The CI feature helps as the project grows. At 5 developers, the Team plan cost is $250–500/month — reasonable if it replaces the engineering time to set up and maintain orchestration infrastructure.
**Team using the Semantic Layer:** dbt Cloud. The MetricFlow-powered Semantic Layer is only available in dbt Cloud (or as a standalone self-hosted deployment that is not officially supported). If your BI strategy depends on dbt-managed metrics with consistent definitions across tools, dbt Cloud is required.
**Team with large dbt projects (100+ models) and frequent contributor PRs:** dbt Cloud CI provides measurable value here. The slim_ci mode reduces CI run time from 30+ minutes to 2–5 minutes for typical PRs. For teams where slow CI is a bottleneck, this justifies the cost.
**Team already invested in Airflow or Dagster:** dbt Core. Both Airflow (with the dbt-airflow provider) and Dagster (with dagster-dbt) have excellent dbt integrations. The dbt Cloud scheduler offers less flexibility than a full-featured orchestrator for complex pipeline dependencies. Keep your orchestrator and use dbt Core.
Pricing Summary
dbt Cloud pricing (as of 2025):
- Developer plan: Free, 1 developer, limited features, no team collaboration
- Team plan: $50/developer/month, full feature set except Enterprise features, 15k model runs/month
- Enterprise: Custom pricing, SSO, audit logs, advanced security, higher run limits
For a 5-person analytics engineering team on the Team plan: $3,000/year. Compare to the engineering time to build and maintain equivalent Airflow + GitHub Actions + documentation hosting + CI infrastructure. For most teams, the break-even is 3–5 days of engineering time per year — easily reached in initial setup alone.
The Semantic Layer creates a harder lock-in consideration: once your BI tools depend on the dbt Semantic Layer, switching to dbt Core requires rebuilding the semantic layer elsewhere. Evaluate this dependency before committing.
The Practical Decision
Use dbt Core if: you have strong DevOps capability, an existing orchestration platform, and the team size and use case do not justify managed services.
Use dbt Cloud if: you lack an orchestration platform and do not want to build one, you need the Semantic Layer, you have a large team where the Cloud IDE and CI features reduce friction, or you want to invest engineering time in transformations rather than dbt infrastructure.
Our data engineering consulting practice helps teams design their dbt architecture and select the right deployment model for their context — contact us to discuss your dbt environment.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →