La Distinzione Fondamentale

È importante capire subito una cosa: dbt Core e dbt Cloud usano lo stesso motore. I modelli SQL, le macro Jinja, i test YAML, i file di configurazione - sono identici. dbt Cloud non è un prodotto diverso: è un managed service che wrappa dbt Core aggiungendo infrastruttura e strumenti di produttività.

La scelta tra i due non è tecnica ma organizzativa: dipende dalla dimensione del team, dalla maturità della piattaforma dati, e da quanto tempo e infrastruttura sei disposto a gestire internamente.

dbt Core: Il Motore Open-Source

dbt Core è il progetto open-source mantenuto da dbt Labs. È un CLI Python installabile con pip, completamente gratuito, senza limiti su modelli o utenti.

-- Installazione dbt Core (esempio con adapter Snowflake)
pip install dbt-snowflake==1.8.0

-- Verificare la versione
dbt --version

-- Cosa ottieni con dbt Core:
-- * dbt run, dbt test, dbt docs, dbt source freshness
-- * Tutti i tipi di materializzazione
-- * Macro e package (packages.yml + dbt deps)
-- * Jinja2 templating completo
-- * Schema.yml per documentazione e test
-- * Adapter per 40+ warehouse (Snowflake, BigQuery, Redshift, Databricks, DuckDB...)
-- * Integrazione con qualsiasi orchestratore (Airflow, Prefect, Dagster)

Cosa dbt Core NON Include

Per usare dbt Core in produzione devi costruire e gestire tu stesso:

• Scheduler e orchestrazione: Airflow, Prefect, Dagster, o cron job
• IDE/editor: VS Code + estensione dbt Power User, o qualsiasi editor
• CI/CD: GitHub Actions, GitLab CI, Jenkins - configurazione manuale
• Hosting del catalogo dbt docs: GitHub Pages, S3 static website, Netlify
• Gestione degli artifact (manifest.json): S3, GCS, o altro storage per Slim CI
• Monitoraggio delle esecuzioni: logging custom, alerting Slack/email
• Gestione multi-ambiente: profiles.yml con variabili d'ambiente

dbt Cloud: Il Managed Service

dbt Cloud è la piattaforma SaaS di dbt Labs. Fornisce un'interfaccia web completa per sviluppare, schedulare, monitorare e documentare i progetti dbt senza gestire infrastruttura. Il pricing è per developer seat (2024):

Confronto Feature-by-Feature

1. Sviluppo (IDE e Ambiente)

# dbt Core: sviluppo in locale
# Setup:
# 1. Clona il repository
# 2. Configura profiles.yml con credenziali warehouse
# 3. Apri VS Code (estensione consigliata: dbt Power User)
# 4. dbt run / dbt test dalla CLI

# Vantaggi: workflow git-native, qualsiasi editor, nessuna dipendenza da internet
# Svantaggi: ogni developer configura il proprio ambiente, onboarding più lento

# dbt Cloud IDE: sviluppo nel browser
# Setup:
# 1. Accedi a cloud.getdbt.com
# 2. Configura il progetto (git repo + warehouse connection)
# 3. Ogni developer ha il proprio schema di sviluppo isolato automaticamente
# 4. Commit, preview, run direttamente nel browser

# Vantaggi: zero setup locale, schema isolati per sviluppatore, preview dei risultati inline
# Svantaggi: dipende dalla connessione internet, meno flessibile per workflows complessi

2. Scheduling e Orchestrazione

# dbt Core: orchestrazione con Airflow (esempio tipico)
# Richiede setup di Airflow + dbt Airflow provider

from airflow.decorators import dag, task
from airflow.operators.bash import BashOperator
from datetime import datetime

@dag(schedule_interval='0 6 * * *', start_date=datetime(2024, 1, 1))
def dbt_daily_pipeline():

    run_models = BashOperator(
        task_id='dbt_run',
        bash_command='cd /opt/dbt && dbt run --target prod --select tag:daily',
        env={'DBT_PROFILES_DIR': '/opt/dbt'}
    )

    run_tests = BashOperator(
        task_id='dbt_test',
        bash_command='cd /opt/dbt && dbt test --target prod --select tag:daily',
        env={'DBT_PROFILES_DIR': '/opt/dbt'}
    )

    run_models >> run_tests

# dbt Cloud: scheduling con job UI
# Configurazione tramite interfaccia web (o API dbt Cloud)

# Job: "Daily Production Run"
# Schedule: "Every day at 6:00 AM UTC"
# Commands:
#   - dbt deps
#   - dbt source freshness
#   - dbt build --target prod --select tag:daily
# Notifications:
#   - Slack: #data-alerts (on failure)
#   - Email: team@company.com (on failure + success)
# Retry: 1 volta dopo 10 minuti in caso di failure

3. CI/CD e Pull Request Testing

Questa è una delle aree dove dbt Cloud Team porta più valore aggiunto rispetto al self-hosting:

# dbt Core + GitHub Actions: CI manuale da configurare
# .github/workflows/dbt-ci.yml
name: dbt CI

on:
  pull_request:
    branches: [main]

jobs:
  dbt_ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dbt
        run: pip install dbt-snowflake==1.8.0
      - name: dbt deps
        run: dbt deps
      - name: dbt build (modificati + downstream)
        run: dbt build --select state:modified+ --defer --state ./prod-artifacts
        env:
          SNOWFLAKE_PASSWORD: ${{ secrets.SNOWFLAKE_PASSWORD }}
          DBT_TARGET: ci

# dbt Cloud Team: CI integrato nella UI
# Configurazione: Project Settings > Continuous Integration
# - Trigger: aperta PR su branch main
# - Commands: dbt build --select state:modified+
# - Schema CI: nome schema automatico (dbt_ci_pr123)
# - Commento automatico sulla PR con risultati (successo/failure + righe fallite)
# - Cleanup automatico schema CI dopo merge/close PR

# Vantaggio chiave: nessuna infrastruttura CI da mantenere
# Gli artifact di produzione (manifest.json) sono gestiti automaticamente da dbt Cloud

4. Lineage e Documentazione

Il Caso del Self-Hosting: Quando dbt Core Basta

Con un investimento iniziale di configurazione, dbt Core su orchestratori open-source può fare quasi tutto ciò che dbt Cloud Team fa. Ecco lo stack tipico self-hosted per team intermedi:

# Stack dbt Core self-hosted (per team 3-10 persone)
componenti:
  dbt_core: "1.8.x - motore di trasformazione"
  orchestratore: "Airflow 2.x su EC2/GKE oppure Prefect Cloud free tier"
  ide: "VS Code + dbt Power User extension"
  ci_cd: "GitHub Actions (configurazione manuale ~1 giorno)"
  documentazione: "dbt docs generate → GitHub Pages (gratuito)"
  artifacts_storage: "S3 bucket per manifest.json (Slim CI)"
  monitoring: "Airflow logs + Slack webhook custom"

costo_mensile_stimato:
  orchestratore_airflow_ec2: "~30 EUR/mese (t3.medium)"
  s3_artifacts: "~1 EUR/mese"
  totale: "~31 EUR/mese"

tempo_setup_iniziale: "3-5 giorni (DevOps + dbt engineer)"
tempo_manutenzione: "2-4 ore/mese (aggiornamenti, monitoring)"

Guida alla Scelta: Decision Framework

Risposta rapida: dbt Core self-hosted è sufficiente per team tecnici con infrastruttura già in piedi; dbt Cloud Team conviene quando il costo del developer time per setup e manutenzione supera il costo della subscription.

Migrazione dbt Core → dbt Cloud

Se inizi con dbt Core e poi migri a dbt Cloud, la transizione è quasi indolore perché il codice è identico. L'unica cosa che cambia è dove viene eseguito e come vengono gestite le credenziali:

# Prima: profiles.yml locale
my_project:
  target: dev
  outputs:
    dev:
      type: snowflake
      account: "{{ env_var('SNOWFLAKE_ACCOUNT') }}"
      user: "{{ env_var('SNOWFLAKE_USER') }}"
      password: "{{ env_var('SNOWFLAKE_PASSWORD') }}"
      database: analytics
      warehouse: compute_wh
      schema: dbt_dev_{{ env_var('DBT_USER', 'unknown') }}

# Dopo: connessione configurata nella UI dbt Cloud
# I credentials non sono più in profiles.yml
# dbt Cloud gestisce internamente le variabili d'ambiente
# Il file profiles.yml può essere rimosso o mantenuto solo per uso locale

# L'unico cambio nel codice: il profiles.yml non è deployato su dbt Cloud
# (le connessioni sono configurate tramite UI o API)

dbt Semantic Layer: Disponibile Solo su Cloud Enterprise

Una feature esclusiva di dbt Cloud che merita una menzione a parte è il Semantic Layer (basato su MetricFlow). È la risposta di dbt Labs al problema delle “metriche multiple”: ogni analista calcola il revenue in modo leggermente diverso, e ogni dashboard mostra numeri diversi per lo stesso KPI.

# Il Semantic Layer definisce le metriche una volta sola
# e le espone a qualsiasi tool BI tramite API standardizzata

# dbt Core: puoi definire le metriche in YAML (MetricFlow è open-source)
# ma l'integrazione con BI tool richiede dbt Cloud Enterprise

# In dbt Core, MetricFlow può essere usato via CLI:
pip install dbt-metricflow

# Query metriche da CLI (funziona anche senza Cloud):
mf query \
  --metrics revenue \
  --group-by order_date__month

# Integrazione con BI tool (Tableau, Looker, PowerBI):
# SOLO dbt Cloud Enterprise tramite Semantic Layer API
# (JWT-based authentication, JDBC/ADBC connection string)

Funzionalità in Anteprima: dbt Explorer vs Docs

Un confronto diretto tra il catalogo di dbt Core e quello di dbt Cloud:

Considerazioni Pratiche: Un Percorso Evolutivo

Il consiglio più onesto: non devi scegliere definitivamente da subito. Molti team partono con dbt Core, costruiscono esperienza e comprensione del progetto, e poi valutano dbt Cloud quando identificano problemi concreti che Cloud risolverebbe. I costi di migrazione sono minimi perché il codice è identico.

# Segnali che indicano che è il momento di valutare dbt Cloud Team:
segnali_migrazione:
  - "Onboarding di un nuovo developer richiede >2 giorni per setup locale"
  - "Le PR aspettano il CI per >15 minuti (compute CI troppo alto)"
  - "Gli analisti SQL vorrebbero modificare modelli ma temono la CLI"
  - "Airflow/Prefect occupano il 20%+ del tempo di un engineer"
  - "Il catalogo di documentazione è sempre disallineato dalla realtà"
  - "I PR non hanno check automatici e le rotture vanno in produzione"

# Se hai 3+ di questi segnali, il ROI di dbt Cloud Team è quasi certamente positivo.
# Se hai 0-1 segnali, dbt Core self-hosted è probabilmente sufficiente.

Conclusioni e Prossimi Passi

Non esiste la scelta universalmente migliore. dbt Core è eccellente per team tecnici che vogliono controllo totale; dbt Cloud ripaga il suo costo quando il tempo risparmiato su infrastruttura e onboarding supera la subscription.

La cosa più importante: inizia con dbt Core. Capisci cosa manca, cosa è difficile da gestire, e poi valuta se dbt Cloud risolve quei problemi specifici nel tuo contesto.

Il prossimo modulo affronta il tema CI/CD in profondità: come configurare GitHub Actions con Slim CI per testare solo i modelli modificati, risparmiando fino al 90% del tempo di CI rispetto a un full run.