dbt Cloud is the managed deployment platform for dbt (data build tool), adding orchestration, a web IDE, documentation hosting, job scheduling, and collaboration features to the open-source dbt Core framework. This guide explains what dbt Cloud provides, how it compares to self-hosted dbt, and when each is appropriate.
dbt Cloud is the managed deployment platform for dbt (data build tool) developed by dbt Labs. It adds orchestration, a browser-based IDE, documentation hosting, job scheduling, CI/CD integration, and team collaboration features to the open-source dbt Core framework. dbt Cloud is one of two ways to run dbt in production — the other being dbt Core self-hosted, managed by the data team's own infrastructure.
What dbt Core Provides (and What It Does Not)
dbt Core is the open-source transformation framework. It allows data engineers and analytics engineers to write SQL models, define tests, build documentation, and execute transformations against a data warehouse. Running dbt Core locally requires the dbt CLI and a profiles configuration.
What dbt Core does not include:
- A scheduler or orchestrator — you need Airflow, Prefect, Dagster, or a similar tool
- A web IDE — development happens in local text editors and terminals
- Hosted documentation — dbt docs generate runs locally; hosting the output requires additional setup
- CI/CD integration — triggered runs on pull requests require external tooling
- Access controls and user management — anyone with CLI access can run any command
- Usage analytics — no built-in visibility into who ran what, when, and what the outcome was
dbt Cloud provides all of these.
Core Features of dbt Cloud
### Orchestration and Job Scheduling
dbt Cloud's scheduler runs dbt jobs on a cron schedule or triggered by external events. A production job might run on a schedule, refreshing all models, running all tests, and failing the job if any test fails. Job run history, logs, and model timing are all visible in the UI.
Compared to running dbt in Airflow: dbt Cloud's scheduler is simpler to configure and purpose-built for dbt. Airflow is more flexible for complex multi-system pipelines. Organizations with complex orchestration requirements often run dbt within Airflow or Dagster even when they use dbt Cloud for the IDE and CI features.
### Browser-Based IDE
dbt Cloud's IDE allows analytics engineers to write, test, and preview dbt models in a browser without installing anything locally. The IDE includes:
- A file tree editor for models, tests, sources, and macros
- Query preview against the connected warehouse
- dbt command terminal
- Git integration (commit, push, pull request creation from the IDE)
- Lineage graph visualization for the current file
The IDE is particularly valuable for organizations where the analytics engineering team is not comfortable with local development tooling, or where IT policies make local database connections difficult.
### Documentation Hosting
dbt generates a documentation site from model descriptions, column descriptions, and test definitions — a browsable catalog of every model, its columns, its business purpose, its lineage, and its test coverage. In dbt Core, generating this documentation requires running a local server or deploying the static output manually.
dbt Cloud hosts this documentation automatically and keeps it current with every job run. Stakeholders can browse to the documentation URL to see the current state of the data model without involving the data engineering team.
### CI/CD Integration
dbt Cloud integrates with GitHub, GitLab, and Azure DevOps to run "slim CI" jobs on pull requests — running only the models and tests affected by the pull request changes, rather than the full project. This provides fast feedback on whether a proposed change breaks any downstream models or tests before it is merged.
Slim CI uses dbt's state comparison feature to identify what changed and test only the affected model subgraph, making CI runs fast even for large dbt projects with hundreds of models.
### Environments and Access Controls
dbt Cloud supports multiple environments (development, staging, production) with different credential sets and configuration. Developers run models against a personal development schema; CI runs against a staging schema; production jobs run against production. This separation prevents development experiments from corrupting production data.
Role-based access controls (available on higher tiers) allow administrators to restrict who can trigger production jobs, who can modify production credentials, and who has read-only access to the UI.
dbt Cloud vs. dbt Core Self-Hosted
The decision between dbt Cloud and self-hosting dbt Core depends on several factors:
Choose dbt Cloud when:
- The team wants to minimize infrastructure management — no Airflow cluster, no scheduler, no documentation hosting to maintain
- The IDE is valuable for team members who are not comfortable with local development
- CI/CD integration on pull requests is important and the team does not already have it
- The organization's security policy permits SaaS tools with cloud credential access
Choose dbt Core self-hosted when:
- The organization already has Airflow, Prefect, or Dagster and wants to orchestrate dbt within the existing pipeline system
- Security or compliance requirements prohibit sending warehouse credentials to a SaaS platform
- Cost at scale makes dbt Cloud's pricing prohibitive
- The team requires dbt capabilities not yet available in dbt Cloud (some advanced features arrive in Core before Cloud)
**Common hybrid:** Many teams use dbt Cloud for the IDE (developers work in the browser IDE) but orchestrate dbt runs via Airflow in production. This separates the development experience from the production orchestration, using each tool for what it does best.
dbt Cloud Pricing
dbt Cloud pricing (as of 2025) has three tiers:
**Developer** — free for a single developer. Single project, single environment, community support. Useful for learning and individual use.
**Team** — per-seat pricing, multiple projects and environments, CI/CD integration, documentation hosting, standard support.
**Enterprise** — custom pricing, SSO/SAML, IP allowlisting, SLA-backed support, advanced role-based access controls, dedicated infrastructure options.
The main cost consideration for growing data teams is that per-seat pricing scales with headcount. For large teams, self-hosting dbt Core may be more economical — though the engineering investment in building and maintaining the equivalent infrastructure should be included in the comparison.
dbt Cloud in the Modern Data Stack
dbt Cloud fits naturally into the modern data stack: ingestion tools (Fivetran, Airbyte) load raw data into the warehouse; dbt Cloud transforms it via SQL models; the semantic layer (dbt Metrics, Cube.dev) defines business metrics; BI tools (Tableau, Looker) query the semantic layer.
Our data architecture practice implements dbt Cloud and dbt Core deployments for clients building analytics-engineering-led data stacks. Contact us to discuss your transformation layer architecture.
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 →