Databricks fattura il compute in Databricks Units (DBU), con addebito al secondo, ai quali si aggiunge una fattura distinta del cloud provider per macchine virtuali, storage ed egress. Il costo totale dipende dal tipo di workload (Jobs, All-Purpose o SQL), dal tier di edizione (Standard, Premium o Enterprise) e dalla piattaforma cloud. I team che eseguono workloads batch di produzione su cluster All-Purpose anziché su cluster Jobs finiscono regolarmente per pagare 3-4 volte più del necessario. Per arrivare a una spesa Databricks prevedibile servono una corretta classificazione dei workloads, policy di auto-termination, governance dei cluster e monitoraggio continuo dei costi.
La maggior parte dei team CloudOps e FinOps si avvicina a Databricks aspettandosi una fattura cloud lineare. Ne riceve due. Databricks fattura il compute nella propria valuta, i DBU, mentre il cloud provider fattura separatamente le macchine virtuali, lo storage e l'egress che reggono quei workloads. E le due fatture si ignorano a vicenda.
La doppia struttura non è l'unica complessità. Il consumo di DBU varia di un fattore 3-4 a seconda che un workload giri come job pianificato o in un notebook interattivo. I tier di edizione moltiplicano ulteriormente la tariffa per DBU. Aggiunga il trasferimento dati cross-region e gli addebiti dei cluster inattivi e un team con workloads del tutto ragionevoli può ritrovarsi fatture mensili dal 50 al 200% superiori alle previsioni iniziali.
Questa guida analizza ogni voce di costo, mostra dove i team spendono in eccesso e illustra le pratiche di monitoraggio e governance che trasformano Databricks da incognita finanziaria in capacità operativa prevedibile.
Come funzionano i prezzi di Databricks e i suoi piani?
I prezzi di Databricks seguono un modello di consumo pay-as-you-go basato sui Databricks Units (DBU). Un DBU è una misura normalizzata della potenza di elaborazione, fatturata al secondo. La tariffa per DBU si moltiplica per il numero di unità consumate dal workload e il risultato corrisponde al costo software di Databricks. Il cloud provider fattura poi separatamente l'infrastruttura sottostante.
La piattaforma offre oggi tre tier di edizione su AWS: Standard, Premium ed Enterprise. Su Azure e GCP restano disponibili Standard e Premium, anche se Microsoft ha annunciato la dismissione del tier Standard su Azure per ottobre 2026. I nuovi clienti AWS e GCP partono ora da Premium come tier di base. Ogni upgrade introduce funzionalità aggiuntive di governance, sicurezza e ottimizzazione e alza di conseguenza la tariffa per DBU.
Standard, Premium ed Enterprise: cosa include ciascun tier?
Standard copre il data engineering di base e i notebook collaborativi. Non include Databricks SQL Workspace né gli strumenti di ottimizzazione SQL. Premium aggiunge Unity Catalog per la data governance, controlli di accesso basati sui ruoli, capacità di SQL analytics e le funzionalità di audit e compliance richieste dalla maggior parte dei team enterprise. Enterprise aggiunge supporto dedicato, strumenti avanzati per il ciclo di vita ML e prezzi negoziati per il consumo committed.
La scelta del tier conta per due motivi: idoneità funzionale e baseline di costo. Un team che esegue solo ETL automatizzati può restare su Standard. Un team che ha bisogno di SQL analytics per i professionisti BI, di governance su più workspace o del tracciamento del data lineage deve passare a Premium. La maggior parte delle organizzazioni di medie dimensioni si colloca su Premium e su quelle tariffe deve costruire i propri modelli di costo di riferimento.
Pricing a consumo o sconti per uso committed
Il pricing on-demand non comporta alcun impegno iniziale ed è adatto ai team che stanno ancora valutando i pattern dei propri workloads. I contratti committed use (chiamati Databricks Commit Units, o DBCU, su Azure) offrono sconti significativi in cambio di garanzie di consumo a 1 o 3 anni. Azure dichiara risparmi fino al 37% per un impegno DBCU triennale. AWS e GCP propongono strutture analoghe attraverso i rispettivi marketplace.
La soglia pratica per impegnarsi è semplice: se il suo team esegue workloads costanti e prevedibili e dispone di almeno 6 mesi di storico d'uso su cui ancorare la previsione, i commitments sono vantaggiosi. Se i workloads sono ancora in evoluzione o stagionali, l'on-demand preserva la flessibilità a un costo maggiore. Databricks mette a disposizione un calcolatore dei prezzi per ciascun cloud provider, utile a stimare il consumo di DBU prima di sottoscrivere un impegno.
Quanto costa davvero Databricks? L'analisi completa dei DBU
Pianificare il budget di Databricks senza conoscere i tipi di workload è la via più diretta verso una sorpresa in fattura. Il tipo di compute che alimenta il workload determina la tariffa DBU e la differenza è abbastanza ampia da incidere su ogni fattura mensile.
Tariffe DBU per tipo di workload
Jobs Compute esegue workloads pianificati e automatizzati: pipeline ETL, controlli di qualità dei dati, aggregazioni batch. I cluster si avviano all'inizio del job e si spengono al completamento. È la categoria di compute più economica. All-Purpose Compute supporta il lavoro interattivo nei notebook condivisi, l'analisi esplorativa e lo sviluppo. Quei cluster restano attivi finché qualcuno non li ferma. Il sovrapprezzo dell'uso interattivo riflette un'esposizione concreta al tempo di inattività: un cluster All-Purpose lasciato acceso tutta la notte da un singolo data scientist costa per tutta la notte.
I Databricks SQL Warehouse alimentano le query BI e la SQL analytics. I SQL warehouse serverless includono il costo della VM sottostante nella tariffa per DBU: la fattura si semplifica, ma il prezzo apparente del DBU sale. Per volumi di query sporadici, il serverless spesso fa risparmiare eliminando gli addebiti dei cluster inattivi. Per workloads SQL costanti e ad alto volume, un classic warehouse su istanze riservate offre in genere un'economia migliore.
Tariffe DBU approssimative per tipo di workload (AWS, tier Standard e Premium)
Tipo di compute
Tier Standard
Tier Premium
Ideale per
Jobs Compute (AWS)
~0,07 $/DBU
~0,15 $/DBU
ETL pianificati, pipeline batch
All-Purpose Compute (AWS)
~0,40 $/DBU
~0,55 $/DBU
Notebook interattivi, sviluppo
SQL Warehouse (AWS)
~0,22 $/DBU
~0,22 $/DBU
Query BI, SQL analytics
Serverless SQL (AWS)
N/D
~0,75 $/DBU*
Carichi SQL sporadici o a picchi
*Le tariffe serverless includono i costi delle VM sottostanti. Tariffe valide a marzo 2026; verifichi i valori attuali sulla pagina dei prezzi di Databricks prima di pianificare il budget, poiché variano per regione, tipo di istanza e cloud provider e sono soggette a modifica.
L'implicazione pratica: eseguire ETL di produzione su un cluster All-Purpose anziché su un cluster Jobs può aumentare la fattura DBU di quel workload di 3-4 volte, senza alcuna variazione del compute sottostante. Identificare e riclassificare quei workloads è di solito l'intervento di ottimizzazione a più alto ROI per un team CloudOps.
Storage, trasferimento dati e altri costi di servizio
Gli addebiti dell'infrastruttura cloud si sommano alla voce DBU. Ogni cluster Databricks gira su VM gestite dal provider e quelle VM sono fatturate alle tariffe standard. Su Azure, un cluster Small SQL Compute costa circa 2,64 $ all'ora in DBU e altri 3,89 $ all'ora in addebiti VM, portando il costo orario reale oltre i 6,50 $: più del doppio del solo dato DBU. I team che pianificano il budget basandosi solo sul calcolatore dei prezzi di Databricks e trascurano il lato infrastruttura cloud sottostimano regolarmente la spesa mensile totale dal 50 al 200%.
Il trasferimento dati aggiunge un altro livello. Spostare dati tra regioni genera addebiti di egress da parte del cloud provider. Lo storage Delta Lake su S3, ADLS o GCS accumula costi di object storage e di transazione. Funzionalità avanzate come Delta Live Tables, lo storage di Unity Catalog e l'AI Foundation Model Serving introducono ciascuna dimensioni di fatturazione proprie. Le funzionalità serverless, in particolare, presentano tariffe per DBU più alte perché incorporano nel prezzo unitario l'overhead di gestione dell'infrastruttura.
Come ottimizzare i costi di Databricks senza frenare l'engineering?
L'ottimizzazione dei costi di Databricks non è un audit una tantum. I workloads crescono, nascono nuove pipeline, i team sperimentano. Le pratiche di ottimizzazione che reggono in un contesto così dinamico sono quelle integrate nelle policy dei cluster, nei pattern architetturali e nell'infrastruttura di monitoraggio: non quelle salvate su una pagina wiki e poi dimenticate.
Right-sizing dei cluster e scaling automatico
La prima leva è l'assegnazione del tipo di workload. Ogni job batch di produzione che gira su All-Purpose Compute è un costo evitabile. Imporre Jobs Compute per i workloads pianificati tramite cluster policy elimina sistematicamente quella categoria di spreco. Le cluster policy vincolano anche la scelta del tipo di istanza, fissano un tetto al consumo massimo di DBU per cluster e impediscono il provisioning ad-hoc di nodi sovradimensionati.
La selezione della famiglia di istanze è la seconda dimensione del right-sizing su cui la maggior parte dei team lascia margini. La documentazione di ottimizzazione dei costi di Databricks associa i tipi di workload alle famiglie di istanze: memory-optimized per ML e workloads con shuffle pesanti, compute-optimized per structured streaming e job di manutenzione come OPTIMIZE e VACUUM, storage-optimized per analytics interattive e in cache, istanze GPU solo per workloads con librerie GPU-accelerated. Chi usa per default istanze general-purpose su tutti i workloads lascia sul tavolo un rapporto prezzo-prestazioni significativo.
L'auto-termination è il terzo controllo critico. I cluster All-Purpose dedicati al lavoro interattivo richiedono soglie di terminazione aggressive, in genere 15-30 minuti di inattività, per evitare addebiti notturni dovuti a una singola sessione di notebook dimenticata. Un'avvertenza importante: l'autoscaling standard dei cluster ha dei limiti nello scale-down dei workloads di structured streaming. Per quei casi specifici Databricks raccomanda Lakeflow Spark Declarative Pipelines con enhanced autoscaling. Applicare consigli di autoscaling generici alle pipeline di streaming senza tenere conto di questa distinzione può portare a cluster che non scalano verso il basso come previsto.
Le istanze Spot offrono un'altra strada per la riduzione dei costi nei workloads batch fault-tolerant. Tutti e tre i cloud provider supportano il pricing Spot per i cluster Databricks e i risparmi possono essere consistenti, spesso dal 60 all'80% rispetto alle tariffe VM on-demand. Il rovescio della medaglia è il rischio di interruzione, che rende le Spot inadatte alle pipeline time-critical ma molto efficaci per i job batch notturni con logica di retry integrata.
Il formato di storage è una leva di costo che molti team trascurano del tutto. Eseguire pipeline su Delta Lake invece che direttamente su Parquet, ORC o JSON riduce l'uptime del compute. Le ottimizzazioni di performance di Delta Lake accelerano l'esecuzione ETL, e questo si traduce in runtime di cluster più brevi e in meno DBU fatturati a parità di volume di dati. Chi ha ereditato pipeline non-Delta dovrebbe trattare la migrazione del formato come un vero intervento sui costi, non solo come un upgrade di affidabilità o governance.
Anche le impostazioni di default dello storage collegato sono una voce di costo che passa spesso inosservata. Databricks effettua il provisioning di volumi EBS (o l'equivalente block storage collegato su Azure e GCP) con ciascun cluster di default, e il dimensionamento è generoso. Alla maggior parte dei workloads non serve. Se un job non comporta operazioni di shuffle pesanti, spillage di memoria su disco o un fabbisogno significativo di storage temporaneo, quei volumi vengono provisionati, fatturati e restano inutilizzati. Verificare la configurazione di default dei volumi nelle cluster policy, e ridurre o rimuovere lo storage collegato dei job che non lo usano, è una riduzione dei costi a basso sforzo che si moltiplica su ogni cluster del workspace.
I runtime con Photon abilitato riducono ulteriormente il consumo di DBU accelerando l'esecuzione delle query sui workloads idonei. Il motore Photon non abbassa la tariffa per DBU, ma completa lo stesso calcolo in meno secondi, riducendo il totale di unità fatturate. Tutti i SQL warehouse includono Photon di default. Per le pipeline batch, abilitare Photon sui cluster Jobs Compute richiede una valutazione job per job, perché lo speedup varia in base alle caratteristiche del workload.
Monitoraggio dei costi, alerting e strategie di chargeback
I team non possono governare ciò che non vedono. Databricks espone i dati di utilizzo a livello di workspace e di cluster tramite le system table e le integrazioni di cost logging. Senza convogliare quei dati in un layer di cost analytics che mappi il consumo a team, progetti o business unit, le conversazioni sull'ottimizzazione restano troppo astratte per produrre cambiamenti.
L'applicazione dei tag a livello di workspace e cluster abilita l'attribuzione del chargeback. Quando ogni cluster porta un tag di centro di costo o di progetto, finance ed engineering possono confrontarsi su voci specifiche e non più su fatture aggregate. Quella precisione sposta la conversazione da "abbiamo speso troppo su Databricks" a "la pipeline ETL della feature X ha consumato il 40% del budget Jobs Compute del mese scorso". E queste sono conversazioni che producono azioni.
L'alerting sulle anomalie di consumo DBU rappresenta il livello di early-warning. Alert basati su soglia sulla spesa DBU giornaliera o settimanale intercettano i cluster fuori controllo prima che si trasformino in eccessi pluri-giornalieri. Gli alert di budget legati ai tag dei workspace responsabilizzano i singoli team sulla propria spesa. Attribuzione, alerting e una cadenza di revisione settimanale trasformano la gestione dei costi in una pratica continua, non in un progetto di pulizia occasionale.
Databricks Intelligence di DoiT fornisce questo livello di visibilità out-of-the-box, combinando il monitoraggio in tempo reale dei costi DBU con il rilevamento delle anomalie, l'attribuzione dei workloads e raccomandazioni di governance automatizzate. I team che lo utilizzano insieme a Cloud Analytics possono correlare la spesa Databricks ai KPI di business e alle metriche di velocity dell'engineering, dando al FinOps il contesto per distinguere la spesa inutile dall'investimento produttivo.
Databricks o le alternative: dove offre il valore migliore?
Il confronto giusto tra le piattaforme non passa per le tariffe DBU di facciata. Passa per il costo totale di proprietà sull'intero stack: infrastruttura, operations, personale e idoneità funzionale rispetto all'architettura esistente.
Confronto tra piattaforme: Databricks e le principali alternative
Piattaforma
Modello di pricing
Punto di forza
Da considerare
Databricks
DBU + infra cloud (doppia fattura)
Lakehouse unificato, workloads ML/Spark
Il modello DBU richiede gestione costante dei costi
AWS EMR
Ore di istanze EC2 + sovrapprezzo EMR
Costo per job inferiore; flessibilità multi-framework
Maggior overhead operativo; UX sviluppatore meno curata
Google Dataproc
Ore VM + sovrapprezzo Dataproc (~1 cent/vCPU/h)
Provisioning rapido (~90 sec); GCP-native
Valore migliore solo all'interno dell'ecosistema GCP
Azure Synapse
DWU/cDWU o byte processati serverless
Forte integrazione Microsoft; BI+Spark unificati
Curva di apprendimento ripida; affidabilità altalenante su scala
AWS EMR offre costi di compute per job inferiori per workloads batch ad alta intensità Spark, ma scarica più complessità operativa sul team. Chi adotta EMR investe in genere in attività dedicate di gestione, tuning e troubleshooting dei cluster che Databricks copre attraverso un'infrastruttura managed. Un team analytics di medie dimensioni che processa 10 TB al mese potrebbe spendere tra 8.000 e 12.000 $ con Databricks (infrastruttura AWS inclusa) contro 5.000-8.000 $ con servizi AWS-native equivalenti, ma con un overhead operativo significativamente più alto da assorbire nel secondo scenario.
Google Dataproc effettua il provisioning di cluster Hadoop e Spark in circa 90 secondi a tariffe per VM competitive, con un piccolo sovrapprezzo per il servizio managed. È conveniente per i team già fortemente integrati nell'ecosistema GCP, ma non offre l'esperienza di piattaforma analytics unificata (notebook, SQL workspace, Delta Lake, Unity Catalog) propria di Databricks. Chi sceglie Dataproc si fa carico di un maggior assemblaggio della toolchain circostante.
Azure Synapse si integra strettamente con Power BI, Azure Data Lake Storage e lo stack di identità Microsoft, e diventa la scelta naturale per le organizzazioni già su Azure e radicate in T-SQL. Gestisce bene workloads SQL serverless e dedicati, ma le pipeline complesse di data engineering e i workloads ML richiedono spesso strumenti aggiuntivi o un'integrazione di ritorno con Databricks.
Databricks costa più per DBU rispetto alle alternative di sola infrastruttura, ma quel sovrapprezzo finanzia una piattaforma unificata che riduce la complessità della toolchain, i tempi di onboarding degli sviluppatori e l'onere operativo di gestire sistemi separati per data engineering, analytics e ML. Se il compromesso porti valore dipende dal mix di workloads del suo team e dalla maturità dell'engineering.
Come fanno i team migliori a mantenere prevedibile la spesa Databricks su larga scala?
La complessità dei prezzi di Databricks non è di per sé un rischio finanziario. Lo diventa quando i team non hanno visibilità su ciò che guida il consumo, non hanno governance sulla configurazione dei cluster e trattano la revisione dei costi come un appuntamento trimestrale anziché come una pratica continua.
I team che gestiscono con successo la spesa Databricks condividono alcune scelte strutturali. Separano i tipi di workload by design, usando di default Jobs Compute per i batch di produzione e All-Purpose solo per lo sviluppo interattivo. Applicano cluster policy che vincolano la selezione delle istanze e il comportamento in idle. Mantengono un'attribuzione dei costi per team tramite tag e rivedono i dati di consumo con cadenza settimanale per intercettare le anomalie prima che si aggravino.
Quella disciplina operativa scala anche senza un FinOps a tempo pieno. La giusta infrastruttura di monitoraggio fa emergere i segnali. Gli strumenti di governance impongono guardrail senza frenare l'engineering. L'esperienza sul campo traduce i pattern di consumo in aggiustamenti concreti man mano che i workloads evolvono.
DoiT mette insieme visibilità, governance ed esperienza in un'unica piattaforma. I team che eseguono Databricks su larga scala usano Databricks Intelligence per automatizzare il monitoraggio dei costi e il rilevamento delle anomalie, e collaborano con gli esperti cloud di DoiT per tradurre i pattern di consumo in raccomandazioni di ottimizzazione. Il risultato è una spesa Databricks che cresce insieme ai dati senza generare volatilità finanziaria.
Scopra come DoiT aiuta i team CloudOps e FinOps a ottimizzare in modo continuo la spesa Databricks senza frenare l'innovazione. Parli con un esperto.
Domande frequenti sui prezzi di Databricks
Cos'è una Databricks Unit (DBU)?
Una DBU è un'unità normalizzata di capacità di elaborazione che Databricks usa per misurare e fatturare il consumo di compute. L'uso di DBU si accumula al secondo mentre un cluster è in esecuzione, a una tariffa che varia in base al tipo di istanza, al tipo di workload (Jobs, All-Purpose, SQL) e al tier di edizione. Moltiplicando i DBU consumati per la tariffa per DBU applicabile si ottiene il costo software di Databricks. Quel costo compare su una fattura distinta da quella degli addebiti infrastrutturali del cloud provider.
Perché la mia fattura Databricks include addebiti da due provider diversi?
Databricks fattura il proprio software di piattaforma in DBU. Il suo cloud provider (AWS, Azure o GCP) fattura separatamente le macchine virtuali, lo storage e l'egress di rete che eseguono i suoi workloads Databricks. Le due fatture sono indipendenti e nessuno dei due provider ha visibilità sugli addebiti dell'altro. I team che pianificano il budget basandosi solo sul calcolatore dei prezzi di Databricks e trascurano il lato infrastruttura cloud sottostimano regolarmente i costi mensili totali dal 50 al 200%.
Quanto costa Databricks al mese per un team tipo?
Un piccolo team che esegue ETL giornalieri e analisi ad-hoc su AWS spende in genere tra 1.500 e 3.000 $ al mese, sommando DBU Databricks e infrastruttura cloud. I team di medie dimensioni con volumi di dati più importanti e workloads più complessi si attestano comunemente tra 5.000 e 15.000 $ al mese, o anche oltre. Il costo totale dipende dal volume dei workloads, dalla scelta del tipo di compute, dal tier di edizione, dal cloud provider e da quanto è governato il comportamento dei cluster in idle. La singola variabile a maggiore impatto è se i workloads batch di produzione girino su Jobs Compute o su All-Purpose Compute.
Qual è il modo più rapido per ridurre i costi di Databricks?
Tre azioni offrono i risparmi maggiori con un rischio minimo per l'engineering: spostare i workloads batch di produzione da All-Purpose Compute a Jobs Compute (in genere taglia i costi DBU di quei workloads dal 60 al 75%), imporre l'auto-termination su tutti i cluster All-Purpose con una soglia di idle di 15-30 minuti e usare istanze Spot/preemptible per i job batch fault-tolerant. Insieme, queste tre modifiche possono ridurre la spesa Databricks totale dal 40 al 60% nei team che non le hanno ancora applicate.
I prezzi di Databricks variano tra AWS, Azure e GCP?
Sì. Jobs Compute sul tier Standard costa circa 0,07 $ per DBU su AWS, 0,10 $ su GCP e 0,15 $ su Azure. All-Purpose Compute è più allineato tra i provider, intorno a 0,40 $ per DBU sul tier Standard. Azure prevede inoltre costi aggiuntivi di managed storage per dischi e blob, e le sue integrazioni native Microsoft aggiungono complessità ai confronti diretti dei costi cross-cloud. Il pricing del tier Enterprise prevede tariffe negoziate e non viene esposto pubblicamente da nessun provider.