Snowflake vs Databricks: la sfida definitiva

I dati

Il nostro benchmark utilizza TPC-H con Scale Factor 1000. Il dataset ha circa 6 miliardi di righe nella tabella più grande. Sia Snowflake sia Databricks dispongono di dati TPC-H, ma le dimensioni non coincidono e i dataset più grandi non sono identici. Per un confronto davvero alla pari occorre fare l'ETL dei dati da Snowflake a Databricks. Il modo più semplice è usare uno strumento dedicato come Estuary, oppure può farlo manualmente.

Databricks include:

• tpcds_sf1 e sf1000
• tpch con 30 milioni di righe. Circa la metà dello scale factor 10 di Snowflake, che ne ha 60 milioni.

Snowflake include:

• tpcds_sf10 e 100
• tpch con scale factor 1, 10, 100 e 1000

Nessuna sorpresa: le piattaforme hanno reso difficile il confronto delle performance non fornendo dati di esempio sovrapponibili. 🤨

Scenari

Abbiamo utilizzato queste query standard in 3 scenari:

• Esecuzione di tutte le 22 query in modo sequenziale. In questo scenario, solo la query 1 parte da cold start e ogni query successiva può beneficiare della cache del warehouse generata dalle precedenti.
• Esecuzione di tutte le 22 query in modo concorrente. Qui testiamo la capacità della piattaforma di eseguire più query contemporaneamente e di verificare se si osserva uno scaling orizzontale.
• 5 query in cold start. Abbiamo eseguito una piccola selezione di query, con complessità e stile variabili, per vedere come si comportano le piattaforme partendo da un warehouse freddo.

Workloads CTAS: dato che le query standard del benchmark producono risultati piuttosto piccoli, per lo più altamente aggregati, non rappresentano bene un vero workload CTAS, perché il payload in scrittura sarebbe troppo ridotto per stressare il throughput. Per testare le operazioni write-intensive abbiamo creato 5 varianti che materializzano grandi result set con forme di dato diverse, da tabelle strette con miliardi di righe a tabelle denormalizzate molto larghe, in modo da confrontare le performance di scrittura su forme di tabella e complessità di query differenti.

Workloads DML: qui eliminiamo 1 mese di dati dalla tabella e li reinseriamo. 1 mese rappresenta circa l'1% dei dati, ovvero 6 milioni di righe. È un test sia dell'efficienza del query pruning (mirato sul mese specifico) sia dell'efficienza DML.

Warehouse

Per ogni run e scenario viene generato automaticamente un nuovo warehouse all'inizio (run + scenario), che viene distrutto subito al termine del lavoro. Questo ci permette di osservare il costo totale di un warehouse in isolamento, eliminando dal quadro il tempo di inattività.

Un Databricks Serverless SQL Warehouse è grossomodo equivalente a un Snowflake Warehouse di una taglia superiore. Ad esempio, uno Small in Databricks corrisponde più o meno a un Medium in Snowflake. Abbiamo eseguito i 4 scenari sopra su queste combinazioni di warehouse.

• Snowflake Medium vs Databricks Small
• Snowflake Large vs Databricks Medium
• Snowflake XL vs Databricks Large

Questo confronto tra dimensioni trova conferma nella documentazione di Snowflake e Databricks, dove il Worker Count di Databricks è considerato equivalente ai Credit di Snowflake.

Attribuzione dei costi

Volevamo un'attribuzione dei costi il più precisa possibile. Per riuscirci, usiamo warehouse isolati come descritto sopra e ci basiamo sui dati di fatturazione effettivi (in credit o DBU) per l'intera vita del warehouse. Alla fine applichiamo un calcolatore di costo flessibile che assegna diversi costi per credit o per DBU ai risultati, in modo da simulare vari tier di piattaforma. Con questo approccio eliminiamo ogni complessità legata all'attribuzione dei costi per query concorrenti, agli incrementi minimi di fatturazione e così via. Ci limitiamo a guardare il costo totale dello scenario.

Quando mostriamo il costo per singole query anziché per run interi, il costo viene attribuito a quella query in proporzione al suo tempo di esecuzione. In pratica, il costo totale del run (o della vita di quel warehouse) viene distribuito sulle query, così i numeri tornano.

Confronto dei costi

Il Databricks Standard Tier è in dismissione (probabilmente già ritirato a ottobre 2025). Quindi, confrontando il listino più basso di ciascuna piattaforma, il paragone è tra Snowflake Standard a 2 $/credit e Databricks Enterprise a 0,70 $/DBU. Riteniamo che sia un confronto equo: il tier Snowflake Standard è una versione completa di Snowflake, e l'unica funzionalità importante che manca è il time travel. Sappiamo però che molti lettori vorranno confrontare Enterprise vs Enterprise. Per questo mostriamo entrambi: Databricks a 0,70 $/DBU vs Snowflake a 2 $/credit e a 3 $/credit.

Storico dei run e analisi

Gli ID delle query e le statistiche di esecuzione vengono loggati immediatamente in un duckdb locale. I dati sono memorizzati a livello di Query ID (oltre a Run ID, Warehouse e scenario). Le view di reporting aggregano i dati per permetterci di trarre conclusioni sull'intero run.

Query

Le query del benchmark si trovano qui. (Anche se l'SQL sembra hard-coded sul dataset con scale factor 100x, il nome della tabella viene sostituito dinamicamente a runtime con lo scale factor indicato nel file di configurazione. Tutti i test sono stati eseguiti su scale factor 1000x.) Abbiamo organizzato le 22 query in categorie basate su complessità e numero di join. La suddivisione dettagliata per categoria si trova qui, ma questo screenshot ne offre una sintesi.

Obiettivo e setup

Obiettivo: eseguire le query in sequenza riproduce ciò che si vive seduti alla scrivania, lanciando query su queste piattaforme dati. È l'esperienza tipica dell'utente finale quando esegue una SELECT. Questa misurazione consente di confrontare query per query e warehouse per warehouse, in modo simile alla maggior parte dei benchmark TPC-H.

Setup: il setup è semplicissimo: lanciamo 22 query, una alla volta. In tutti gli scenari il warehouse viene creato all'inizio del run e distrutto subito dopo il termine dell'ultima query. I risultati vengono loggati immediatamente nel duckdb.

In questo scenario solo la query 1 è un vero "cold start"; le query da 2 a 22 sono considerate calde, perché il warehouse resta attivo per tutto il run.

Risultati

Snowflake a 2 $/credit vs Databricks a 0,70 $/DBU:

Snowflake a 3 $/credit vs Databricks a 0,70 $/DBU:

Si nota che a 2 $/credit Snowflake è il 34% più veloce e il 17% più economico. Portando Snowflake a 3 $/credit, Databricks diventa il 20% più economico.

Obiettivo e setup

Obiettivo: questo scenario simula il caricamento di un dashboard di BI o l'esecuzione di job in cui decine di query partono simultaneamente. L'obiettivo è testare come ciascuna piattaforma gestisce la concorrenza.

Setup: abbiamo usato Python per lanciare tutte le 22 query insieme e registrarne i risultati.

Risultati

Snowflake a 2 $/credit vs Databricks a 0,70 $/DBU:

Snowflake a 3 $/credit vs Databricks a 0,70 $/DBU:

In entrambi gli scenari, Snowflake si è rivelato più veloce ed economico! Significa che, per workloads concorrenti, Snowflake sembra essere il vincitore (in questo scenario di benchmark).

Vediamo ora come ciascuna piattaforma ha gestito la concorrenza. Se la concorrenza fosse gestita in modo perfetto (senza code né competizione per le risorse), il tempo totale del test concorrente dovrebbe essere circa pari a quello della query più lunga eseguita da sola.

Piattaforma	Dimensione warehouse	Query isolata più lunga	Wallclock concorrente	Rapporto
Databricks	SMALL	134,5 sec	369,5 sec	2,7x
Databricks	MEDIUM	64,5 sec	296,0 sec	4,6x
Databricks	LARGE	32,9 sec	176,5 sec	5,4x
Snowflake	MEDIUM	94,7 sec	278,7 sec	2,9x
Snowflake	LARGE	45,2 sec	142,8 sec	3,2x
Snowflake	XLARGE	20,7 sec	99,7 sec	4,8x

I dati mostrano che entrambe le piattaforme pagano un prezzo per la concorrenza (eseguire più query insieme le rallenta tutte oppure genera code), ma in questo confronto Snowflake ha un rapporto migliore.

Eseguendo 22 query concorrenti, vediamo che Snowflake è scalato fino a 4 cluster per Medium e Large e ne ha usati solo 3 sull'XL. Per questo l'XL è costato solo pochi centesimi in più rispetto al Large.

Purtroppo gli stessi dati non sono disponibili su Databricks. Non sono riuscito a trovare un modo per sapere quanti cluster siano stati effettivamente utilizzati.

Obiettivo e setup

Obiettivi: misurare i tempi di esecuzione delle query senza "cache del warehouse" e capire se il tempo di avvio del warehouse incide sui risultati.

Entrambe le piattaforme sfruttano una "cache del warehouse" o "Photon acceleration", una cache residente sulla VM che esegue la query. Eseguendo le query in sequenza, la query 2 può beneficiare di parte della cache generata dalla query 1, e così via.

Setup: per vedere come si comportano le query in assenza di cache, abbiamo progettato uno scenario che spegne il warehouse tra un'esecuzione e l'altra. In questo caso abbiamo deciso di non eseguire tutte e 22 le query, perché avrebbe comportato una spesa eccessiva.

Il tempo di creazione del warehouse non viene conteggiato nel wall clock totale, ma il tempo di avvio del warehouse SÌ.

Le query

Query	Categoria	Complessità	Descrizione
Q1	Aggregazione e filtro semplici	Bassa (warm-up)	Aggregazioni multiple (SUM, AVG, COUNT) con GROUP BY su una tabella da 600M di righe
Q3	Join semplici (2-4 tabelle)	Media (OLAP standard)	Join a 3 vie con aggregazione e filtro per data
Q5	Join complessi (5+ tabelle)	Alta (stress test)	Join a 6 vie con calcolo revenue e filtro geografico
Q10	Join semplici (2-4 tabelle)	Media (OLAP standard)	Join a 4 vie con filtro selettivo e GROUP BY ad alta cardinalità
Q18	Subquery e semi-join	Media (OLAP standard)	Subquery IN con filtro di aggregazione (HAVING)

Query Categoria Complessità Descrizione Q1 Aggregazione e filtro semplici Bassa (warm-up) Aggregazioni multiple (SUM, AVG, COUNT) con GROUP BY su tabella da 600M righe Q3 Join semplici (2-4 tabelle) Media (OLAP standard) Join a 3 vie con aggregazione e filtro data Q5 Join complessi (5+ tabelle) Alta (stress test) Join a 6 vie con calcolo revenue e filtro geografico Q10 Join semplici (2-4 tabelle) Media (OLAP standard) Join a 4 vie con filtro selettivo e GROUP BY ad alta cardinalità Q18 Subquery e semi-join Media (OLAP standard) Subquery IN con filtro di aggregazione (HAVING)

Risultati

Qui Snowflake si è rivelato più veloce di diversi ordini di grandezza e leggermente più economico.

Entrando nel dettaglio, abbiamo riscontrato che il tempo di avvio di Databricks è di circa 7 secondi per avvio, mentre quello di Snowflake è inferiore al secondo in tutti i casi.

Obiettivo e setup

Obiettivo: misurare le operazioni write-intensive tipiche dei task di data engineering e dei progetti dbt. Le query TPC-H standard sono ottimizzate per letture analitiche: scansionano grandi dataset ma restituiscono risultati piccoli e aggregati (somme, medie, top-N). Questo mette alla prova esecuzione e ottimizzazione delle query, ma non le performance di scrittura. Volevamo capire come si confrontano Snowflake e Databricks scrivendo miliardi di righe con forme di dato diverse.

Setup: abbiamo creato 5 varianti CTAS, ognuna pensata per testare un pattern di scrittura specifico:

1. Narrow Tall (6 mld righe × 4 colonne): una semplice proiezione della tabella LINEITEM con sole 4 colonne chiave (l_orderkey, l_partkey, l_quantity, l_extendedprice). Mette alla prova il throughput massimo di righe con overhead minimo di colonne.
2. Standard Tall (6 mld righe × 16 colonne): una copia completa della tabella LINEITEM (SELECT * FROM LINEITEM). Rappresenta un pattern tipico di duplicazione o archiviazione di grandi tabelle fact. (Di solito si userebbe Clone, ma oggi non stiamo facendo benchmark su operazioni Clone.)
3. Medium Wide (1,5 mld righe × 30 colonne): un join delle tabelle ORDERS, CUSTOMER, NATION e REGION. Mette alla prova la combinazione di performance in lettura e scrittura con complessità di JOIN moderata e uno schema più largo, tipico della denormalizzazione di uno star schema.
4. Very Wide (6 mld righe × 59 colonne): un join completamente denormalizzato su tutte le tabelle TPC-H (LINEITEM, ORDERS, CUSTOMER, SUPPLIER, PART, PARTSUPP, NATION, REGION). Rappresenta il caso estremo di tabelle larghe e pre-unite, comuni negli analytics layer.
5. Filtered (2 mld righe × 16 colonne): LINEITEM filtrata sugli ordini spediti dopo il 1995 (WHERE l_shipdate >= '1995-01-01'). Testa il throughput di scrittura per copie parziali di tabella, un pattern comune nelle pipeline di dati incrementali.

Risultati

Snowflake a 2 $/credit vs Databricks a 0,70 $/DBU:

Snowflake a 3 $/credit vs Databricks a 0,70 $/DBU:

Snowflake a 2 $/credit vs Databricks a 0,70 $/DBU, escludendo l'outlier della query "Very Wide":

Snowflake a 3 $/credit vs Databricks a 0,70 $/DBU, escludendo l'outlier della query "Very Wide":

Possiamo affermare con sicurezza che, in questo scenario di benchmark, Databricks ha un netto vantaggio nella creazione di tabelle di grandi dimensioni tramite CTAS.

Obiettivo e setup

Obiettivo: Delete + Insert è un pattern comune per aggiornare i dati in modo incrementale. È il modo più efficace per trasformare segmenti mirati di dati su tabelle di grandi dimensioni, e quindi uno scenario importante da testare.

Setup: all'inizio del run viene creata una copia dei dati sorgente del benchmark. Questa operazione non viene conteggiata nel tempo di esecuzione né nei costi. Una volta creata la copia, parte il processo di benchmark: vengono cancellati 1 mese di dati, circa 6M di righe, ovvero circa l'1% del totale, e poi viene reinserito lo stesso mese dalla sorgente. Si simula così uno scenario ETL reale in cui i record corrispondenti vengono cancellati e reinseriti. Nota: non abbiamo usato merge perché è noto che delete + insert offre performance migliori rispetto a merge.

Risultati

Snowflake a 2 $/credit vs Databricks a 0,70 $/DBU:

Snowflake a 3 $/credit vs Databricks a 0,70 $/DBU:

I risultati sono davvero interessanti. Il motivo per cui Snowflake M, L e XL elaborano i dati in meno di 20 secondi è un eccellente query pruning. I 6 miliardi di righe vengono ridotti e gestiti come se fossero 6 milioni, quindi l'operazione gira su un dataset molto più piccolo. Il warehouse Snowflake Small impiega più del doppio del tempo perché va in spillage sia nello step di delete sia in quello di insert.

Su Databricks accade qualcosa di simile. Vediamo una concentrazione tra 35 e 39 secondi per tutte le dimensioni di warehouse. Databricks riduce efficacemente la dimensione del dataset, quindi M, L e XL la gestiscono senza problemi. Ma non con la stessa velocità di Snowflake.

Se desidera eseguire questi test in autonomia, è relativamente semplice. Come anticipato, la prima cosa da fare è l'ETL del dataset 1000x da Snowflake a Databricks. È la parte più difficile e l'unica per cui non forniamo automazione, perché entrano in gioco troppe variabili. Anche qui, le consiglio di usare Estuary!

Una volta che i dati sono disponibili nel suo account Databricks, può seguire la guida di getting started qui. Le basta avere UV e Snowflake CLI installati, configurare il file .env eseguendo uv run setup_config.py, e potrà iniziare a lanciare benchmark! Il readme contiene molti esempi su come eseguire singoli scenari, dimensioni di warehouse o l'intera suite.

Dopo l'esecuzione del benchmark, deve attendere 2 ore affinché i dati di fatturazione si stabilizzino. Poi può eseguire uv run enrich.py per arricchire i risultati con i dati di billing. Quando è pronto per visualizzare i risultati, segua i passi del readme anche per questa parte.

I risultati dimostrano in modo chiaro che Snowflake Standard Edition è la piattaforma più conveniente in tutti gli scenari, tranne quello CTAS, in cui Databricks supera Snowflake sia per costi sia per performance. Passando a Snowflake Enterprise Edition a 3 $/credit, in alcuni scenari Databricks diventa più economico. Lo ripetiamo: i benchmark sono solo benchmark, quindi faccia sempre i test sui suoi dati!

Jeff è un consulente di Data e Analytics con oltre 15 anni di esperienza nell'automazione degli insight e nell'uso dei dati per governare i processi di business. Sul fronte tecnologico è specializzato in Snowflake + dbt + Tableau. Sul fronte dei settori, ha esperienza in Utility Pubbliche, Trial Clinici, Editoria, CPG e Manifatturiero. Lo contatti pure quando vuole: [email protected].