La maggior parte delle decisioni architetturali costa meno da rivedere che da rimandare. Si può cambiare una coda, sostituire un framework, spostarsi su un altro cloud: costoso, complesso, ma gestibile.
La tenancy è diversa. Il modo in cui separa i dati dei clienti influenza ogni query che scriverà, ogni migration che eseguirà, ogni procedura di backup e ripristino e ogni questionario di sicurezza enterprise che dovrà compilare. Cambiarlo in seguito significa riscrivere il data layer di un sistema in produzione mentre i clienti lo usano.
Vale quindi la pena dedicare un'ora ora. Ecco i tre modelli, confrontati in modo trasparente.
Modello 1: Schema condiviso
Un database, un set di tabelle, una colonna tenant_id su tutto. Ogni query filtra per tenant.
- Costo: il più basso di gran lunga. Un solo database da gestire, uno da salvare, uno da ottimizzare.
- Operatività: la più semplice. Una sola migration, applicata una volta, e tutti i tenant sono sullo schema attuale.
- Scalabilità: ottima per molti tenant di piccole dimensioni. È così che si servono diecimila clienti in modo sostenibile.
- Isolamento: il più debole. Basta dimenticare un
WHERE tenant_id = ?per causare una fuga di dati tra tenant. - Noisy neighbours: reale. Un report pesante di un tenant può peggiorare l'esperienza di tutti.
- Ripristino per tenant: davvero complesso. Ripristinare i dati di un singolo cliente da un backup condiviso è un intervento di precisione.
Il rischio di isolamento è gestibile, ma va affrontato strutturalmente, non affidandosi alla disciplina individuale. Imposti la separazione dei tenant al livello più basso possibile — sicurezza a livello di riga nel database, oppure uno strato di accesso ai dati che renda impossibile scrivere query senza ambito — mai contando sulla memoria di ogni sviluppatore. Il code review non è una misura di sicurezza scalabile.
Se deve trattenere un solo concetto da questo articolo: renda la query senza ambito impossibile da scrivere, non solo sconsigliata. Ogni violazione di schema condiviso che abbiamo letto nasce da una query dimenticata senza filtro.
Modello 2: Schema per tenant
Un database, uno schema separato per ogni tenant. Stesso server, namespace distinti.
- Costo: ancora basso — una sola istanza di database.
- Isolamento: sensibilmente migliore. L’accesso tra tenant richiede un errore deliberato, non solo una clausola dimenticata.
- Ripristino per tenant: realizzabile, cosa che lo schema condiviso non consente.
- Operatività: qui sta la difficoltà. Le migrazioni vanno eseguite per ogni schema e devono essere robuste anche su centinaia di schemi. Una migrazione che riesce solo a metà su 400 schemi è davvero un problema.
- Limite di scalabilità: i database iniziano a soffrire già con poche migliaia di schemi — il pooling delle connessioni e il catalogo diventano il vincolo.
Questa è la soluzione pragmatica intermedia, adatta a piattaforme con decine o poche centinaia di tenant, ciascuno di rilievo commerciale. È anche il modello più spesso scelto per motivi sbagliati — perché sembra più sicuro dello schema condiviso, senza che nessuno abbia valutato il costo degli strumenti di migrazione necessari.
Modello 3: Database per tenant
Ogni tenant dispone del proprio database, a volte anche di un’infrastruttura separata.
- Isolamento: il massimo possibile, e il più semplice da spiegare a chi si occupa di sicurezza.
- Conformità: il modello che risponde in modo diretto ai requisiti di residenza dei dati — il database di questo tenant è a Francoforte, quello di un altro in Virginia.
- Backup, ripristino ed export per tenant: banali. Lo è anche la cancellazione completa di un cliente quando lascia, aspetto più rilevante di quanto si pensi.
- Vicini rumorosi: eliminati. Un tenant non può influire sulle prestazioni di un altro.
- Costo: il più elevato, e cresce linearmente con il numero di tenant, non con l’uso.
- Operatività: la più impegnativa. Migrazioni, monitoraggio, backup e aggiornamenti si moltiplicano; serve automazione reale prima di raggiungere numeri significativi di tenant.
Questo modello si giustifica solo in un caso: clienti enterprise il cui processo di procurement lo richiede. Se i buyer inviano questionari di sicurezza chiedendo dove risiedono fisicamente i dati e se condividono infrastruttura con altri, questa è la risposta che vogliono, e può fare la differenza tra vincere o perdere la commessa.
La scelta
Valuti questi aspetti in ordine:
- Chi è il cliente? Migliaia di piccoli tenant suggeriscono schema condiviso. Decine di grandi imprese indicano database per tenant. Un mix richiede un modello ibrido — veda sotto.
- Che cosa richiede davvero la conformità? Non ciò che sembra più sicuro. Legga gli obblighi. Data residency e assenza di infrastruttura condivisa sono requisiti specifici con risposte specifiche; l’ansia generalizzata non lo è.
- A quale fascia di prezzo vende? Il database per tenant ha un costo minimo per cliente. Se questo minimo rappresenta una quota rilevante del prezzo mensile, il modello non è adatto a quel segmento.
- Qual è la reale capacità operativa del suo team? Scegliere un modello di isolamento che il team non può automatizzare equivale a scegliere un’interruzione di servizio.
- Quanto è probabile un ripristino per tenant? Se è plausibile che un cliente cancelli accidentalmente i propri dati, lo schema condiviso sarà un problema.
L'ibrido, e perché di solito prevale
La maggior parte delle piattaforme di successo adotta un modello misto: schema condiviso per la fascia self-serve, database dedicati per i clienti enterprise che li richiedono. È una soluzione legittima e frequente.
È anche molto più semplice da raggiungere se la si prevede fin dall’inizio. Realizzare uno strato di risoluzione dei tenant che sappia instradare verso un database condiviso oppure uno dedicato ha un costo minimo all’avvio ed è ciò che rende possibile l’ibrido in seguito. Inserirlo a posteriori in un codice che assumeva una sola stringa di connessione è dove si concentra il vero costo.
Se ha dubbi, costruisca lo schema condiviso dietro un’astrazione che possa instradare per tenant. Ottiene ora il modello economico e mantiene la possibilità di passare a quello più costoso in futuro — il contrario della situazione in cui finiscono la maggior parte dei team.
Ciò che la vincola comunque
Qualunque modello scelga, queste decisioni si consolidano insieme e meritano la stessa attenzione:
- Identità del tenant nel suo sistema di autenticazione. Aggiungere la multi-tenancy a un modello single-tenant è complesso; decida subito se un utente può appartenere a più tenant.
- Se gli ID dei tenant sono esposti in URL e API. Cambiare questa scelta in seguito rompe le integrazioni realizzate dai clienti.
- Dove risiede la configurazione per tenant. Nei dati del tenant o in un registro centrale? Entrambe le soluzioni funzionano; mescolarle no.
- Come gestisce una fusione o una divisione di tenant. Evento raro, ma critico se il modello dati non lo prevede — i clienti acquisiscono altri clienti.
- Il modello di job in background. Code per tenant, scheduling equo e limiti di rate per tenant sono molto più semplici da progettare che da aggiungere dopo.
La domanda dietro la domanda
Di solito si arriva a questa scelta perché qualcuno chiede i nostri dati sono sicuri? — e si opta per l’isolamento massimo come rassicurazione. È comprensibile, ma costoso.
L’isolamento è solo uno dei controlli. Una piattaforma database-per-tenant con controlli deboli, senza audit log e con una backdoor amministrativa condivisa è meno sicura di una piattaforma a schema condiviso ben progettata, con sicurezza a livello di riga e autorizzazione corretta. Scelga il modello di tenancy in base a requisiti ed economia; la sicurezza va acquistata separatamente, in modo deliberato e su più livelli.
Questo è il tipo di decisione che affrontiamo prima di scrivere una riga di codice — veda quanto costa davvero una piattaforma Node.js personalizzata per capire l’impatto sul budget. Il nostro team Node.js e il nostro team full-stack lavorano su questi aspetti insieme al cliente, non al suo posto, perché la risposta dipende da dati commerciali che solo il cliente possiede. Dove i buyer sono regolamentati — come in finanza e sanità — sono i requisiti di conformità a decidere.
Domande frequenti
Con quale modello di tenancy dovrebbe partire un nuovo SaaS?
Schema condiviso, dietro uno strato di risoluzione del tenant in grado di instradare verso un database dedicato in futuro. Così si ottiene il modello più economico ora, mantenendo la possibilità di passare a quello più costoso — il contrario della situazione in cui la maggior parte dei team si trova bloccata.
Come si prevengono fughe di dati tra tenant in uno schema condiviso?
Imporre la separazione dei tenant sotto il livello applicativo: sicurezza a livello di riga nel database, oppure uno strato di accesso ai dati dove scrivere una query senza ambito sia impossibile. Affidarsi al fatto che gli sviluppatori ricordino la clausola WHERE non è un controllo, e il code review non è una soluzione scalabile.
Quando vale la pena adottare un database per tenant?
Quando la procurement aziendale lo richiede — residenza dei dati in una specifica giurisdizione, oppure una garanzia documentata di assenza di infrastruttura condivisa. Se i suoi clienti inviano questionari di sicurezza con queste domande, questo modello è quello che fa concludere l'accordo. Altrimenti, è solo una rassicurazione costosa.
È possibile cambiare modello di tenancy in seguito?
Sì, ma con costi rilevanti. Significa riscrivere lo strato di accesso ai dati, migrare i dati dei clienti in produzione e validare nuovamente ogni query, mentre la piattaforma resta attiva. Costruire un'astrazione di routing fin dall'inizio riduce molto i costi; non averla è ciò che rende la scelta difficile da invertire.
La multi-tenancy influisce sulle prestazioni?
Con schema condiviso, sì — il carico di lavoro di un tenant può degradare le prestazioni degli altri, motivo per cui limiti di rate per tenant e una pianificazione equa dei job sono fondamentali. I database dedicati eliminano il problema, ma aumentano la complessità operativa da gestire.
Far revisionare la decisione prima di procedere
Ci dica chi sono i suoi clienti e cosa chiede il loro procurement, e le diremo quale modello serve davvero alla sua azienda — di solito quello più economico. Contatti il nostro team; rispondiamo entro un giorno lavorativo.