Power BI e ADBC: i driver ODBC escono dai connettori

Se i tuoi report Power BI leggono dati da Snowflake, Databricks o Google BigQuery, nei prossimi mesi cambia il motore che li collega. Microsoft sta sostituendo i driver ODBC incorporati in questi connettori con i nuovi driver ADBC. Non è una funzione nuova da provare quando c’è tempo: è un cambio infrastrutturale con date già pianificate, e chi non si prepara rischia refresh che si fermano.

Cosa cambia nei connettori Power BI

Un driver è il componente che permette a Power BI di parlare con una sorgente dati. Finora molti connettori usavano driver ODBC (Open Database Connectivity) della famiglia Simba, inclusi nel prodotto. Al loro posto arrivano i driver ADBC (Apache Arrow Database Connectivity), uno standard pensato per trasferire grandi volumi di dati in formato colonnare, senza conversioni intermedie. Secondo Microsoft portano anche miglioramenti di sicurezza, come la gestione più sicura della memoria.

I connettori coinvolti sono Databricks e Azure Databricks, Snowflake, Google BigQuery, Dremio, Impala e Spark. Hive invece viene deprecato senza sostituto. Il cambio riguarda solo i driver incorporati: se usi il connettore ODBC generico con un driver installato a parte, per te non cambia nulla.

Il calendario indicato nella documentazione Microsoft, con tutte le date segnate come pianificate, è questo.

• Da ottobre 2026 Microsoft inizia ad attivare per gradi l’impostazione tenant che rende ADBC il driver predefinito.
• All’inizio del primo trimestre 2027 è prevista la rimozione dei driver ODBC dal servizio Power BI.
• Nella primavera 2027 i driver ODBC non saranno più inclusi in Power BI Desktop e nel gateway.

Il driver usato dipende da un parametro della query M chiamato Implementation. Con il valore “2.0” si usa ADBC, con “1.0” si resta su ODBC. Se il parametro non c’è, decide l’impostazione del tenant o del workspace. Per Databricks e Azure Databricks il connettore ADBC è già disponibile in versione generale.

Il punto critico: le query bloccate su ODBC

Le connessioni senza parametro passeranno ad ADBC da sole quando il tenant cambia impostazione. Il rischio vero è nelle query che hanno Implementation=”1.0″ scritto esplicitamente e non passano da un gateway. Microsoft le classifica come destinate a fallire al momento del passaggio: il refresh smette di funzionare.

C’è poi il caso del gateway on premises. I refresh che passano dal gateway continuano a usare ODBC, perché usano i driver installati con il gateway stesso. È un rinvio, non una soluzione: quando le nuove versioni del gateway non avranno più ODBC, anche quella strada si chiude. E attenzione ai test. Se provi ADBC passando dal gateway, in realtà stai ancora usando ODBC. Per una prova valida serve una connessione cloud.

Anche Power BI Desktop ha una particolarità. Non esiste un interruttore per file: una query esistente resta sul driver con cui è stata creata. Per verificarla su ADBC bisogna eliminarla, aggiungere di nuovo la sorgente e riselezionare i campi.

Un esempio dalla logistica

Pensa a un distributore che tiene ordini, giacenze e spedizioni su Snowflake. Ogni notte un modello semantico si aggiorna e alle 8 il responsabile di magazzino apre la dashboard degli ordini inevasi. Mesi fa qualcuno, per risolvere un problema, ha fissato Implementation=”1.0″ in una query. Nessuno se lo ricorda. Il giorno in cui ODBC sparisce dal servizio, quel refresh fallisce e la mattina il magazzino lavora con i numeri del giorno prima, senza saperlo.

Per evitarlo Microsoft mette a disposizione pq-adbc-advisor, un notebook Fabric in sola lettura. Scansiona un workspace e per ogni modello semantico, dataflow e pipeline indica se è pronto, se va rivisto o se fallirà. Non modifica le query, quindi si può lanciare senza timori. Gli amministratori possono estendere la scansione a tutto il tenant.

Il percorso che consiglio è quello suggerito anche da Microsoft. Prima l’inventario con il notebook. Poi un workspace pilota con ADBC attivo tramite l’override a livello di workspace. Infine il confronto, report per report, di numero di righe, tipi di colonna e durata del refresh rispetto a ODBC. Solo dopo si decide se attivare ADBC per tutto il tenant.

Il mio punto di vista

Il cambio ha senso. ADBC è più adatto ai grandi volumi tipici di Snowflake e Databricks, e togliere driver di terze parti dal prodotto semplifica la manutenzione. Il limite è la comunicazione: è un cambio di motore, non una funzione visibile, e per questo rischia di passare inosservato finché qualcosa non si rompe. Inoltre non c’è un modo per restare su ODBC per sempre. L’unica scelta reale è quando migrare, non se.

Le date sono ancora indicative e Microsoft dice che avviserà prima delle scadenze. Non aspetterei l’avviso. Il lavoro di verifica è piccolo se fatto adesso, con calma, e diventa urgente se fatto a febbraio sotto pressione. Se segui le novità di Power BI, a ottobre ho scritto anche del Gantt nativo nei report, una novità che chi gestisce report di progetto o di produzione può già provare in anteprima.

Da dove partire

Questa settimana fai una sola cosa: chiedi a chi gestisce Power BI quante connessioni verso Snowflake, Databricks o BigQuery avete e quante passano dal gateway. Se nessuno sa rispondere, hai già trovato il primo problema da risolvere.

Se non sai quali report dipendono da questi connettori, scrivimi per un audit gratuito dei tuoi dati e report: mappiamo insieme le connessioni a rischio prima che un refresh si fermi. Richiedi l’audit dalla pagina contatti.

Fonti

• Microsoft Learn, Transition from ODBC to ADBC drivers in Power BI and Microsoft Fabric
• Microsoft Fabric Community, Databricks ADBC connector for Power BI and Microsoft Fabric (Generally Available)
• Microsoft Learn, Configure ADBC or ODBC driver for Power BI (Azure Databricks)
• Microsoft Learn, What’s new in Power BI, ottobre 2026