Perché la storage mode è una decisione architetturale

In Power BI ogni tabella del modello ha una storage mode che decide dove risiedono i dati e come vengono interrogati. È una delle scelte più impattanti sulle performance e sull’esperienza utente: non è un dettaglio di configurazione, ma un compromesso fra velocità, freschezza del dato e volume gestibile. Le tre modalità sono Import, DirectQuery e Dual.

Import: VertiPaq in-memory

In modalità Import i dati vengono copiati dentro il modello e gestiti dal motore VertiPaq, un database analitico columnstore in-memory. VertiPaq non memorizza righe ma colonne compresse: applica dictionary encoding, run-length encoding e value encoding, sfruttando il fatto che una colonna contiene valori omogenei e spesso ripetuti. Il risultato è una compressione elevata e query DAX velocissime, perché l’aggregazione avviene interamente in RAM.

Caratteristiche chiave:

  • Prestazioni massime: ideale per dashboard interattive e slicing/dicing rapido.
  • DAX completo: nessuna limitazione di funzioni.
  • Dati “congelati” al refresh: la freschezza dipende dalla pianificazione del refresh (es. 8 refresh/giorno in capacità Pro, più con Fabric/Premium).
  • Limite di dimensione: il modello deve stare in memoria; su capacità condivisa il file ha un tetto (tipicamente 1 GB compresso).

Import è la scelta di default quando il volume è gestibile e non serve il tempo reale.

DirectQuery: query live sulla sorgente

In DirectQuery i dati restano nella sorgente (un data warehouse, Azure SQL, Microsoft Fabric, Databricks, ecc.). Ogni visual genera query SQL inviate live al backend al momento dell’interazione.

Vantaggi e vincoli:

  • Dati sempre freschi: nessuna copia, ideale per volumi enormi o requisiti near-real-time.
  • Nessun limite di dimensione del modello (i dati non entrano in RAM).
  • Più lento: ogni interazione dipende dalla latenza e dal carico della sorgente.
  • Limitazioni DAX/M: alcune funzioni time-intelligence e pattern complessi non sono supportati o degradano le performance; il Power Query è ridotto perché deve tradursi in SQL.

DirectQuery si sceglie quando i dati sono troppo grandi per l’import, o quando la governance impone che restino nel database sorgente.

Dual: la tabella camaleonte

Una tabella in Dual si comporta sia come Import sia come DirectQuery, e il motore decide caso per caso quale usare. È pensata per le dimension table condivise in un modello composite: se una query coinvolge solo tabelle Import, Dual serve i dati dalla cache in-memory; se coinvolge una fact table in DirectQuery, Dual si allinea a quest’ultima evitando join costosi tra motori diversi (le cosiddette cross-source query).

Composite model e aggregation table

Un composite model mescola storage mode diverse nello stesso modello: tipicamente fact table enormi in DirectQuery + dimensioni in Dual/Import. Questo permette di combinare freschezza su grandi volumi e reattività sulle dimensioni.

Il vero acceleratore sono le aggregation table: tabelle pre-aggregate (spesso in Import) che rispondono al posto della fact DirectQuery quando la query è a granularità alta.

  • L’utente chiede il totale vendite per anno → il motore usa in modo trasparente l’aggregazione in-memory (velocissimo).
  • L’utente scende al singolo scontrino → il motore fa fallback in DirectQuery sul dettaglio.

Le aggregazioni si configurano con Manage aggregations mappando le colonne su Count/Sum/Min/Max/GroupBy; l’utente non deve cambiare le sue query.

Criteri di scelta rapidi

  • Volume gestibile + no real-time → Import.
  • Volumi enormi o dato in tempo reale → DirectQuery, meglio se in composite con aggregazioni.
  • Dimensioni condivise in composite → Dual.

Trappole tipiche d’esame

  • Serve massima velocità e i dati aggiornati una volta al giorno bastano → Import, non DirectQuery (evita la latenza della sorgente).
  • Fact table da miliardi di righe che non entra in memoria, ma serve reattività sui report riepilogativi → composite model DirectQuery + aggregation table in Import.
  • In un modello composite, che storage mode dare alle dimension table condivise per evitare query cross-source lente? → Dual.
  • Servono dati in tempo reale dal data warehouse aziendale → DirectQuery (Import mostrerebbe dati fermi all’ultimo refresh).
  • Una misura DAX time-intelligence non funziona / il report è lento → probabile tabella in DirectQuery: valuta il passaggio a Import o l’uso di aggregazioni, ricordando che VertiPaq offre DAX completo mentre DirectQuery lo limita.