Salta al contenuto
Guida acquisto • Cloud · Microsoft Azure

Azure SQL Database vs SQL Server su Azure VM: PaaS o IaaS per PMI italiane

Confronto fra database SQL managed (PaaS) e SQL Server su VM (IaaS) su Azure. Quando scegliere uno o l'altro per software custom PMI.

Microsoft

Azure SQL Database (PaaS)

Database SQL managed con backup, HA, patching automatici inclusi

— vs —

01 — Il contesto

Perché confrontarli

Quando una PMI italiana ospita un software custom su Microsoft Azure, una delle decisioni architetturali ricorrenti è dove mettere il database SQL. Le due opzioni principali sono Azure SQL Database (servizio managed PaaS basato su SQL Server) o SQL Server installato manualmente su una Azure VM (IaaS). Entrambe sono Microsoft, entrambe parlano lo stesso T-SQL, entrambe scalano in cloud — ma le implicazioni operative e di costo sono molto diverse.

La scelta sbagliata costa tipicamente 20-40% in più sul TCO 3 anni o complica la manutenzione operativa al punto di richiedere un sistemista dedicato che non era nei piani. Questo confronto fornisce il framework decisionale tecnico per CTO o IT manager PMI che progettano l'architettura del prossimo software custom. Per il quadro più ampio sulla scelta hosting vedi anche [Azure App Service vs Container Apps](/confronti/azure-app-service-vs-container-apps-hosting-software-custom-pmi) e [Azure vs AWS per software custom](/confronti/hosting-cloud-azure-vs-aws-per-software-custom-pmi-italia).

02 — Confronto puntuale

Criteri di confronto

Ogni criterio confronta i due prodotti su un aspetto rilevante. I valori sono basati su informazioni pubblicamente disponibili sui siti dei vendor coinvolti.

Modello di servizio

  • Cosa gestisci tu, cosa gestisce Microsoft

    Microsoft

    PaaS managed: Microsoft gestisce OS, patching SQL Server, backup automatici, alta disponibilità, monitoring infrastructure. Tu gestisci solo schema, query, indici, dati.

    Microsoft

    IaaS: Microsoft gestisce solo l'hardware fisico e l'hypervisor. Tu gestisci OS Windows Server, patching, SQL Server version, backup, HA, configurazione storage, sicurezza, ottimizzazione.

  • Effort operativo annuale

    Microsoft

    Quasi zero. Patching SQL Server automatico (durante maintenance window concordata), backup giornalieri configurati at setup, HA in availability zone in 1 click. 2-4 ore/anno di gestione operativa per DB tipico.

    Microsoft

    Significativo. Patching Windows + SQL Server, backup script o tool dedicati (Veeam, Azure Backup), tuning storage, monitoring, capacity planning. 40-100 ore/anno di gestione operativa per DB tipico (richiede competenze DBA).

Pricing

  • Tier base / entry-level

    Microsoft

    Basic (2 GB max, 5 DTU): ~5 €/mese — per dev/test piccoli. Standard S0 (10 GB, 10 DTU): ~14 €/mese. General Purpose vCore 2-core: ~280 €/mese per workload production tipico.

    Microsoft

    VM Azure B2s (2 vCPU, 4 GB RAM) + SQL Server Web Edition + storage Premium 100 GB: ~150-200 €/mese all-inclusive. Tier production tipico (D4s_v5 + SQL Standard): ~600-1.000 €/mese.

  • Costo workload PMI tipico (50 GB, 100 query/sec)

    Microsoft

    Azure SQL Database General Purpose vCore 2-core, 50 GB: ~280-400 €/mese all-inclusive. Backup + HA inclusi. Reserved Instances 3 anni: ~180-260 €/mese.

    Microsoft

    VM D2s_v5 + SQL Standard licenza inclusa + storage Premium 100 GB: ~450-650 €/mese. Con Azure Hybrid Benefit (porti SA on-premise): ~250-400 €/mese.

  • Azure Hybrid Benefit

    Microsoft

    AHB non applicabile a Azure SQL Database PaaS (il licensing è incluso nel prezzo, non separato).

    Microsoft

    AHB applicabile: se hai SQL Server on-premise con SA, lo "sposti" su VM Azure → sconto 40-55% sul componente SQL della VM. Critico per ottimizzazione TCO.

Performance

  • Performance massima

    Microsoft

    Hyperscale tier scala fino a 100 TB con storage decoupled da compute. Premium tier per workload OLTP con bassa latenza (<1ms). Per il 95% delle PMI italiane è sovra-dimensionato — General Purpose basta.

    Microsoft

    Performance dipendente dalla VM scelta. Con VM grandi (M-series, memory-optimized) e storage NVMe locale, raggiunge performance superiori a Azure SQL DB per workload molto specifici (in-memory OLTP, real-time analytics).

  • Predictability

    Microsoft

    DTU model: capacity costante, throttling automatico se superi. vCore model: capacity costante con burst limitato. Performance prevedibile.

    Microsoft

    Performance dipende da gestione interna (configurazione SQL, tempdb, indici, storage IOPS). Più variabile — può essere migliore con tuning o peggiore con setup sub-ottimale.

Compatibilità

  • Compatibilità SQL Server features

    Microsoft

    Compatibilità T-SQL alta ma non 100%. Mancano: SQL Server Agent (jobs), Distributed Transactions, Service Broker, alcuni linked server, alcune trace flag, FileStream. Per app moderne raramente blocking, per gestionali legacy può essere problema.

    Microsoft

    100% SQL Server compatibility. Tutto quello che funziona su SQL Server on-premise funziona su VM Azure. Lift & shift di gestionali legacy senza modifiche.

  • Migrazione lift & shift da on-premise

    Microsoft

    Richiede assessment: Azure Data Migration Service identifica incompatibilità. Per app moderne tipicamente OK con piccole modifiche; per app legacy può richiedere refactoring. Pattern alternativo: Azure SQL Managed Instance (compatibilità 99%, fra SQL DB e VM SQL).

    Microsoft

    Lift & shift perfetto: stesso SQL Server, stesso comportamento. Database export/import o backup/restore funziona out-of-the-box. Pattern raccomandato per migrazioni da on-premise senza tempo per refactoring.

Sicurezza

  • Encryption e compliance

    Microsoft

    Encryption at rest by default (TDE attivo), encryption in transit by default (TLS 1.2+), audit log centralizzato, Advanced Threat Protection incluso. Compliance certifications Azure inherite automaticamente.

    Microsoft

    Encryption configurabile (TDE manuale, Always Encrypted, encryption colonne), audit via SQL Server Audit, sicurezza dipendente dalla configurazione. Compliance richiede setup manuale, ma maggiore controllo per scenari altamente regolati.

  • Patch management

    Microsoft

    Automatico durante maintenance window concordata (tipicamente 1 ora di notte una volta al mese). Zero intervento DBA.

    Microsoft

    Manuale o automatizzato via Azure Update Management. Patch Tuesday Microsoft → finestra di reboot pianificata. Richiede approccio strutturato.

Backup e HA

  • Backup e disaster recovery

    Microsoft

    Backup automatici giornalieri (PITR fino a 35 giorni), geo-redundant by default in alcuni tier. Restore self-service via portale. Auto-failover groups per HA cross-region.

    Microsoft

    Backup configurabile (Azure Backup, Veeam, script T-SQL custom, log shipping). HA via Always On Availability Groups (Enterprise edition required) o Azure Site Recovery. Più flessibile, più complesso.

  • Recovery Point Objective tipico

    Microsoft

    RPO < 5 minuti (transaction log backup ogni 5 min, geo-replication continua su tier Premium/Business Critical).

    Microsoft

    RPO dipende dal setup. Con Always On sync replica RPO ~0. Con backup giornaliero + log shipping RPO 15-60 min. Con backup-only RPO 24h.

03 — Quando scegliere uno o l'altro

Scenari decisionali

Non esiste vincitore assoluto. La scelta giusta dipende dal vostro contesto: stack esistente, processi, dimensione, budget.

Azure SQL Database (PaaS)

Scegli Azure SQL Database se...

Sviluppi software custom **moderno** (.NET 6+, Node, Python con framework ORM moderni), workload OLTP standard (CRUD, transaction tipiche PMI), niente dipendenze legacy SQL Server specifiche. Vuoi minimizzare effort operativo e non hai DBA dedicato. **Sweet spot per il 70% delle PMI italiane**.

Considera Azure SQL Managed Instance se...

Compatibility 99% (vicina a SQL Server on-premise) ma con managed services PaaS. Sweet spot per **migrazione SQL legacy** dove non vuoi gestione VM ma serve compatibilità feature alta. Costo medio fra Azure SQL DB e SQL su VM. Pattern frequente per modernizzazioni PMI.

Pattern misto in scenari grandi

PMI mid-market che ospita più software: Azure SQL Database per applicazioni nuove cloud-native + SQL Server su VM per gestionale legacy lift & shift. Pattern frequente fino a quando il gestionale legacy non viene modernizzato.

SQL Server su Azure VM (IaaS)

Scegli SQL Server su VM se...

Stai facendo **lift & shift** di un gestionale legacy on-premise con SQL Server Agent jobs, linked server, custom CLR assemblies, o features non supportate da Azure SQL Database. Hai licenze SQL Server con SA (Azure Hybrid Benefit applicabile). Hai DBA interno o esterno strutturato.

04 — La nostra raccomandazione

Il consiglio SynSphere

Per le PMI italiane che sviluppano software custom moderno la regola pratica è: Azure SQL Database è la scelta default, salvo casi specifici. Tre ragioni:

1. Effort operativo zero vs significativo. Una PMI senza DBA dedicato non vuole gestire patch Windows + patch SQL Server + backup script + HA configuration. Azure SQL Database lo fa per te. Il valore di questa scelta sotto i 100 dipendenti è sempre superiore al risparmio teorico di Azure Hybrid Benefit su VM.

2. Compatibilità sufficiente per app moderne. Se sviluppi con Entity Framework Core, Dapper, o ORM moderni, le incompatibilità di Azure SQL DB vs SQL Server on-premise non ti toccano. SQL Server Agent jobs lo sostituisci con Azure Functions o Logic Apps. Linked server lo sostituisci con Azure Data Factory o API integration. Le "missing features" PaaS sono per il 95% dei casi obsolete-by-design.

3. Total cost of ownership migliore sotto i 100 GB. Per database 10-100 GB con workload OLTP standard PMI, Azure SQL DB tier vCore General Purpose 2-core costa ~280 €/mese inclusivo. Una VM equivalente costa ~250-450 €/mese senza considerare il tempo DBA (40-100 ore/anno = 2.000-5.000 €/anno). Includi il costo del tempo umano e Azure SQL DB vince quasi sempre.

Quando SQL Server su VM è la scelta giusta: lift & shift di gestionali legacy dove l'effort di refactoring per Azure SQL DB è più alto del valore migration. Tipico per migrazioni Zucchetti / TeamSystem / gestionali custom .NET 4.x con SQL Agent jobs annuali. Pattern operativo raccomandato: migra a SQL Server su VM ora, modernizza ad Azure SQL DB fra 2-3 anni quando il software riceverà refactoring naturale.

Caso intermedio importante: Azure SQL Managed Instance. Spesso sotto-considerato. Compatibility 99% con SQL Server on-premise + managed PaaS. Per modernizzazioni di gestionali legacy verso cloud è il sweet spot quando Azure SQL DB richiederebbe troppo refactoring ma vuoi evitare gestione VM. Per le PMI italiane con gestionale custom legacy è spesso la scelta più razionale, anche se costa il 30-40% in più di Azure SQL DB.

Errore frequente: PMI che parte SQL Server su VM "perché siamo abituati così" senza valutare se l'app custom moderna sarebbe compatibile con Azure SQL DB. Risultato: paga il doppio per il database e si carica del DBA effort. Pattern raccomandato: chiedi al partner di sviluppo l'assessment compatibility Azure SQL DB prima della decisione architetturale.

05 — Domande frequenti

FAQ

  • Posso migrare da SQL Server on-premise direttamente ad Azure SQL Database?

    **Dipende dalle feature usate**. Il tool ufficiale Microsoft **Azure Data Migration Service (DMS)** fa assessment automatico: identifica le incompatibilità (es. SQL Agent jobs, CLR assemblies, linked server, Distributed Transactions) e ti dice se la migrazione è "ready" o "requires fix". Per gestionali moderni cloud-ready: tipicamente 1-3 settimane di lavoro. Per gestionali legacy con molte feature SQL Server specifiche: 2-6 mesi o passaggio intermedio a SQL Managed Instance.

  • Azure SQL Managed Instance vale la pena vs Azure SQL Database puro?

    **Solo per casi specifici**. SQL Managed Instance costa circa 30-40% in più di Azure SQL Database tier equivalente, ma offre compatibilità 99% con SQL Server on-premise (Agent jobs, linked server, Distributed Transactions, CLR, Service Broker). Va scelto quando: 1) migri legacy SQL Server con feature non supportate da Azure SQL DB; 2) vuoi minimizzare il refactoring; 3) hai DB grande (>500 GB) dove la flessibilità Managed Instance giustifica il costo. Per nuovo sviluppo cloud-native: Azure SQL Database è sempre la scelta migliore (più economica + sufficient).

  • SQL Server Express è disponibile su Azure?

    **Sì, gratuito, ma molto limitato**. SQL Server Express è disponibile come licenza inclusa su VM Azure (no Azure Hybrid Benefit needed). Limiti: 10 GB DB max, 1 GB RAM utilizzata, 1 socket CPU. **Adatto solo a dev/test o app micro** con dataset molto contenuti. Per produzione PMI tipica vai su Azure SQL Database tier Basic/Standard (10-50 €/mese) — il costo è marginale e ottieni features production-grade (HA, backup, monitoring).

  • Come gestisco backup di Azure SQL Database?

    **Backup automatici sono inclusi**. Microsoft fa: backup completo settimanale, backup differenziale ogni 12-24 ore, transaction log backup ogni 5-10 minuti. Point-in-time restore disponibile fino a 7-35 giorni (configurable). Geo-redundant backup opzionale (replica copy a region secondaria). **Non serve configurare nulla** — è on by default. Per scenari di retention long-term (1-10 anni per compliance), configurare Long-Term Retention Policy nel portale (costo aggiuntivo basato su storage). Per export periodici a Blob Storage (es. archive in formato BACPAC): Azure Automation o Logic App job.

  • Performance Azure SQL Database vs SQL Server su VM identica VM size?

    **Generalmente paragonabile, talvolta superiore lato Azure SQL DB**. Azure SQL DB è ottimizzato dal team Microsoft per il workload specifico (alcuni tier hanno hardware NVMe locale per low-latency OLTP). SQL Server su VM offre performance leggermente superiori solo se: 1) tuning storage IOPS specifico; 2) tempdb dedicato su disco NVMe locale (Ephemeral SSD VM); 3) configurazione SQL avanzata fatta da DBA esperto. Per il 95% dei workload PMI Azure SQL DB pari o meglio.

  • Posso passare da SQL Server su VM ad Azure SQL Database più tardi?

    **Sì, è il pattern raccomandato per modernizzazioni progressive**. Workflow: 1) inizia con SQL Server su VM per lift & shift veloce, 2) audit compatibility Azure SQL DB durante uso, 3) refactoring graduale delle feature incompatibili (sostituire SQL Agent jobs con Azure Functions, ecc.), 4) test migration con Azure DMS, 5) cutover su Azure SQL DB. Tempo tipico: 6-18 mesi per modernizzazione completa. Risparmio TCO operativo: 30-50% post-migration.

Nota metodologica. Il confronto è basato su informazioni pubblicamente disponibili sui siti dei vendor coinvolti, listini e documentazione tecnica ufficiale. Nomi, marchi e logo citati sono dei rispettivi proprietari. Per una valutazione personalizzata sul tuo specifico scenario aziendale (utenti, stack esistente, budget, requisiti compliance), contattaci: discovery iniziale gratuita, senza impegno.

  • Azure SQL Database
  • SQL Server
  • PaaS
  • IaaS
  • Database
  • Azure
  • PMI

Potrebbe interessarti anche

Confronti correlati per argomento, sezione e categoria di catalogo.

Devi scegliere fra le due soluzioni?

Parla con un nostro consulente: ti aiutiamo a tradurre il confronto teorico in una scelta concreta sul tuo scenario aziendale (utenti, stack, budget, tempi). Discovery iniziale gratuita.

Contattaci