Azure SQL Database vs. Fabric SQL Database: differenze di costo e di calcolo spiegate

By Mirko Peters · 2026-10-21

Confronto tra i costi di calcolo di Azure SQL Database e Fabric SQL Database: scalabilità serverless, unità di capacità, economia dello storage e compromessi funzionali.

Automatically translated with AI from the original post. Read the English original

Scegliere tra Azure SQL Database e Fabric SQL Database significa capire in che modo cambiano l'allocazione del calcolo, il comportamento di scalabilità e le unità di capacità. Pur basandosi entrambi sullo stesso solido motore SQL, l'integrazione di Fabric con OneLake e i modelli di capacità condivisa introduce considerazioni architetturali e di costo specifiche per le organizzazioni orientate ai dati.

Punti chiave

• Fabric SQL Database attinge alle unità di capacità (CU) condivise di Fabric, invece che ai livelli vCore autonomi di Azure.
• Le risorse di calcolo scalano fino a zero e vengono rilasciate automaticamente dopo 15 minuti di inattività, per ridurre i costi.
• Lo storage viene fatturato in modo continuo, ogni ora, mentre il backup dello storage è gratuito fino alla dimensione del database primario.
• Il mirroring integrato automatico elimina le pipeline ETL manuali, popolando in tempo reale i file Delta Parquet in OneLake.
• Il tradizionale Azure SQL Database mette a disposizione pool elastici dedicati e processi di SQL Server Agent, che negli ambienti Fabric vengono gestiti in modo diverso.

Capire il calcolo: vCore o unità di capacità

Quando si migrano i carichi di lavoro o si pianifica una nuova architettura cloud, la differenza fondamentale tra il tradizionale Azure SQL e Fabric SQL sta nella gestione del calcolo. In un Azure SQL Database autonomo, si effettua il provisioning di vCore dedicati oppure di calcolo Serverless, associati direttamente alla singola istanza di database. Gestisci limiti di scalabilità, finestre di manutenzione e livelli di prestazioni database per database.

Al contrario, un Fabric SQL Database attinge la sua potenza di calcolo dal pool di capacità Fabric più ampio dell'organizzazione. Questo modello di risorse condivise significa che il database condivide un budget con report di Power BI, pipeline di Data Factory e Lakehouse. La conversione tra unità di capacità Fabric (CU) e potenza del database avviene in modo dinamico, dietro le quinte. Ad esempio, un'allocazione di 64 unità di capacità equivale grosso modo a 24,5 vCore per il carico di lavoro del database. Questo approccio a pool unificato evita la frammentazione delle risorse tipica degli ambienti con più database e consente una condivisione dinamica all'interno dell'area di lavoro analitica.

Scalabilità serverless e regole di fatturazione in inattività

Entrambe le offerte di database utilizzano architetture serverless che scalano verso l'alto durante i picchi di esecuzione delle query e tornano a scalare verso il basso quando il traffico diminuisce. Tuttavia, la logica di fatturazione del tempo di inattività è particolarmente importante per le previsioni di budget. Un Fabric SQL Database monitora l'attività in modo continuo. Se un database resta completamente inattivo per 15 minuti senza query in arrivo, rilascia tutte le risorse di calcolo e il costo del calcolo scende a zero.

Per evitare latenze da avvio a freddo per il successivo utente, Microsoft applica un margine di mantenimento deliberato. Se un database lavora intensamente per due minuti e poi si ferma, paghi quei due minuti di attività più 15 minuti aggiuntivi di calcolo in standby attivo, per un totale di 17 minuti. Lo storage, invece, resta costante e viene fatturato ogni ora, indipendentemente dal fatto che il database stia elaborando transazioni o sia in pausa.

Costi dello storage ed economia dei backup

La gestione dello storage in Fabric SQL Database offre vantaggi significativi in termini di costi rispetto alle configurazioni tradizionali. Poiché il database avvia automaticamente il mirroring continuo verso OneLake, i tuoi dati operativi vengono duplicati in file Delta Parquet aperti. Questo formato aperto garantisce che i dati non restino mai bloccati in un silo proprietario: qualsiasi strumento in grado di leggere il formato Delta può interrogare direttamente la copia replicata.

Inoltre, l'economia dei backup è molto ottimizzata nell'ecosistema Fabric. La funzionalità di ripristino point-in-time consente agli amministratori di riportare indietro le lancette dell'orologio fino a sette giorni, per recuperare dati corrotti per errore o errori catastrofici degli utenti. Lo storage dei backup è completamente gratuito fino alla dimensione totale del database primario. Si pagano costi aggiuntivi solo se l'ingombro dello storage dei backup supera le dimensioni del database attivo, offrendo una rete di sicurezza finanziaria prevedibile per la conservazione dei dati a lungo termine.

Compromessi operativi: cosa si guadagna e cosa si perde

Sebbene il motore SQL di base sia identico su entrambe le piattaforme, scegliere Fabric SQL Database invece di Azure SQL Database richiede di valutare specifici compromessi funzionali. Sapere cosa manca nell'implementazione di Fabric evita ostacoli architetturali imprevisti durante lo sviluppo.

Funzionalità esclusive di Azure SQL tradizionale

I database Azure SQL autonomi supportano nativamente i pool elastici per nome, offrendo agli amministratori di database un controllo granulare sui raggruppamenti dei database. Includono inoltre il classico SQL Server Agent, da cui dipendono molte applicazioni legacy per pianificare stored procedure e attività di manutenzione.

Vantaggi nativi di Fabric SQL

Fabric SQL elimina l'overhead amministrativo legato alla configurazione di pipeline di replica esterne. Non appena crei il database, il mirroring si attiva automaticamente per tutte le tabelle supportate, senza bisogno di configurare manualmente un ETL. Inoltre, si integra nativamente con Git per il controllo del codice sorgente e supporta le convenzioni di denominazione a tre parti, consentendoti di unire facilmente tabelle operative con Lakehouse e Warehouse in un'unica query. Per una panoramica completa di come questi elementi si incastrano tra loro, ascolta l'episodio completo per sentire l'analisi degli esperti e le strategie pratiche per gli architetti dei dati moderni.

Domande frequenti

Come funziona la fatturazione per un Fabric SQL Database inattivo?

La fatturazione del calcolo prosegue per 15 minuti dopo il termine dell'ultima query, per mantenere il database attivo; dopodiché i costi di calcolo scendono a zero. Lo storage continua a essere fatturato ogni ora, indipendentemente dall'attività.

Devo configurare manualmente il mirroring per portare i dati in OneLake?

No. Il mirroring si avvia automaticamente nel momento in cui viene creato il Fabric SQL Database, sincronizzando in modo continuo le tabelle relazionali in OneLake sotto forma di file Delta Parquet aperti, senza codice ETL personalizzato.

È possibile usare SQL Server Agent per pianificare i processi in un Fabric SQL Database?

SQL Server Agent non è disponibile in Fabric SQL Database. Microsoft consiglia invece di usare le pipeline di Data Factory o i processi Apache Airflow per pianificazione e automazione.

Come vengono fatturati i backup in Fabric SQL?

I backup per il ripristino point-in-time sono completamente gratuiti fino alla dimensione totale dello storage del database attivo. Si paga lo storage dei backup solo se l'ingombro dei backup supera le dimensioni del database primario.