dbt Coreとdbt Cloudは「同じdbtエンジン」を共有しており、モデル定義やテストの書き方は完全に共通です。違いは実行環境・スケジューリング・CI/CD・UIといった「運用体験」をどこまでSaaSに任せるかの一点に集約されます。少人数のスタートアップならCore + GitHub Actionsで十分、中規模チームに育ったらCloudのジョブスケジューラとWeb IDEで時間を買う、という段階的な選択が現実的です。本記事では両者の特徴・コスト・チーム規模別の推奨を整理したうえで、判断フローチャートと実装サンプルまで提供します。「まずCoreで始めて、必要に応じてCloudへ」という折衷戦略も含め、意思決定の判断材料を揃えていきましょう。
dbt CoreとCloud――同じdbtでも「運用体験」が大きく異なる
dbt Coreは、Apache 2.0ライセンスのCLIツールとして提供されているオープンソース本体です。pip installでインストールし、ローカルもしくは自前のサーバー・CI/CD環境から実行します。モデル定義・テスト・ドキュメント生成といったdbtの中核機能はすべてCoreに含まれており、料金はかかりません。
一方dbt Cloudは、dbt Labs社が提供するSaaS型のマネージドサービスです。dbt Coreをベースに、Web IDE・ジョブスケジューラ・CI連携・ドキュメントホスティング・セマンティックレイヤーといった運用系の機能を追加したものと理解すると分かりやすいでしょう。エンジンが同じである以上、モデル定義そのものを書き換える必要はどちらを選んでも発生しません。
したがって選定の論点は「機能の有無」ではなく、「運用インフラを自分たちで持つか、月額を払って外部化するか」という経済合理性の問題になります。
dbt Coreの特徴と向いているチーム
dbt Coreの最大のメリットは完全無料であること、そして自由度が極めて高いことです。既存のAirflow・GitHub Actions・Jenkins・GitLab CIなど、どのような実行基盤とも統合できます。社内ポリシー上SaaSへの機密データ送信が難しい企業や、既にデータ基盤のインフラを持っている組織にはCoreが馴染みます。
デメリットは運用負荷です。スケジューリングは自前で仕組みを作る必要があり、Web UIは存在せず、ドキュメントホスティングも別途検討しなければなりません。セットアップから安定運用までには、ある程度のエンジニアリング工数が必須となります。
例えばAirflowからdbt Coreを叩く場合、BashOperatorで以下のように呼び出す形が定番です。
from airflow.operators.bash import BashOperator
run_dbt = BashOperator(
task_id='dbt_run_daily',
bash_command='cd /opt/dbt_project && dbt run --target prod --profiles-dir .',
env={'DBT_PASSWORD': '{{ var.value.dbt_password }}'},
)
Coreが向いているのは、インフラ運用を自前で行える技術力があり、かつ自由度とコストを優先したいチームです。
dbt Cloudの特徴と向いているチーム
dbt Cloudは、Web IDE・ジョブスケジューラ・CI/CD統合・ドキュメントホスティング・セマンティックレイヤーといった運用系機能をワンストップで提供します。ブラウザを開けばすぐに開発を始められるため、アナリティクスエンジニアの立ち上がりが早いのが魅力です。Gitリポジトリと連携してPull Requestごとに自動テストを走らせる「Slim CI」機能は、CI/CD基盤を自作せずに済む大きな利点です。
デメリットは料金とベンダーロックインです。Developerプランは1ユーザー無料ですが、複数人で使うTeamプランは1シートあたり月額$100程度から始まります。また、近年ではdbt Cloud CLIが公開されたことで、ローカル開発とCloudのジョブ実行を組み合わせるハイブリッドな使い方もしやすくなりました。
Cloudが向いているのは、運用工数を買いたい中規模チーム、SaaS完結でガバナンスを担保したい組織、そしてセマンティックレイヤーを活用したいBI統合プロジェクトです。
徹底比較表
以下の表で、dbt Coreとdbt Cloudの主要項目を俯瞰的に比較します。実際の選定にあたっては、このチェックリストを下敷きに自社の優先順位をマーキングしていく使い方が有効です。
| 項目 | dbt Core | dbt Cloud |
|---|---|---|
| 料金 | 完全無料(OSS) | Developer無料、Team $100/シート〜、Enterpriseはカスタム |
| 実行環境 | 自前サーバー・コンテナ・CI/CD | マネージドなクラウド実行環境 |
| スケジューリング | Airflow等を別途用意 | 組み込みジョブスケジューラ |
| CI/CD | GitHub Actions等を自作 | Slim CI・Pull Request連携が組み込み |
| Web IDE | なし(ローカルエディタ) | あり(ブラウザで完結) |
| ドキュメントホスティング | 自前でホスティング | マネージドホスティング |
| セマンティックレイヤー | dbt-semantic-layer単体で利用可だが統合は自作 | フル統合、BIツール連携が容易 |
| ユーザー管理 | なし(Git権限に依存) | ロール管理・SSO(上位プラン) |
| API | なし | Jobs API、Discovery APIを提供 |
| サポート | コミュニティ(Slack・GitHub) | 公式サポート窓口 |
チーム規模別の推奨選択
チームの人数と成熟度に応じて、最適な選択は変わります。以下、3つのフェーズ別に実用的な推奨を示します。
フェーズA:1〜3人のスタートアップ。Coreを選び、GitHub Actionsでのスケジューリングとテストを組むのが定番です。コストをかけずに、かつモダンな開発フローを最初から実装できます。Developer無料プランも選択肢に入りますが、複数人で併用するには制約が出てくるでしょう。
フェーズB:5〜10人の中規模チーム。ここではdbt Cloud Teamへの切り替えを検討すべきです。ジョブ失敗時の通知、Slim CI、共有ドキュメントサイトといった機能が、チーム全体の生産性を底上げします。月額コストが発生しますが、自作する場合の運用人件費を考えると十分割に合います。
フェーズC:10人以上のエンタープライズ。dbt Cloud Enterpriseへ進むか、あるいは既存のAirflow基盤と統合する形でCoreを使い続けるかの二択になります。SSO・監査ログ・ロール管理といったガバナンス要件が強い場合はEnterpriseが有力です。
| チーム規模 | 推奨 | 理由 | 月額目安 |
|---|---|---|---|
| 1〜3人 | Core + GitHub Actions | コストゼロで最小構成が組める | 約0円〜数千円(CI実行時間) |
| 5〜10人 | dbt Cloud Team | 運用工数の削減とガバナンスの両立 | 約5万〜15万円 |
| 10人以上 | Cloud Enterprise または Core + 自前基盤 | SSO・監査・大規模ジョブ運用 | 要見積もり |
【dbt Core vs Cloud 判断フローチャート】
Q1. 既にAirflow等のオーケストレーション基盤があるか?
├── Yes --> Q2. インフラ運用に余力があるか?
│ ├── Yes --> [dbt Core + 既存基盤] 推奨
│ └── No --> [dbt Cloud Team] 検討
└── No --> Q3. チーム人数は?
├── 1〜3人 --> [dbt Core + GitHub Actions]
├── 5〜10人 --> [dbt Cloud Team]
└── 10人以上 --> [dbt Cloud Enterprise]
※ Developer無料プランは個人検証向け。本番運用には上位プランが前提
dbt Core + OSS構成の実装例
dbt Coreを選んだ場合の定番構成が、Airflow + GitHub Actionsの組み合わせです。Airflowで日次バッチを制御し、GitHub ActionsでPR単位のテストを走らせる二本立ての運用になります。以下は、GitHub Actionsでdbt testを実行する最小構成のサンプルです。
name: dbt CI
on:
pull_request:
branches: [main]
jobs:
dbt-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: '3.11'
- run: pip install dbt-snowflake
- run: dbt deps
- run: dbt compile --target ci
- run: dbt test --target ci
env:
DBT_SNOWFLAKE_PASSWORD: ${{ secrets.DBT_PASSWORD }}
このYAMLをリポジトリの.github/workflows配下に置くだけで、Pull Requestのたびに自動テストが走ります。dbt CloudのSlim CIに近いことを無料で実現できる点が、Core+OSS構成の魅力です。
まとめ――「まずCoreで始めて、必要に応じてCloudへ」も有効な戦略
本記事の要点を振り返ります。
- dbt Coreは完全無料・自由度が高いが、運用は自前
- dbt CloudはWeb IDE・ジョブ管理・Slim CIを組み込みで提供
- チーム規模が5〜10人を超える頃がCloud検討の目安
- プロジェクト自体はそのまま使えるため、Core→Cloudの移行障壁は低い
- 「まずCoreで始め、必要になったらCloudへ」という段階的戦略も有効
次に読むべき記事は、dbtの基本概念を押さえるdbt入門、スケジューリングの選択肢を広げるAirflow入門、そしてCI/CD設計の実践編です。DE-STKでは、dbtの導入可否診断から実装・社内浸透までを並走型で支援しています。現在の構成が最適かどうかを確認したい方は、ぜひ一度ご相談ください。
よくある質問(FAQ)
Q. dbt Coreは完全に無料ですか?
A. はい。dbt CoreはApache 2.0ライセンスのOSSで完全無料です。ただし実行環境(サーバー、CI/CD)やスケジューリング(Airflow等)の構築・運用コストは別途かかります。
Q. dbt Cloudの料金はいくらですか?
A. Developerプラン(1名)は無料、Teamプランは1シートあたり月額$100程度から始まります。Enterpriseプランはカスタム見積もりで、SSO・監査ログ等の機能が追加されます。
Q. dbt CoreからCloudへの移行は簡単ですか?
A. dbtプロジェクト自体はそのまま使えるため、移行のハードルは低いです。主な作業はGitリポジトリの接続設定、ジョブスケジュールの再設定、環境変数の移行です。