Scegliere un'architettura multi-tenancy è una delle decisioni più consequenziali nella progettazione di piattaforme SaaS. Influisce sulla struttura dei costi, l'isolamento dei dati, le caratteristiche prestazionali e la complessità operativa per l'intera vita del prodotto. I tre pattern dominanti sono il database condiviso con discriminazione per ID tenant, lo schema per tenant all'interno di un server database condiviso e il database completamente isolato per tenant. Ogni pattern occupa un punto diverso nello spettro tra efficienza operativa e isolamento del tenant. Abbiamo costruito piattaforme SaaS in produzione usando tutti e tre e possiamo condividere indicazioni concrete sulla corrispondenza tra pattern e contesto aziendale.
Il pattern del database condiviso memorizza tutti i dati dei tenant in tabelle comuni, distinti da una colonna ID tenant. È l'approccio più efficiente in termini di costi perché l'infrastruttura scala con il volume totale di dati piuttosto che con il numero di tenant. Aggiungere un nuovo tenant è istantaneo e non richiede provisioning. Tuttavia, questo pattern richiede disciplina rigorosa nella progettazione delle query: ogni query deve includere il filtro ID tenant, e un filtro mancante significa una fuga di dati catastrofica. Mitigiamo questo rischio con policy di sicurezza a livello di riga nel database e middleware obbligatorio di contesto tenant che inietta il filtro automaticamente. L'isolamento delle prestazioni è l'altra sfida, poiché un singolo tenant che esegue query pesanti può impattare tutti gli altri senza un'attenta governance delle risorse.
Lo schema per tenant fornisce un isolamento logico più forte condividendo il server database sottostante. Ogni tenant ottiene il proprio schema con strutture di tabelle identiche, e l'applicazione cambia schema in base al contesto del tenant autenticato. Questo pattern semplifica le conversazioni sulla conformità perché è possibile dimostrare confini chiari dei dati, e le migrazioni specifiche dello schema per tenant diventano possibili per la personalizzazione enterprise. Il costo operativo cresce linearmente con il numero di tenant, poiché ogni schema richiede gestione indipendente delle migrazioni. Abbiamo riscontrato che questo pattern funziona bene per prodotti SaaS B2B con decine o centinaia di tenant dove i requisiti di isolamento dei dati sono moderati e si prevede una certa personalizzazione per tenant.
Il database per tenant offre le garanzie di isolamento più forti. Ogni tenant ha un'istanza di database completamente indipendente, potenzialmente su hardware dedicato. Questo pattern è necessario quando i tenant hanno requisiti normativi per la residenza dei dati, quando l'isolamento delle prestazioni deve essere assoluto, o quando i tenant necessitano della possibilità di utilizzare le proprie chiavi di crittografia. Il compromesso è un overhead operativo significativo: provisioning, monitoraggio, backup e migrazione devono essere automatizzati per ogni istanza tenant. Il costo scala direttamente con il numero di tenant indipendentemente dall'utilizzo. Raccomandiamo questo pattern per prodotti SaaS di classe enterprise con meno di cento tenant di alto valore dove i requisiti di isolamento giustificano l'investimento infrastrutturale.