Databricks, Snowflake, BigQuery o Fabric: come si sceglie?

Databricks, Snowflake, BigQuery e Microsoft Fabric sono quattro piattaforme dati cloud della stessa famiglia, pensate per immagazzinare e interrogare grandi volumi di dati aziendali, ma con impostazioni architetturali diverse fin dalle fondamenta. Snowflake gestisce lo storage in modo proprietario all'interno del proprio servizio. Databricks lavora su un lakehouse costruito su formati aperti, dentro bucket di proprietà del cliente, con Spark come motore di calcolo e Delta Lake come formato tabellare di riferimento. BigQuery è un motore serverless integrato nel cloud Google, senza cluster da dimensionare o gestire. Fabric accorpa tutti i carichi analitici su un unico lago, OneLake, dove ogni motore legge e scrive una sola copia del dato in formato Delta Parquet. Nessuna delle quattro impostazioni è superiore in assoluto: ciascuna bilancia in modo diverso controllo, apertura del dato e sforzo operativo, ed è quel compromesso, non una funzione isolata, a determinare quale si adatti meglio a un contesto specifico.

La differenza che conta davvero

Ciò che non cambia, mentre le differenze storiche si erodono, è dove il dato finisce per stare quando nessuno interviene. Tutte e quattro oggi possono tenere tabelle in formati tabellari aperti dentro storage del cliente: Snowflake e BigQuery con tabelle Iceberg su storage esterno, Databricks come impostazione nativa in Delta Lake, Fabric scrivendo in Delta Parquet su OneLake. Cambia ciò che accade se nessuno decide nulla: su Databricks e su Fabric il dato è già in formato aperto, su Snowflake e BigQuery le tabelle native restano dentro il servizio e la configurazione aperta va scelta esplicitamente. In tutti e quattro i casi resta l'attrito del catalogo e delle pipeline, che nessun formato aperto azzera. BigQuery e Fabric aggiungono l'assenza di cluster da amministrare, al prezzo di restare rispettivamente dentro il perimetro Google Cloud e dentro quello Microsoft. Sulla distinzione tra magazzino strutturato e lago di file grezzi vale la voce su data warehouse e data lake.

La trappola del confronto di prezzo

Le quattro piattaforme fatturano in unità diverse e non comparabili. Snowflake vende crediti calcolati sul tempo di utilizzo dei propri warehouse virtuali. Databricks vende DBU (Databricks Unit), un'unità che varia per tipo di workload e per il cloud sottostante. BigQuery fattura in due modelli diversi tra loro: a consumo sui byte processati da ogni query, oppure a capacità in slot-ora riservati, quindi l'unità cambia anche restando dentro una sola piattaforma. Fabric vende capacità in CU (Capacity Unit), un pool unico che copre tutti i carichi, con lo storage OneLake fatturato a parte al giga e fuori dalle CU. Un preventivo che confronta "il costo di Databricks" con "il costo di Fabric" senza prima normalizzare lo stesso carico di lavoro sta confrontando unità senza un denominatore comune.

Un esempio enterprise

Un'azienda manifatturiera italiana con impianti IoT che generano milioni di eventi al giorno valuta le quattro piattaforme per il proprio hub dati centrale. Se il gruppo è già dentro un solo cloud, e ha già licenze e identità in quell'ambiente, il criterio decisivo diventa l'attrito di integrazione, che spinge verso la piattaforma nativa di quel cloud. Se le competenze in casa sono soprattutto SQL, un motore che si guida in SQL puro parte con un costo di formazione più basso; se invece esistono già pipeline scritte in Spark, riscriverle ha un costo che il preventivo iniziale spesso non include. Se prevale l'esigenza di non gestire infrastruttura, un motore serverless riduce il carico sul team dati.

Perché conta per chi decide

I criteri reali sono tre domande a monte. Su quale cloud è già l'azienda, e quali vincoli di residenza del dato si applicano. Quali competenze esistono già in casa, perché la formazione è una voce di costo in entrambe le direzioni. Quanto conta possedere fisicamente i propri dati in un formato aperto contro quanto conta non manutenere nessuna infrastruttura. E vale per tutte e quattro allo stesso modo il vendor lock-in, presente in ciascuna sotto forma diversa (storage proprietario, unità di calcolo legate a un runtime, integrazione stretta con un solo cloud). Chi cerca un modello costruito attorno a un'ontologia operativa, anziché a tabelle da interrogare, guarda a Palantir Foundry, un'opzione ulteriore che entra nello stesso confronto quando il problema non è solo analitico ma operativo.