Import, DirectQuery o Direct Lake: quale modalità scegliere in Power BI

Regola breve: Import finché puoi — è la modalità più veloce e la più completa dal punto di vista funzionale. DirectQuery quando i dati devono essere freschi al secondo o il volume non entra in memoria. Direct Lake quando hai una capacità Fabric F-SKU e i dati sono già tabelle Delta in OneLake: ti dà la velocità di Import senza il refresh di Import. Questa scelta va fatta all'inizio, perché cambiarla dopo significa quasi sempre rifare il modello.

Import — i dati dentro il modello

Al refresh Power BI copia i dati dalla sorgente e li comprime con VertiPaq, il motore colonnare in memoria. Da quel momento ogni interazione dell'utente viene risolta in RAM, senza toccare la sorgente.

• Tempi di risposta nell'ordine dei millisecondi, anche su decine di milioni di righe.
• Nessun carico sulla sorgente durante l'uso del report.
• Tutto DAX funziona: time intelligence, colonne calcolate, tabelle calcolate, Q&A.
• Tutte le trasformazioni Power Query sono disponibili (unpivot, merge, colonne custom).

Il prezzo: i dati sono fotografati all'ultimo refresh, e c'è un limite di dimensione. La compressione VertiPaq è aggressiva (dictionary encoding, run-length encoding) e su dati reali si vedono rapporti 5x–10x, quindi "1 GB di modello" corrisponde a molti più GB di sorgente — ma il limite esiste.

Se il problema è solo il tempo di refresh, la risposta di solito non è cambiare modalità: è il refresh incrementale (disponibile anche in Pro), che ricarica solo la finestra recente invece dell'intero storico.

DirectQuery — query live alla sorgente

Nessuna copia. A ogni interazione Power BI genera una query nativa (SQL o equivalente) e la manda alla sorgente.

• Dati sempre allineati alla sorgente, senza refresh schedulato.
• Nessun limite di dimensione lato modello.
• Le performance sono quelle della sorgente, moltiplicate per il numero di utenti concorrenti.

I vincoli reali, quelli che scoprono tutti troppo tardi:

• Esiste un tetto sulle righe restituite da una singola query alla sorgente (1 milione per default; sulle capacità Fabric/Premium è configurabile). Superato quel tetto la query fallisce.
• Le trasformazioni in Power Query devono essere traducibili in query nativa (query folding). Se uno step rompe il folding, Power Query non può più delegare e la modalità diventa inutilizzabile.
• Diverse funzionalità DAX sono limitate o assenti: tabelle calcolate sulle tabelle DirectQuery, alcune funzioni di time intelligence avanzate, l'auto date/time.
• Ogni click di ogni utente è una query. Con 200 utenti su un SQL non dimensionato, la sorgente va in ginocchio. Parlane con il DBA prima.

Come verificare il folding: in Power Query, tasto destro sull'ultimo step → Visualizza query nativa. Se è disattivato, il folding si è rotto in quello step o in uno precedente.

Esempio concreto. Questa query rompe il folding all'ultimo step:

let
    Origine   = Sql.Database("srv-prod", "Vendite"),
    Fatti     = Origine{[Schema = "dbo", Item = "FactVendite"]}[Data],
    Filtrata  = Table.SelectRows(Fatti, each [Anno] >= 2024),
    // Text.Proper non ha equivalente SQL: da qui in poi Power Query
    // scarica i dati e trasforma in locale → addio DirectQuery
    Normaliz  = Table.TransformColumns(Filtrata, {{"Citta", Text.Proper}})
in
    Normaliz

Questa invece regge, perché ogni step ha un corrispondente SQL nativo:

let
    Origine   = Sql.Database("srv-prod", "Vendite"),
    Fatti     = Origine{[Schema = "dbo", Item = "FactVendite"]}[Data],
    Filtrata  = Table.SelectRows(Fatti, each [Anno] >= 2024),
    Colonne   = Table.SelectColumns(Filtrata, {"IdOrdine", "Data", "IdCliente", "Importo"}),
    Rinomina  = Table.RenameColumns(Colonne, {{"Importo", "Fatturato"}})
in
    Rinomina

La regola operativa: in DirectQuery le trasformazioni "non traducibili" (funzioni di testo complesse, unpivot, merge fuzzy, colonne custom con logica M) vanno fatte a monte, in una vista SQL o nella pipeline. Power Query deve limitarsi a selezionare, filtrare e rinominare.

Direct Lake — la modalità nativa di Fabric

Direct Lake legge direttamente i file Delta/Parquet da OneLake: non copia i dati come Import e non manda query live alla sorgente come DirectQuery. Le colonne vengono caricate in memoria on demand al primo utilizzo (transcoding) e restano lì per le query successive.

Due concetti da conoscere:

• Framing: l'operazione con cui il modello semantico aggiorna il puntatore all'ultima versione della tabella Delta. È il "refresh" di Direct Lake, ma non muove dati — dura secondi. Può essere automatico o schedulato.
• Transcoding: la conversione al volo dei segmenti Parquet nel formato in memoria di VertiPaq. È il motivo per cui la prima query su una colonna è più lenta delle successive.

Risultato: freschezza vicina a DirectQuery, velocità vicina a Import, zero duplicazione dello storage.

Cosa serve davvero

Quest'ultimo punto è quello che fa la differenza tra un report istantaneo e uno mediocre. Se il tuo processo di scrittura genera migliaia di file Parquet minuscoli, il transcoding diventa costoso. Esegui OPTIMIZE sulle tabelle Delta e verifica che la scrittura V-Order sia attiva.

Il fallback a DirectQuery

Quando Direct Lake non riesce a servire una query — memoria della capacità esaurita, guardrail di righe per tabella superati, oggetti non supportati come le viste SQL — il modello può fare fallback automatico a DirectQuery sull'endpoint SQL. È trasparente per l'utente, ma le performance cambiano di colpo.

I guardrail sono legati allo SKU: si va dall'ordine delle centinaia di milioni di righe per tabella sugli SKU piccoli a molti miliardi sui più grandi. I numeri esatti cambiano nel tempo, quindi controllali nella documentazione Microsoft prima di dimensionare.

Puoi governare il comportamento con la proprietà DirectLakeBehavior del modello semantico:

• Automatic — fallback consentito (default).
• DirectLakeOnly — niente fallback: le query che non possono essere servite falliscono. Utile in test, per scoprire i fallback invece di subirli.
• DirectQueryOnly — forza DirectQuery, utile per confronti.

Per diagnosticare: attiva il Log Analytics della capacità oppure usa il monitor delle query e cerca gli eventi con queryResultCacheMode / fallback. Se i fallback sono frequenti, o riduci il volume o sali di SKU.

Tabella di confronto

Sui limiti di dimensione, gli ordini di grandezza attuali: Power BI Pro ~1 GB per modello semantico, PPU fino a 100 GB, capacità Fabric da 25 GB (F64) fino a centinaia di GB sugli SKU maggiori. Sono numeri che Microsoft ha già cambiato più volte: verificali sulla documentazione ufficiale prima di prendere impegni con il cliente.

Modelli compositi

Puoi mescolare le modalità nello stesso modello.

Import + DirectQuery. Il pattern classico: dimensioni (Prodotti, Clienti, Calendario) in Import per velocità di slicer e relazioni; la fact table enorme in DirectQuery per non duplicarla. Attenzione alle limited relationships fra tabelle di gruppi di storage diversi: non propagano il filtro allo stesso modo e alcune ottimizzazioni saltano.

Direct Lake + Import. Dal 2025 i modelli Direct Lake su OneLake possono includere anche tabelle in Import nello stesso modello semantico. Utile quando la fact vive nel Lakehouse ma una dimensione arriva da un Excel o da un sistema fuori Fabric.

I compositi funzionano, ma aggiungono complessità su sicurezza a livello di riga, performance e debug. Non sono un modo per evitare una decisione: sono una decisione in più.

Come scegliere — scenari concreti

Il criterio di partenza è sempre lo stesso: qual è il requisito di freschezza reale? Nella maggior parte dei progetti la risposta onesta è "ieri sera va benissimo" — e in quel caso Import vince senza discussione.

E Copilot?

Copilot in Power BI richiede una capacità Fabric a pagamento (F2 o superiore, oppure P) e funziona sui modelli semantici indipendentemente dalla modalità di storage. Quello che cambia davvero la qualità delle risposte non è Import vs Direct Lake: è quanto è pulito il modello. Nomi di tabelle e colonne comprensibili, descrizioni compilate, colonne tecniche nascoste, misure con formattazione corretta. Un modello Direct Lake disordinato dà risposte peggiori di un modello Import curato.

Errori comuni

Scegliere DirectQuery "per avere dati aggiornati" senza misurare il requisito. Se il business accetta un ritardo di un'ora, un refresh incrementale orario in Import è più veloce, più economico e più stabile.

Rompere il query folding e non accorgersene. Uno step con colonna custom in mezzo alla query, e Power Query smette di delegare alla sorgente. In DirectQuery questo trasforma un report da 2 secondi in uno da 40. Controlla Visualizza query nativa dopo ogni modifica strutturale.

Convertire da DirectQuery a Import senza sapere che è irreversibile. In Power BI Desktop il passaggio DirectQuery → Import è a senso unico: una volta fatto, non torni indietro nello stesso file. Lavora su una copia.

Pensare che Direct Lake sia gratis. Serve una capacità Fabric attiva, che si paga a ore di capacità (o riservata). Su volumi piccoli, un modello Import su Pro costa una frazione. Direct Lake conviene quando hai già Fabric per altri motivi o quando i volumi rendono Import impraticabile.

Portare in Direct Lake dati non ottimizzati. Tabelle Delta con migliaia di file piccoli, senza OPTIMIZE, senza V-Order: la modalità funziona ma le performance deludono e ti convinci che "Direct Lake è lento". Il collo di bottiglia è a monte, nella pipeline che scrive.

Ignorare i fallback. Un modello Direct Lake che fa fallback su ogni query è, di fatto, un modello DirectQuery — con i costi di Fabric in più. Metti DirectLakeBehavior su DirectLakeOnly in ambiente di test: se qualcosa si rompe, lo scopri lì e non in produzione.

Usare i modelli compositi come scorciatoia. "Metto un po' in Import e un po' in DirectQuery così risolvo" è il modo migliore per ottenere un modello che nessuno riesce a debuggare sei mesi dopo. I compositi vanno progettati, non improvvisati.

Provare a fare le trasformazioni in Power Query con Direct Lake. Direct Lake legge quello che trova nelle tabelle Delta. Pulizia, join e derivazioni si fanno a monte, con un notebook, un dataflow o una pipeline che scrive nel Lakehouse. Se ti serve trasformare in Power Query, la modalità giusta è Import.

Se vuoi partire dalle basi e arrivare a fare questa scelta con cognizione di causa, il Livello Base del corso Power BI Lab è gratuito e copre proprio le modalità di connessione, il caricamento dati e il primo modello; Fabric, Direct Lake e Copilot sono approfonditi nei livelli successivi (prezzi).