Multi-tenancy software: cos'è e quando conviene adottarla

Stai costruendo un prodotto SaaS o stai valutando come scalare la tua piattaforma su più clienti senza moltiplicare i costi? Prima o poi ti imbatterai nel concetto di multi-tenancy software. È uno dei pattern architetturali più potenti per chi vuole crescere in modo sostenibile — ma è anche uno di quelli più fraintesi.

In questa guida spieghiamo cos'è la multi-tenancy, come funziona tecnicamente, quando conviene adottarla e quali errori evitare prima di costruirla nel tuo progetto.

Cos'è la multi-tenancy software

La multi-tenancy (o architettura multi-tenant) è un modello in cui una singola istanza dell'applicazione serve più clienti — chiamati tenant — condividendo la stessa infrastruttura, ma mantenendo i dati di ciascuno completamente separati e isolati.

Pensa a un palazzo condominiale: lo stesso edificio, gli stessi impianti, ma ogni appartamento è privato. Nessun inquilino può entrare nell'appartamento dell'altro, anche se condividono le stesse scale e lo stesso ascensore.

Nel software, i "tenant" sono tipicamente le aziende o i clienti che usano la tua piattaforma. Ognuno vede solo i propri dati, personalizza la propria esperienza e lavora in isolamento rispetto agli altri — ma sotto il cofano girano tutti sulla stessa applicazione.

Multi-tenancy vs single-tenancy: le differenze chiave

Il modello opposto è la single-tenancy: ogni cliente ha la propria istanza separata dell'applicazione, con il proprio server, il proprio database, la propria infrastruttura. È come affittare ville indipendenti invece di appartamenti in un condominio.

Ecco le differenze pratiche:

• Costi infrastrutturali: la multi-tenancy è molto più economica da gestire perché le risorse sono condivise. Con la single-tenancy, i costi si moltiplicano linearmente al crescere dei clienti.
• Aggiornamenti: in multi-tenancy aggiorni una volta e tutti i tenant ricevono la nuova versione. In single-tenancy devi aggiornare ogni istanza separatamente.
• Isolamento dei dati: la single-tenancy offre un isolamento fisico più forte. La multi-tenancy richiede una progettazione accurata per garantire la stessa sicurezza a livello logico.
• Personalizzazione: con la single-tenancy è più semplice fare personalizzazioni profonde per ogni cliente. In multi-tenancy le personalizzazioni devono essere gestite a livello applicativo.

La scelta tra i due modelli non è mai assoluta: dipende dal tuo modello di business, dal profilo dei tuoi clienti e dalla fase in cui ti trovi.

Come funziona la multi-tenancy: i tre modelli principali

Non esiste un unico modo di implementare la multi-tenancy. I tre approcci più diffusi si differenziano per come vengono gestiti i dati dei tenant:

1. Database condiviso, schema condiviso

Tutti i tenant usano lo stesso database e le stesse tabelle. Ogni riga ha un campo tenant_id che identifica a chi appartiene. È il modello più economico e semplice da implementare, ma richiede attenzione estrema per evitare che un bug esponga i dati di un tenant ad un altro.

2. Database condiviso, schema separato

Stesso database fisico, ma ogni tenant ha il proprio schema (namespace) con le proprie tabelle. Più isolamento rispetto al primo approccio, ma la gestione delle migrazioni può diventare complessa al crescere dei tenant.

3. Database separato per tenant

Ogni tenant ha il proprio database fisico, ma l'applicazione rimane condivisa. Offre il massimo isolamento dei dati e facilita il backup selettivo, a costo di una maggiore complessità infrastrutturale e costi leggermente più alti.

La scelta dipende principalmente da: volume di dati, requisiti di compliance (GDPR, ISO 27001, SOC 2), numero di tenant attesi e budget.

Se stai valutando quale modello adottare per il tuo progetto SaaS, possiamo aiutarti a fare la scelta giusta: contattaci dalla sidebar per una consulenza gratuita.

Quando conviene la multi-tenancy

La multi-tenancy è quasi sempre la scelta giusta se stai costruendo un prodotto SaaS destinato a molti clienti con esigenze simili. In particolare conviene quando:

• Hai un modello di business a subscription con decine o centinaia di clienti previsti
• Vuoi scalare senza aumentare proporzionalmente i costi operativi
• I tuoi clienti hanno esigenze simili, con personalizzazioni limitate e controllate
• Vuoi rilasciare aggiornamenti velocemente a tutti i clienti in modo uniforme
• Stai costruendo una piattaforma B2B dove ogni cliente è un'azienda con i propri utenti interni

Diventa invece meno indicata — o richiede approcci ibridi — quando:

• I clienti hanno requisiti di compliance molto stringenti che impongono isolamento fisico dei dati (es. settore bancario, sanità, difesa)
• Le personalizzazioni richieste sono così profonde da rendere impossibile una codebase condivisa
• Hai pochissimi clienti (meno di 5-10) con contratti enterprise ad alto valore: in quel caso la single-tenancy può essere più gestibile

Errori comuni da evitare

Progettare male una multi-tenancy può costare carissimo in seguito. Questi sono gli errori più frequenti che vediamo nei progetti che ci vengono portati per essere "rimessi in salute":

Aggiungere il tenant_id dopo. Se non progetti la multi-tenancy fin dall'inizio, integrarla a posteriori è un refactoring enorme. Ogni query, ogni API, ogni permesso deve essere ripensato. Fallo subito o non farlo affatto.

Dimenticare il row-level security. Non basta filtrare i dati a livello applicativo. Se il database supporta Row Level Security (come PostgreSQL), usalo come secondo livello di protezione. Un bug nel codice non deve esporre i dati di un altro tenant.

Non pensare al rate limiting per tenant. In un sistema condiviso, un tenant che genera traffico anomalo può degradare le performance per tutti gli altri. Serve un sistema di throttling per tenant fin dall'inizio.

Trascurare la gestione delle migrazioni. Ogni volta che aggiorni il database, la migrazione deve girare su tutti i tenant in modo coerente. Con database condivisi è semplice; con database separati per tenant, serve un sistema di orchestrazione delle migrazioni.

Non testare l'isolamento. Scrivi test espliciti che verificano che un tenant non possa accedere ai dati di un altro. Non lasciare questo alla "logica implicita" del codice.

Checklist pratica prima di iniziare

Prima di commissionare o avviare lo sviluppo di una piattaforma multi-tenant, verifica questi punti:

1. Hai definito chiaramente cos'è un "tenant" nel tuo business model? (un'azienda, un account, un workspace?)
2. Quali dati devono essere isolati per tenant e quali possono essere condivisi?
3. Quali sono i requisiti di compliance dei tuoi clienti target?
4. Hai stimato il numero di tenant previsto a 12 e 36 mesi?
5. Il tuo team (o la software house che sceglierai) ha esperienza con architetture multi-tenant?
6. Hai previsto come gestirai il provisioning di nuovi tenant? (automatico, manuale, self-service?)

Conclusione

La multi-tenancy software è il fondamento architetturale di quasi tutti i prodotti SaaS di successo. Progettarla bene fin dall'inizio significa poter scalare da 10 a 10.000 clienti senza riscrivere l'intera piattaforma. Ignorarla o implementarla male significa accumulare debito tecnico che prima o poi ti presenterà il conto.

Se stai avviando un progetto SaaS o vuoi valutare se la tua architettura attuale regge alla crescita, il nostro team può aiutarti a fare un'analisi concreta. Hai bisogno di supporto sull'architettura multi-tenant? Scrivici: trovi il form di contatto qui a destra.