dbt Cloud (Studio) vs dbt Core

В мае 2026 dbt существует в двух принципиально разных формах: dbt Core — open-source CLI, и dbt Cloud / Studio — managed SaaS-продукт от dbt Labs (после merger с Fivetran в октябре 2025). Этот урок отвечает на главный middle-вопрос: что именно Cloud делает за вас и когда платить за него экономически разумно.

Что такое dbt Core (recap)

dbt Core — это open-source Python-пакет под Apache 2.0. Текущий stable — 1.10 (выпущен в начале 2026). Что вы получаете бесплатно:

• CLI: dbt run, dbt test, dbt build, dbt docs serve
• Адаптеры: dbt-snowflake, dbt-bigquery, dbt-duckdb и т.д.
• Все core-фичи: модели, ref(), sources, tests, snapshots, incremental, microbatch, unit tests, semantic_models
• Локальная docs-генерация: dbt docs generate + dbt docs serve
• Возможность интегрировать с любым оркестратором: Airflow + Cosmos, Dagster, Prefect, GitHub Actions, cron

Что Core НЕ делает:

• Не шедулит запуски сам — нужен внешний оркестратор
• Не хранит artifacts между запусками — нужен S3/git
• Не имеет встроенного UI для team collaboration — только локальный docs serve per-developer
• Не имеет встроенной системы алертов
• Не имеет встроенного secrets management

Производственный сетап на Core в 2026 году обычно выглядит так: Airflow (или GitHub Actions) запускает dbt build, manifest сохраняется в S3, alerts шлются через кастомный Python hook в Slack, secrets берутся из Vault.

Что такое dbt Cloud / Studio

dbt Cloud — SaaS-продукт от dbt Labs. С 2024-2025 годов IDE-часть стала называться dbt Studio, а после merger с Fivetran в октябре 2025 года продукт продолжает rebranding: часть документации использует “Studio”, часть — “Cloud”. Для middle-инженера в 2026 важно знать оба термина — они описывают один и тот же managed-продукт.

Архитектурно Cloud / Studio = dbt Core внутри managed-окружения + дополнительные SaaS-сервисы поверх.

Что Cloud / Studio даёт сверху

Разберём каждую категорию.

IDE / Studio

Web IDE с автокомплитом по моделям и колонкам (через manifest.json), lineage-view прямо в редакторе, preview скомпилированного SQL рядом с Jinja-источником, встроенный git (branches, PR-flow без локального cli). Studio — самый “видимый” компонент Cloud, его обычно показывают на demo.

Полезность Studio для middle-инженера: ниже, чем кажется. Опытные разработчики предпочитают VSCode + dbt-power-user extension, потому что:

• Локальное окружение быстрее web-IDE
• VSCode дружит с git-tooling (lazygit, magit, GitLens)
• Расширения покрывают всё, что есть в Studio (lineage, preview, autocomplete)

Studio даёт ценность главным образом для non-engineers: аналитики без локального dev-окружения, контракторы, бизнес-пользователи которые правят SQL-логику метрик.

Jobs (deploy + CI)

Главная экономическая ценность Cloud для большинства команд. Jobs — это cron-like шедулер, где вы определяете:

• Команды: dbt build, dbt run, dbt test, dbt source freshness
• Расписание: cron или интервал
• Триггеры: webhook, manual, dependency на другой job
• Environment: dev / staging / prod (target вычисляется по env)
• Notifications: success / fail / cancel

Без Cloud вам нужен Airflow + Cosmos (или Dagster + dagster-dbt), что означает: K8s-кластер или managed Airflow ($300-$1000/month), DevOps-овнер для поддержки, обновления Airflow и Python-зависимостей.

Explorer

Лineage UI поверх dbt-артефактов. Что Explorer показывает чего нет в локальном dbt docs:

• Performance metrics: какие модели медленные, тренды по времени
• Ownership: владельцы моделей через teams
• Freshness staleness: какие source-таблицы не обновлялись
• Cross-project lineage (через dbt Mesh): зависимости между проектами

Defer

Технология “compile against prod, run against dev”. Когда вы делаете dbt run --defer --select +my_model+, dbt компилирует ваши локальные изменения, но ref() других моделей резолвится в prod-схемах. Без defer вам приходится либо запускать всё upstream локально, либо иметь dev-warehouse где всё уже есть.

В Cloud defer работает “из коробки” — Studio автоматически сохраняет manifest от prod jobs и использует его при CI. В Core вам нужно вручную выкладывать manifest в S3 после каждого prod-run.

Notifications и Webhooks

Cloud отправляет уведомления в Email / Slack / Microsoft Teams по событиям jobs. Webhooks позволяют интегрировать с любыми внешними системами (PagerDuty, Opsgenie, кастомные dashboards). В Core нужно писать post-run hooks на Python.

Semantic Layer API

Endpoint (GraphQL + JDBC) который BI-инструменты используют для запросов метрик. Tableau, Looker, Hex, Mode, Sigma имеют коннекторы к dbt Semantic Layer. Без Cloud вам нужно либо поднимать MetricFlow сервер самим (открытый исходник, но в production требует поддержки), либо не использовать Semantic Layer “правильным” способом.

Cost Insights

Атрибуция расходов warehouse (Snowflake credit usage, BigQuery slot-hours) к конкретным dbt-моделям и Jobs. Самостоятельно это требует парсинга information_schema.query_history Snowflake + JOIN с manifest.json + ETL — то есть, отдельный mini-pipeline. В Cloud это идёт “бесплатно” внутри Explorer.

dbt Mesh

Cross-project ref’ы, model groups, access (private/protected/public), governance. Mesh может работать частично через Core (структура файлов та же), но реальный механизм cross-project lineage и governance UI — только в Cloud. Подробнее — урок 5 этого модуля.

Pricing tiers (май 2026)

После merger с Fivetran структура pricing немного изменилась. На май 2026 для dbt-направления продукта актуальны три тира:

Важный нюанс после merger: с Q1 2026 в Team tier добавлены Fivetran-credits — небольшая квота на использование Fivetran connectors. Это позиционируется как “единая платформа Load + Transform”. В Enterprise можно объединить billing dbt + Fivetran в один договор.

Когда платить за Cloud vs остаться на Core

Это главный middle-вопрос. Здесь нет универсального ответа — есть факторы.

Когда Cloud очевидно стоит денег

Команда без DevOps: 1-3 аналитика, нет инфраструктурной поддержки. $100-$300/month за Cloud Team — дешевле, чем нанять part-time DevOps на $5k+/month, который бы поднял Airflow и поддерживал его.

Большой проект с Snowflake / BigQuery: Cost Insights окупается на проектах с warehouse-расходами $10k+/month. Реальная экономия 10-30% от расходов на warehouse через выявление “дорогих” моделей.

Mesh-сценарий: компания делит dbt на 5+ проектов (по domain), нужна governance, cross-project lineage и access control. Это базовый use-case Enterprise.

Semantic Layer для BI: если планируете подключать 3+ BI-инструмента к одному определению метрик, своя реализация MetricFlow-сервера дороже Cloud-подписки.

Когда Core “достаточно”

1 человек, 50 моделей: GitHub Actions + cron + S3 для манифестов. Можно собрать за неделю. Не нужны notifications кроме CI-статуса PR.

Команда с сильным DevOps: Airflow уже есть, Cosmos берёт dbt-DAG за полчаса. Cloud — overhead, потому что Jobs уже шедулятся в Airflow.

Регулятивные ограничения: Cloud — multi-tenant SaaS, ваши metadata уходят в инфраструктуру dbt Labs. Для финтеха, госов, healthcare это часто блокер. Enterprise Cloud имеет private deployments, но они дорогие.

Очень специфичные адаптеры: dbt-duckdb официально не поддерживается в Cloud (по состоянию на май 2026). Если ваш warehouse — DuckDB / MotherDuck / ClickHouse / Trino — Cloud не работает или работает ограниченно. Это известное и стабильное архитектурное ограничение.

Гибридные модели

Не редкость — комбинация. Несколько распространённых паттернов:

Core в production + Cloud Developer free tier для лернинга: prod на Airflow + Core, отдельный sandbox-проект в Cloud Developer для onboarding новичков. Бесплатно, удобно.

Cloud для прод, Core для CI: prod-jobs в Cloud, но CI на GitHub Actions с dbt-core запускается на самих PR. Дешевле, чем платить Cloud за каждый CI-run.

Cloud для одних команд, Core для других: marketing-team пользуется Studio (потому что non-engineers), data-platform team пользуется VSCode + Core (потому что разработчики). Один и тот же warehouse, разные UX.

Что middle-инженер должен уметь

После этого урока вы должны:

1. Объяснить разницу между Core и Cloud / Studio в одну фразу: Core — engine + CLI, Cloud — managed окружение (IDE, Jobs, Explorer, Cost Insights, Mesh) поверх того же engine.
2. Знать актуальное состояние брендинга (Studio, после Fivetran merger).
3. Назвать 5+ компонентов, которые Cloud добавляет к Core.
4. Понимать pricing-тиры на верхнем уровне (Developer free / Team / Enterprise).
5. Аргументировать решение “платить или нет” исходя из размера команды, warehouse-стоимости, регулятивных ограничений.

Попробуй сам

Откройте getdbt.com/pricing и посмотрите актуальные тиры. Сравните с тем, что описано в этом уроке — что изменилось с мая 2026?

Зайдите в cloud.getdbt.com и зарегистрируйтесь на Developer free tier. Подключите PostgreSQL (или другой support’ed warehouse — DuckDB не получится). Создайте один dbt-проект, посмотрите как выглядит Studio IDE и Jobs UI. Это — лучший способ почувствовать, что Cloud даёт сверху Core.

Возьмите ваш текущий dbt-проект (или прошлый коммерческий). Прикиньте: сколько часов в месяц тратится на поддержку CI / шедулинга / алертов? Сколько было бы стоить заменить это Cloud Team-подпиской? Где точка разворота — окупается или нет?