Use dbt Core if your team already runs Airflow, Dagster, or another orchestrator and you're comfortable managing CI/CD yourself. Use dbt Cloud if you want scheduling, a browser IDE, docs hosting, and the semantic layer API in one managed product. Core is free; Cloud starts at $100/seat/month and adds up fast.
That's the short answer. The longer one involves your team size, your existing infra, and whether "managed" actually saves you time or just moves the complexity somewhere harder to debug.
Where does dbt fit in the stack?
Before comparing Core and Cloud, it helps to see what dbt actually replaces. Here's a typical modern data stack:
┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐
│ Sources │ │ Ingestion │ │ Warehouse │ │ dbt │ │ BI / │
│ │───→│ │───→│ │───→│ │───→│ Analytics │
│ Postgres │ │ Fivetran │ │ Snowflake │ │ Models + │ │ Dashboards │
│ Stripe API │ │ Airbyte │ │ BigQuery │ │ Tests + │ │ AI agents │
│ Salesforce │ │ Stitch │ │ Redshift │ │ Docs │ │ Notebooks │
└────────────┘ └────────────┘ └────────────┘ └────────────┘ └────────────┘dbt owns the "T" in ELT. It reads raw data from your warehouse, transforms it with SQL (or Python), tests it, documents it, and writes the results back. It doesn't move data in or out of the warehouse. It doesn't serve dashboards. It transforms what's already there.
Core and Cloud are two ways to run the same transformation engine. The engine is identical. Everything around it differs.
What do you actually get with dbt Core?
dbt Core is the open-source CLI. You install it with pip install dbt-core, write models in SQL, and run dbt build from your terminal. That's it.
What Core gives you: the full transformation engine, Jinja templating, ref() and source() resolution, testing (not_null, unique, custom), snapshot support, incremental models, and packages from dbt Hub. All the modeling power. None of the operational wrapper.
What Core does NOT give you: a scheduler, a browser IDE, hosted documentation, CI/CD, the semantic layer API, or job alerting. You bring all of that yourself.
A typical dbt Core deployment looks like this:
┌──────────────────────────────────────────────────────────────────┐
│ Your infrastructure │
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ Airflow / │ │ GitHub │ │ dbt docs │ │
│ │ Dagster │───→│ Actions │ │ on S3 / │ │
│ │ (schedule)│ │ (CI/CD) │ │ Netlify │ │
│ └───────────┘ └─────┬─────┘ └───────────┘ │
│ │ │
│ ┌────▼────┐ │
│ │ dbt Core│ │
│ │ (CLI) │ │
│ └────┬────┘ │
│ │ │
│ ┌────▼─────────┐ │
│ │ Warehouse │ │
│ └──────────────┘ │
└──────────────────────────────────────────────────────────────────┘You own every box except the warehouse. That's the trade-off: full control, full responsibility.
Fastero
Connect your database. Ask questions. Get dashboards.
Postgres, BigQuery, Snowflake, and 10+ sources — live-connected, AI-powered, no dashboard builder learning curve.
Try free →What does dbt Cloud add on top?
dbt Cloud wraps Core's engine in a managed platform. Same SQL, same ref(), same models. But the surrounding infrastructure is handled for you.
The meaningful additions: a browser-based IDE with autocomplete and preview, job scheduling with cron or event triggers, CI on pull requests (run models against a PR branch before merging), hosted docs with search and column-level lineage (Explorer), the dbt Semantic Layer API (MetricFlow), and job failure alerting to Slack/email.
Pricing as of mid-2026: Team plan at $100/seat/month (minimum 8 seats, so $800/month floor). Enterprise plan is custom-quoted and higher. The free Developer plan is single-user only — fine for personal projects, not for teams.
For a 10-person data team, Cloud costs $12,000/year minimum. A 25-person team hits $30,000/year. That adds up, and it's per-seat regardless of whether someone runs 50 models a day or checks a dashboard once a month.
How do they compare head-to-head?
| dbt Core | dbt Cloud | |
|---|---|---|
| Cost | Free (OSS) | $100/seat/mo (Team), custom (Enterprise) |
| IDE | VS Code + dbt Power User extension | Browser IDE with preview, autocomplete, lineage |
| Scheduling | BYO (Airflow, Dagster, cron, GitHub Actions) | Built-in scheduler with cron + event triggers |
| CI/CD | BYO (GitHub Actions, GitLab CI, etc.) | Slim CI: auto-runs modified models on PRs |
| Documentation | dbt docs generate + self-host (S3, Netlify) |
Hosted Explorer with search, column lineage |
| Semantic layer | MetricFlow CLI (local only) | Semantic Layer API (query metrics from any tool) |
| Alerting | BYO (PagerDuty, Slack webhook scripts) | Built-in Slack/email alerts on job failure |
| Version control | Git (any provider) | Git (GitHub, GitLab, ADO) via Cloud IDE |
| Managed infra | You maintain everything | dbt Labs manages compute, scheduling, hosting |
| Vendor lock-in | None | Moderate (IDE, scheduler, CI are Cloud-specific) |
The transformation engine is the same on both sides. Every difference is in the operational wrapper.
Is the dbt Cloud IDE worth it?
Depends on your team. The Cloud IDE is a browser-based SQL editor with model preview, compiled SQL view, lineage visualization, and dbt-aware autocomplete. It's decent. Not great, not bad.
Most experienced analytics engineers I've talked to prefer VS Code with the dbt Power User extension. It's faster, supports multiple windows, has a richer extension ecosystem, and doesn't require a browser tab. The Cloud IDE's main advantage is onboarding — a new hire can start writing models without installing Python, dbt, or configuring profiles.yml locally.
If your team already lives in VS Code, the Cloud IDE alone doesn't justify the subscription.
What about orchestration?
This is where the decision gets real. dbt Core doesn't schedule anything. You run dbt build manually or wire it into an orchestrator.
If you already run Airflow or Dagster, adding dbt is a single operator or asset definition. Dagster's dbt integration is particularly clean — every dbt model becomes a Dagster software-defined asset with automatic lineage. Airflow has a DbtCloudRunJobOperator and a BashOperator for Core. Both work.
If you DON'T have an orchestrator and don't want to run one, dbt Cloud's built-in scheduler is the path of least resistance. It handles cron scheduling, dependency-aware execution, retries, and failure notifications. You skip the entire orchestration problem.
The trend I'm seeing in 2026: teams that adopted dbt Cloud primarily for scheduling are migrating back to Core + Dagster or Airflow. The reasoning is usually cost. A $12k/year dbt Cloud bill on top of a warehouse bill on top of a BI tool bill adds up — and if you already have Dagster running your other pipelines, duplicating the scheduler in dbt Cloud feels redundant.
Teams that adopted Cloud for the full package (IDE + CI + docs + scheduling) tend to stay. The switching cost is higher and the bundle is harder to replicate.
Is the semantic layer Cloud-only?
Partially. MetricFlow — the engine behind dbt's semantic layer — is open source and ships with dbt Core. You can define metrics in YAML and query them locally via mf query. But the Semantic Layer API, which lets external tools query your metrics over JDBC/GraphQL, requires dbt Cloud.
This matters if you want your BI tool, your notebooks, or your AI agent to resolve "revenue" against a governed metric definition. Without the API, those tools can't reach MetricFlow.
The workaround: define metrics in dbt, but serve them through an external semantic layer that imports your dbt definitions. Fastero does this — it imports dbt metric definitions into its own semantic layer, connects to your warehouse (Snowflake, BigQuery, Redshift, Postgres), and lets you query governed metrics through dashboards, SQL, or natural language. No dbt Cloud subscription required.
Who should pick Core?
- Teams with an existing orchestrator (Airflow, Dagster, Prefect) who don't want to pay for a redundant scheduler
- Teams that prefer VS Code over a browser IDE
- Cost-sensitive teams where $100/seat/month across 10+ seats hits the budget
- Shops with strict compliance requirements that prohibit SaaS access to warehouse credentials
- Solo practitioners or small teams (1-3 people) who can handle
dbt buildin a GitHub Action
Who should pick Cloud?
- Teams without an orchestrator who need scheduling out of the box
- Orgs that want CI on dbt PRs without building a custom GitHub Actions pipeline
- Teams where hosted, searchable documentation with column-level lineage matters (large dbt projects, 100+ models)
- Companies that need the Semantic Layer API for external consumption and don't want to run MetricFlow separately
- Mixed-skill teams where non-engineers need the Cloud IDE for SQL authoring
Can you start with Core and move to Cloud later?
Yes, and this is the path I'd recommend for most teams. Your dbt project — models, tests, YAML configs, macros — is identical between Core and Cloud. There's no vendor-specific syntax in your SQL. Moving from Core to Cloud means connecting your repo to dbt Cloud and configuring jobs. Moving from Cloud to Core means setting up your own orchestration and CI. Neither direction requires rewriting models.
The one exception: if you build workflows around Cloud-specific features (the Semantic Layer API, Explorer bookmarks, Cloud CLI), those don't have Core equivalents and you'll need replacements.
FAQ
How much does dbt Cloud actually cost for a typical team? Team plan is $100/seat/month with an 8-seat minimum ($9,600/year). A 15-person data team pays $18,000/year. Enterprise pricing is negotiated and typically higher. dbt Core is free forever — your costs are the engineering time to set up orchestration and CI.
Can I use dbt Core's semantic layer with external tools? Not directly. MetricFlow ships with Core, but the API that external tools query is Cloud-only. You can export metric definitions and import them into a separate semantic layer like Fastero's, which gives you the same governed-metric access without the Cloud subscription.
Is dbt Cloud's CI better than GitHub Actions?
Cloud's "Slim CI" is purpose-built for dbt: it identifies modified models, runs only those (plus downstream), against a temporary schema, and reports results on the PR. Replicating this in GitHub Actions is possible — dbt ls --select state:modified+ does the heavy lifting — but it takes a day of setup and ongoing maintenance. If CI on dbt PRs is important to your workflow, Cloud's version is materially better out of the box.
What's the best orchestrator to pair with dbt Core? Dagster if you're starting fresh — its native dbt integration treats every model as a software-defined asset with lineage tracking. Airflow if you already run it. For event-driven pipelines where models should rebuild when upstream data changes rather than on a schedule, Fastero's workflow engine handles that natively.
Do I lose anything by staying on dbt Core? You lose the Cloud IDE, built-in scheduling, Slim CI, hosted Explorer, the Semantic Layer API, and Cloud-managed job alerting. You keep the full transformation engine, all modeling features, all testing, all packages, and all community resources. The modeling power is identical.
Try Fastero free — import your dbt semantic layer, connect your warehouse, and build dashboards on top of your models. No credit card required.