dbt Core is free and fully customizable. dbt Cloud adds IDE, scheduling, CI/CD, and governance. Choose Core for cost-conscious teams with DevOps skills; choose Cloud for productivity and enterprise features.
I've run dbt Core on Airflow for years, and I've onboarded teams onto dbt Cloud several times. Both use the same underlying dbt engine — the difference is what you pay for and what you manage yourself. dbt Core is the free CLI; you're responsible for scheduling, CI/CD, IDE, docs hosting, and governance. dbt Cloud bundles all of that into a SaaS product with per-seat pricing. The decision isn't really about the dbt technology — it's about where your organization wants the cost and labor to land.
At one company with a 20-person analytics team, we moved from dbt Cloud to dbt Core + Airflow to save on licensing. The savings were real (~$60K/year) but we underestimated the hidden labor: someone now owned the Airflow DAGs, GitHub Actions for CI, a self-hosted dbt docs site, secrets management, environment promotion scripts. It added up to roughly 0.5 FTE of ongoing platform work. Net-net it was a small win financially, but not the home run we pitched. Lesson: dbt Core is "free" only if you have the platform capacity; otherwise you're just shifting cost to engineering time.
At a smaller five-person shop with no platform team, dbt Cloud was clearly the right call — $500/month bought them scheduler, CI, IDE, and docs without any ops. They shipped faster and nobody had to babysit cron jobs.
pip install dbt-core + an adapter like dbt-snowflake). You run commands locally or in CI (dbt run, dbt test, dbt docs generate). Scheduling, CI, docs hosting, and governance are your problem to solve. It's a library — you build the platform around it.Choose dbt Core if:
dbt docs serve is a local dev tool, not a production docs site. You'll need an S3 static site, Nginx container, or similar to host org-wide docs. Not hard, but not free time.If your team is small (<10 analytics engineers) and you don't already have orchestration, dbt Cloud is almost always the right answer — your time is worth more than the license. If your team is large (20+ analytics engineers) and you have strong platform capacity, dbt Core + Airflow often works out cheaper and more flexible, but budget real FTE time for the platform layer. If you're in between, pilot both: run dbt Cloud for a quarter with a subset, run dbt Core + Airflow for another subset, measure both feature parity and engineering time spent. The decision tends to resolve itself quickly once you have real numbers.
Yes — and this is a common path. dbt Cloud runs dbt Core under the hood, so your project files, models, tests, macros, and packages are fully compatible. Migration means connecting your Git repo to dbt Cloud, configuring environments and jobs through their UI, and moving any custom orchestration out of Airflow into dbt Cloud Jobs. Budget 1–2 sprints for the switch; expect the bulk of the effort to be reconfiguring scheduling and environment variables rather than touching your dbt code itself.
The dbt Core software itself is open source under Apache 2.0 — zero license cost. But running it in production means you pay for surrounding infrastructure: an orchestrator (Airflow on EC2, Dagster Cloud, Prefect), CI runners (GitHub Actions minutes or your own CI), secrets management (Vault, AWS Secrets Manager), docs hosting (S3 + CloudFront or Nginx), and engineer time to maintain it all. Realistically, a well-run dbt Core deployment has $2–10K/month of ambient infrastructure and platform cost for a medium team.
The major Cloud-only features are: a web-based IDE with SQL autocomplete and model preview, built-in job scheduler (Jobs), Slim CI (which automatically detects changed models and only tests those plus downstream), auto-hosted documentation site with search, column-level lineage (Team/Enterprise), dbt Explorer (model catalog), the dbt Semantic Layer / MetricFlow for metric definitions, and Enterprise features like SSO/SAML, RBAC with model-level permissions, audit logs, private networking, and dbt Mesh for multi-project governance.
Pricing is published on the dbt Labs site and changes periodically. At the time of writing, the Team plan is around $100/developer seat/month, and Enterprise is negotiated based on seats, features, and volume. There's also a free Developer plan for a single user (great for individuals and solo evaluations). When modeling cost, remember that seats are per developer who commits code — viewers/analysts who only consume docs don't consume seats.
Yes, and this is arguably the most common production pattern. Use the `cosmos` library (Astronomer's open-source dbt-Airflow integration) or the DbtRunOperator/DbtBashOperator patterns to render your dbt models as Airflow tasks with real dependency graphs and per-model retry/alerting. This gives you dbt's transformation model combined with Airflow's mature orchestration, scheduling, SLAs, and observability. Cosmos in particular has become a de-facto standard.
Yes — dbt Cloud supports all the major warehouses (Snowflake, BigQuery, Databricks, Redshift, Postgres, and more), same as dbt Core. The adapter you'd use with Core (`dbt-snowflake`, etc.) is pre-configured in dbt Cloud; you just provide connection credentials through the UI. Feature parity across warehouses is good but not perfect — some advanced features (e.g., certain materialization strategies) may be warehouse-specific.
Partially. The MetricFlow library itself is open-source and can be used outside of dbt Cloud, but the integrated "dbt Semantic Layer" as a queryable API (used by BI tools like Hex, Mode, Lightdash) is a dbt Cloud product. If you want programmatic metric definitions in Core, you can use MetricFlow standalone — but the hosted query layer that lets tools like Tableau call `sum(revenue)` without rewriting SQL is Cloud-only.