Architettura e confronti
SaaS multi-tenant o istanze separate: come scegliere l'architettura
È la prima decisione di una piattaforma venduta in abbonamento, e quella più difficile da cambiare dopo. Qui definiamo i termini, mettiamo i modelli a confronto sui criteri che pesano davvero e raccontiamo perché due nostri prodotti hanno scelto strade opposte.
Scritto da Maximilian Giurastante. . 10 minuti di lettura.
Una piattaforma SaaS multi-tenant è un'applicazione in cui più clienti (i tenant) usano la stessa installazione e la stessa infrastruttura, con i dati separati da un identificativo di tenant su ogni riga. Nel modello a istanze separate ogni cliente ha invece la propria copia dell'applicazione e del database. Il multi-tenant costa meno per cliente e si aggiorna una volta sola; le istanze separate isolano di più e si personalizzano di più.
In sintesi
- Multi-tenant significa un'installazione per tutti i clienti e un identificativo di tenant su ogni dato; istanze separate significa una copia dell'applicazione e del database per cliente.
- AWS chiama i tre modelli silo (tutto separato), pool (tutto condiviso) e bridge (applicazione condivisa, dati separati). Microsoft descrive gli stessi modelli per il database: uno per tenant, condiviso, partizionato, ibrido.
- Il modello condiviso conviene con molti clienti piccoli e poca personalizzazione; quello separato con pochi clienti grandi che chiedono isolamento, residenza dei dati o versioni proprie.
- Il rischio tecnico del modello condiviso è una sola query senza il filtro del tenant: si mitiga con revisioni, test e regole a livello di database, non con la fiducia.
- LeavePilot usa il modello condiviso perché serve molte piccole aziende con lo stesso prodotto; Allestio crea un database per organizzazione perché serve aziende che vogliono i dati separati. La differenza sta nei clienti, non nella tecnologia.
- Un ordine di grandezza per una piattaforma multi-tenant completa: da 15.000 a 40.000 euro e da tre a sei mesi; un database per cliente aggiunge lavoro di gestione, non di sviluppo.
Le definizioni, prima delle opinioni
Il tenant è il cliente inteso come organizzazione: un'azienda con i suoi utenti, i suoi dati e le sue impostazioni. La domanda «multi-tenant o no» chiede dove passa il confine fra un tenant e l'altro: nel codice, nel database o nell'infrastruttura.
I nomi cambiano fra fornitori ma i modelli sono gli stessi. La guida Microsoft ai modelli di tenancy per il database elenca: applicazione single-tenant con database single-tenant, applicazione multi-tenant con un database per tenant, applicazione multi-tenant con un solo database condiviso, database condiviso partizionato in più frammenti, e modello ibrido. In pratica si tratta sempre di decidere se il confine fra clienti sta in una colonna, in un database o in un'installazione.
Dove passa il confine fra un cliente e l'altro
Tre colonne. Istanze separate: tre corsie, ciascuna con un'applicazione e un database per cliente. Multi-tenant condiviso: un'applicazione e un database unico con l'identificativo del tenant su ogni riga. Ibrido: un'applicazione condivisa e un database per ciascun cliente.
- Istanze separate (silo): App A, DB A, App B, DB B, App C, DB C. Isolamento massimo, tre installazioni da aggiornare
- Multi-tenant condiviso (pool): Un'applicazione (per tutti i clienti), Un database (tenant_id su ogni riga). Costo per cliente minimo, un solo aggiornamento
- Ibrido (bridge): Un'applicazione condivisa (per tutti i clienti), DB A, DB B, DB C. Dati separati, un solo codice, migrazioni per ogni database
Il confronto sui criteri che pesano davvero
Nessun modello vince su tutti i criteri. La tabella serve a vedere su quali criteri il tuo caso è sensibile: chi vende a piccole aziende guarda le prime righe, chi vende a enti e grandi imprese guarda le ultime.
| Criterio | Multi-tenant condiviso | Istanze separate | Ibrido (database per tenant) |
|---|---|---|---|
| Costo per cliente | Il più basso: risorse condivise | Il più alto: risorse dedicate | Basso per l'applicazione, medio per i database |
| Isolamento dei dati | Logico: una colonna e un filtro | Fisico: installazioni diverse | Fisico per i dati, logico per l'applicazione |
| Aggiornamenti | Uno per tutti, in un momento | Uno per istanza, anche a versioni diverse | Codice uno per tutti, migrazioni per ogni database |
| Personalizzazione | Per configurazione, entro il prodotto | Anche nel codice, per cliente | Per configurazione, con dati e limiti propri |
| Effetto di un cliente sugli altri | Possibile: un cliente pesante rallenta gli altri | Nessuno | Ridotto: il database non è condiviso |
| Residenza e cancellazione dei dati | Per riga: cancellare un tenant è una query da fare bene | Per installazione: si spegne | Per database: si elimina il database |
| Rischio di errore | Una query senza filtro espone dati di altri | Basso | Basso sui dati, resta sull'applicazione |
| Complessità operativa | Bassa | Alta: cresce con ogni cliente | Media: automatizzare la creazione dei database |
| Onboarding di un nuovo cliente | Una riga in una tabella | Una nuova installazione | Un nuovo database, creato via API |
| Quando conviene | Molti clienti piccoli, stesso prodotto per tutti | Pochi clienti grandi, requisiti contrattuali | Base mista, o clienti che chiedono i dati separati |
Due prodotti, due scelte opposte, per lo stesso motivo
Abbiamo costruito entrambi i modelli, e non per esperimento: i clienti dei due prodotti sono diversi. Il modello segue i clienti.
LeavePilot: condiviso, perché i clienti sono tanti e piccoli
LeavePilot gestisce ferie e permessi per aziende che spesso hanno meno di venti dipendenti, con un piano gratuito fino a cinque. Un database per azienda costerebbe più del ricavo di quell'azienda. Tutte le aziende stanno quindi nello stesso database, ogni riga porta l'identificativo dell'azienda, e il filtro è applicato in un solo punto del codice, così non dipende dalla memoria di chi scrive la query successiva. Un aggiornamento è uno per tutti, la sera stessa.
Allestio: un database per organizzazione, perché i clienti sono aziende che allestiscono
Allestio è un gestionale per aziende audio-video e allestitori. I clienti sono meno, più grandi, e i loro dati (inventari, schemi, foto di cantiere) sono il loro lavoro: vogliono sapere che stanno in un posto loro. Alla creazione di un'organizzazione la piattaforma crea un database dedicato tramite l'API del fornitore, e un catalogo centrale tiene l'elenco. Dentro ogni database, ventinove tabelle su trenta portano anche l'identificativo del progetto: isolamento a due livelli. Il prezzo è che ogni migrazione dello schema va applicata a ogni database, con uno script che le esegue in sequenza.
La stessa decisione, letta sui due prodotti
| Domanda | LeavePilot | Allestio |
|---|---|---|
| Chi sono i clienti | Molte aziende piccole, anche gratuite | Meno aziende, con dati che sono il loro lavoro |
| Cosa chiedono sui dati | Che funzioni e costi poco | Che siano separati e portabili |
| Modello scelto | Condiviso, identificativo su ogni riga | Un database per organizzazione, più identificativo di progetto |
| Costo di un cliente nuovo | Una riga | Un database creato via API, pochi secondi |
| Costo di un aggiornamento | Una migrazione | Una migrazione per ogni database, in sequenza |
| Dove si è pagato di più | Nei test con più aziende e nei controlli sul filtro | Nell'automazione della creazione e delle migrazioni |
Come scegliere, in quattro domande
La decisione si prende guardando i clienti, non le tecnologie. Queste quattro domande bastano quasi sempre; se le risposte sono miste, la risposta è il modello ibrido.
- Quanti clienti, e quanto pagano ciascuno? Se il ricavo per cliente è di poche decine di euro al mese, il costo di un database dedicato lo mangia: modello condiviso. Se è di centinaia o migliaia, il database dedicato è un dettaglio nel conto.
- Cosa chiedono i contratti dei clienti? Enti pubblici, sanità, finanza e grandi imprese spesso chiedono per iscritto dove stanno i dati, chi li può leggere e come si cancellano. Un database per tenant risponde con un fatto; il modello condiviso risponde con una procedura. Entrambe possono andare bene, ma la prima è più facile da spiegare.
- Quanto è diverso il prodotto da un cliente all'altro? Se ogni cliente vuole regole, campi e integrazioni proprie, il modello condiviso diventa un labirinto di condizioni. Meglio istanze separate o un ibrido con configurazione per tenant, e meglio ancora chiedersi se si sta vendendo un prodotto o un servizio su misura.
- Chi gestirà l'infrastruttura fra due anni? Cento istanze separate sono cento installazioni da aggiornare, monitorare e salvare. Se non c'è chi lo faccia, il modello condiviso o l'ibrido con creazione automatica sono le sole opzioni che restano in piedi.
Il contesto di mercato spinge verso le piattaforme condivise: secondo Gartner la spesa mondiale in servizi cloud pubblici era stimata in 723,4 miliardi di dollari per il 2025, in crescita dai 595,7 del 2024, e il software come servizio ne è la voce principale. Chi compra si aspetta ormai il modello SaaS; la scelta architetturale riguarda come dare a ciascun cliente l'isolamento che il suo contratto richiede, senza pagarlo per tutti.
Costi e tempi
Il modello scelto sposta il costo più sull'esercizio che sullo sviluppo. Gli ordini di grandezza sono quelli della nostra pagina sui costi; qui diciamo cosa cambia fra un modello e l'altro.
| Voce | Multi-tenant condiviso | Database per tenant | Istanze separate |
|---|---|---|---|
| Sviluppo della piattaforma | da 15.000 a 40.000 euro, da tre a sei mesi | Uguale, più l'automazione della creazione e delle migrazioni | Uguale, più gli script di installazione per cliente |
| Onboarding di un cliente | Nessun costo tecnico | Pochi centesimi o euro al mese per database | Ore di lavoro e risorse dedicate |
| Aggiornamenti | Compresi nella manutenzione | Compresi, con un passaggio in più | A tempo, per ogni istanza |
| Infrastruttura mensile | Da poche decine a qualche centinaio di euro in tutto | Simile, con un database in più per cliente | Per cliente, da decine a centinaia di euro |
La decisione va presa prima di scrivere la prima tabella, perché spostare un prodotto da un modello all'altro dopo il lancio è un lavoro paragonabile a riscriverlo. Se stai valutando una piattaforma, la pagina piattaforme SaaS descrive come lavoriamo sull'isolamento, gli abbonamenti e i ruoli, e come lavoriamo e quanto costa dà gli ordini di grandezza completi.
Domande frequenti
Cos'è un tenant in una piattaforma SaaS?
Il tenant è il cliente inteso come organizzazione: un'azienda con i suoi utenti, i suoi dati e le sue impostazioni. Una piattaforma multi-tenant serve più tenant con la stessa installazione; ogni utente appartiene a un tenant e vede solo i dati di quel tenant.
Il multi-tenant è meno sicuro delle istanze separate?
Non in sé: la sicurezza dipende da come è costruito. Nel modello condiviso il rischio specifico è una query senza il filtro del tenant, e si previene applicando il filtro in un solo punto, provando con più tenant e usando regole a livello di riga nel database. Nelle istanze separate il rischio si sposta sulle installazioni da tenere aggiornate tutte allo stesso livello.
Quando conviene un database per ogni cliente?
Quando i clienti sono relativamente pochi, pagano abbastanza da coprire il costo del database dedicato, e chiedono per contratto dove stanno i loro dati o come si cancellano. È il modello che abbiamo scelto per Allestio, che serve aziende con inventari e schemi che sono il loro lavoro.
Si può passare da un modello all'altro dopo il lancio?
Si può, ma è un lavoro paragonabile a una riscrittura della parte dati: ogni query, ogni migrazione e ogni script di backup cambiano. Per questo la scelta va fatta prima della prima tabella, sulla base dei clienti che si intende servire, e non rimandata.
Quanto costa sviluppare una piattaforma SaaS multi-tenant?
L'ordine di grandezza è da 15.000 a 40.000 euro e da tre a sei mesi per una piattaforma completa con isolamento dei dati, abbonamenti, ruoli e pannello di amministrazione. Un database per cliente aggiunge lavoro di automazione, non di sviluppo del prodotto. Le variabili che pesano di più sono le integrazioni e i pagamenti.
Fonti
I dati citati nel testo, con il collegamento al documento originale. Le cifre sono riportate come pubblicate dalla fonte, con l'anno a cui si riferiscono.
- AWS, SaaS Tenant Isolation Strategies (whitepaper): Definizione dei modelli silo, pool e bridge per l'isolamento dei tenant. Pubblicato il 1 agosto 2020, oggi conservato come riferimento storico; gli stessi modelli sono ripresi nella SaaS Lens del Well-Architected Framework.
- AWS Well-Architected Framework, SaaS Lens: Bridge model: Il modello ibrido con applicazione condivisa e risorse dedicate per alcuni tenant.
- Microsoft Learn, Multitenant SaaS database tenancy patterns: I modelli di tenancy per il database: single-tenant, database per tenant, database condiviso, condiviso partizionato, ibrido, con la tabella di confronto su scala, isolamento, costo e complessità. Aggiornato il 21 agosto 2025.
- Microsoft Learn, Architectural approaches for storage and data in multitenant solutions: Modelli di distribuzione dei dati nelle soluzioni multi-tenant. Aggiornato il 21 agosto 2026.
- Gartner, Gartner Forecasts Worldwide Public Cloud End-User Spending to Total $723 Billion in 2025: Comunicato del 19 novembre 2024: spesa in servizi cloud pubblici stimata in 723,4 miliardi di dollari per il 2025, dai 595,7 del 2024.
Scritto da Maximilian Giurastante
Founder e software developer, MAXYMIZE. Progetta e sviluppa piattaforme SaaS, gestionali su misura e automazioni con modelli linguistici. Oltre vent'anni come project leader nell'integrazione di sistemi tecnologici, audio e video.
Stai progettando una piattaforma in abbonamento?
Portaci i tuoi clienti tipo, anche solo tre profili. In trenta minuti ti diciamo quale modello di isolamento regge il tuo caso e cosa comporta nei costi di esercizio.