dbt Core vs dbt Cloud: Which Do You Need? (2026)

If you already have orchestration (Airflow, Dagster, Prefect) and your team is comfortable in VS Code, dbt Core does everything you need and costs nothing. If you don't have orchestration, don't want to build CI pipelines from scratch, or need multiple non-technical contributors working in the same project, dbt Cloud earns its price. The decision is less about features and more about what your team is willing to manage.

Side-by-side comparison

How the workflow actually differs

The gap isn't in what dbt can do -- Core and Cloud run the same transformation engine. The gap is in everything surrounding the transformation: how you schedule it, how you catch regressions, how you onboard new teammates.

dbt Core workflow
=================
 
  Developer                    Your infrastructure
  +----------------+           +----------------------------------+
  | VS Code        |           |                                  |
  | + dbt extension|   git     |  GitHub/GitLab                   |
  |                | --------> |    |                              |
  | dbt run        |           |    | GitHub Actions (you write)   |
  | dbt test       |           |    v                              |
  | dbt build      |           |  CI pipeline (you maintain)      |
  +----------------+           |    |                              |
                               |    v                              |
                               |  Airflow / Dagster / Prefect      |
                               |  (you deploy + monitor)           |
                               |    |                              |
                               |    v                              |
                               |  Warehouse                        |
                               +----------------------------------+
                               |                                  |
                               |  dbt docs serve (you host)       |
                               |  Alerting (you configure)        |
                               |  Logs (you aggregate)            |
                               +----------------------------------+
 
  You own: CI config, orchestrator, docs hosting, alerting, logs
 
 
dbt Cloud workflow
==================
 
  Developer                    dbt Cloud (managed)
  +----------------+           +----------------------------------+
  | Browser IDE    |           |                                  |
  | or VS Code     |   git     |  Managed git integration         |
  |                | --------> |    |                              |
  | dbt build      |           |    | Slim CI (auto)               |
  | (in-browser)   |           |    v                              |
  +----------------+           |  Built-in scheduler               |
                               |  (retry, alerting, SLAs)         |
                               |    |                              |
                               |    v                              |
                               |  Warehouse                        |
                               +----------------------------------+
                               |                                  |
                               |  dbt Explorer (auto-hosted)      |
                               |  Metadata API                    |
                               |  Job history + audit logs        |
                               +----------------------------------+
 
  You own: SQL models and tests. That's it.

Notice where the complexity lives. With Core, every box below "GitHub Actions" is yours to deploy, configure, monitor, and debug. With Cloud, you're writing SQL and YAML. That's the trade-off in its clearest form.

The bottom line: dbt Core gives you the engine and lets you build the car. dbt Cloud gives you the car.

What's the actual cost difference?

dbt Core is free. But "free" has hidden costs that don't show up in the licensing line item.

A typical dbt Core setup requires someone to maintain an orchestrator -- Airflow, Dagster, or Prefect. If you're self-hosting Airflow, that's a VM, a database, a scheduler process, and someone who knows how to debug DAG parsing errors at 2am. Managed Airflow (MWAA, Cloud Composer, Astronomer) costs $300-500/month before you write a single DAG.

Then there's CI. You'll write GitHub Actions or GitLab CI to run dbt build on PRs. A basic workflow takes an afternoon. A good one -- with state-aware runs that only test changed models, warehouse credential management, and parallel execution -- takes a week and ongoing maintenance.

Documentation hosting, alerting on failed runs, log aggregation -- each one is a small project. None is hard individually. Together they add up to real engineering time.

dbt Cloud bundles all of this. At $100/seat/month for a five-person team, that's $6,000/year. If maintaining the DIY stack costs more than a week of engineering time per quarter, Cloud is cheaper. If your team already runs Airflow for other workloads and has CI sorted out, the marginal cost of adding dbt is near zero and Core wins.

There's also a middle ground worth knowing about: the Developer tier of dbt Cloud is free for one seat. A solo analytics engineer can use the browser IDE, run jobs on a schedule, and get Slim CI on one project -- no cost. It's limited (one developer, one project, limited run history), but it's a real way to try Cloud features before committing to the Team tier.

Is Slim CI worth $100/seat/month by itself?

For many teams, yes. Slim CI is the single feature that most often tips the decision toward Cloud.

Here's what it does: when someone opens a PR, dbt Cloud identifies which models changed, runs only those models plus their downstream dependencies, and compares the results against production. It doesn't rebuild your entire project. On a 300-model project, that's the difference between a 45-minute CI run and a 3-minute one.

You can approximate this with dbt Core. The state:modified+ selector lets you run only changed models, and you can store a manifest.json artifact from your last production run to enable state comparison. But wiring this up in GitHub Actions -- downloading the right manifest, handling credential injection, managing deferral targets, parsing test failures into PR comments -- is a multi-day project. And every time dbt Labs changes the manifest schema, you're fixing it again.

If your team opens more than a few PRs per week, Slim CI pays for itself in developer time. If you're a solo analytics engineer pushing to main, it barely matters.

Worth noting: Slim CI also catches schema-breaking changes. If a PR renames a column that a downstream model references, the CI run fails before it hits production. With a hand-rolled pipeline, you'd need to build that detection yourself or find out after the merge.

Can you start with Core and migrate to Cloud later?

Yes, and this is the path I'd recommend for most teams starting out. The migration is straightforward because dbt Cloud runs the same dbt Core engine underneath. Your models, tests, macros, and packages work identically. What changes is the infrastructure around them.

The migration typically looks like this: connect your git repo to dbt Cloud, configure your warehouse connection in the Cloud UI instead of profiles.yml, set up your environments, and move your scheduled jobs from Airflow/cron to Cloud's scheduler. The SQL doesn't change. The YAML doesn't change. The Jinja doesn't change.

Two things that do require adjustment: any custom CI logic you built needs to be replaced with Cloud's Slim CI (usually simpler), and any API integrations that read from your self-hosted docs or metadata need to point to Cloud's metadata API instead.

The reverse migration -- Cloud to Core -- is also possible but involves more work. You need to set up everything Cloud was handling: orchestration, CI, docs hosting, alerting. Teams rarely go this direction unless they're cutting costs or hitting Cloud limitations around custom orchestration.

One pattern I've seen work well: start on Core, get your models and tests solid, then evaluate Cloud once the project crosses ~50 models and you have multiple contributors. By that point you'll know exactly which Cloud features would save you time and which ones you don't need.

When does the browser IDE matter?

The browser IDE is a polarizing feature. Engineers who live in VS Code or Neovim see it as a downgrade -- they've got their keybindings, their extensions, their terminal workflow. They don't want a browser tab.

But the IDE isn't for those engineers. It's for the analytics engineer who just joined from a BI background, or the data analyst who's writing their first dbt model. The browser IDE gives them autocomplete on model references, inline compilation preview (see the compiled SQL before running it), and a visual lineage graph right next to their code. No local Python environment, no profiles.yml configuration, no "which virtual env am I in?" debugging.

If everyone on your team is comfortable with local development, the browser IDE adds nothing. If you're onboarding people who aren't, it removes a real barrier.

dbt Cloud also supports VS Code via the dbt Cloud CLI, so you aren't locked into the browser -- the IDE is an option, not a requirement. In practice, hybrid teams often have senior engineers in VS Code and newer analysts in the browser, working on the same project simultaneously.

What about the semantic layer?

The dbt Semantic Layer (powered by MetricFlow) lets you define metrics -- revenue, active users, conversion rate -- as code in your dbt project and expose them through a standardized API. Downstream tools query metrics by name instead of writing their own SQL, which means "revenue" means the same thing in every dashboard, report, and data app.

In dbt Core, MetricFlow works locally via the CLI. You can define metrics and query them during development. But there's no API server -- you can't connect BI tools to it. The semantic layer as a production feature is Cloud-only.

Whether this matters depends on your stack. If you already have a single BI tool and your metrics are defined there, the semantic layer is redundant. If you have multiple consumers -- a BI tool, a Streamlit app, a Slack bot, a customer-facing dashboard -- and you're tired of each one computing "monthly revenue" differently, the semantic layer solves a real problem. But it requires dbt Cloud.

For most teams under 10 people with one or two downstream consumers, the semantic layer is a nice-to-have. For platform teams serving dozens of internal consumers, it's transformational.

FAQ

Can I use dbt Core with VS Code and still get autocomplete and lineage? Yes. The dbt Power User extension gives you model autocomplete, inline SQL compilation, and a lineage graph inside VS Code. It's free, actively maintained, and covers most of what Cloud's browser IDE offers. Column-level lineage and some advanced features require the paid tier, but the free version handles daily work well.

Does dbt Cloud lock me into their platform? No. Your dbt project is the same set of SQL/YAML/Jinja files whether you run it on Core or Cloud. Cloud stores your connection credentials, job definitions, and environment configs -- but your transformation logic stays in your git repo. You can walk away from Cloud any time and keep running the same project with Core.

Is there a self-hosted option for dbt Cloud? Not officially. dbt Labs offers an Enterprise tier with single-tenant deployment and IP restrictions, but it's still hosted by dbt Labs. If you need to run dbt infrastructure entirely within your own VPC, you're looking at dbt Core with self-managed orchestration. Some teams use Dagster Cloud or Prefect Cloud for orchestration while keeping data transformation on Core.

How do dbt Cloud and third-party tools like Dagster overlap? Significantly on scheduling and CI. If you already use Dagster or Prefect, you have job scheduling, retry logic, and alerting. Adding dbt Cloud on top means paying for scheduling you already have. Where Cloud adds value even with an orchestrator is the browser IDE, dbt Explorer, and the semantic layer -- features that orchestrators don't provide. Some teams use Cloud for development and dbt Explorer but run production jobs through their existing orchestrator via the dbt Cloud API.

Can I mix Core and Cloud on the same project? Yes. A common pattern: developers who prefer local tooling use dbt Core + VS Code for authoring and testing. The CI and production execution runs on dbt Cloud. The project is the same git repo; only the execution environment differs. This gives you the local development experience engineers want and the managed CI/scheduling that ops teams need. dbt Cloud's CLI mode (as opposed to the browser IDE) was designed exactly for this hybrid setup -- you develop locally but execute against Cloud's infrastructure.

The decision framework

Pick dbt Core if: you already run an orchestrator, your team is comfortable with CLI tools, you want full control over your CI pipeline, or you're optimizing for cost. Pick dbt Cloud if: you don't have orchestration set up, you want Slim CI without building it, you're onboarding analysts who aren't comfortable with local development, or you need the semantic layer in production.

Where does your dbt data end up?

dbt -- Core or Cloud -- transforms data inside your warehouse. It doesn't answer questions about that data. You still need something downstream: a BI tool, a notebook, a data app, or a reporting layer that turns those clean, tested, well-documented models into dashboards and insights people actually look at.

That's where tools like Fastero fit. Connect your warehouse, point at the tables dbt built, and ask questions in SQL or plain English. Your dbt models become the foundation; the analytics layer sits on top. Whether you run Core or Cloud underneath doesn't matter -- the data lands in the same place either way, and the analysis workflow is the same.

If you're building a free analytics stack from open-source tools, dbt Core handles the transformation layer. If your team wants managed infrastructure and you've got the budget, dbt Cloud handles it with less overhead. Both produce the same well-structured data that downstream tools -- Fastero included -- can query, visualize, and act on.

Try Fastero free — dashboards on top of your dbt-transformed data. Connect your warehouse, ask questions in SQL or English. No credit card required.