Multi-tenancy spiegato:un database, 1.000 clienti

Multi-tenancy spiegato: multi-tenancy significa che più clienti condividono un unico database, ma ogni cliente può vedere solo i propri dati. È il modo in cui un solo founder serve 1.000 organizzazioni da una singola applicazione senza dover ricostruire nulla — e funziona grazie a una colonna che deve esserci su ogni tabella fin dal primo giorno: organization_id.

Se stai costruendo un SaaS con l'AI, questa è una delle poche decisioni architetturali che non puoi correggere a basso costo più avanti. Ecco che cos'è la multi-tenancy, perché la scelta sbagliata costa mesi e le regole esatte da dare alla tua AI perché la faccia bene.

Multi-tenancy spiegato: l'analogia del palazzo di appartamenti

Pensa al tuo SaaS come a un edificio. Ogni cliente è un inquilino. Hai due opzioni.

Potresti costruire una casa separata per ogni cliente. Ogni casa ha bisogno di fondamenta, impianto idraulico e manutenzione propri. Dieci clienti, dieci case. Mille clienti, mille case — e quando vuoi rinnovare la cucina, ristrutturi mille cucine.

Oppure costruisci un unico palazzo di appartamenti. Una fondazione, un impianto idraulico, una squadra di manutenzione. Ogni inquilino ha il suo appartamento, la sua serratura, la sua chiave. Nessuno può entrare nell'appartamento del vicino, ma tu mantieni un solo edificio.

La multi-tenancy è il palazzo di appartamenti. Una sola applicazione, un solo database, un solo deployment — al servizio di ogni cliente, con ciascuno che vede solo i propri dati. È l'architettura standard di quasi ogni prodotto SaaS che usi, ed è ciò che rende possibile l'economia di un SaaS su scala da solopreneur.

I tre modi per servire 1.000 clienti

Tecnicamente gli approcci sono tre. Solo uno ha senso per un founder solitario:

La terza opzione è quella su cui il settore è convergito, ed è l'argomento di questo articolo. Un solo database da mantenere. Una sola modifica da eseguire quando migliori qualcosa. Un solo backup. E puoi scalare da 1 a 10.000 clienti senza modifiche allo schema.

L'unica colonna che serve a ogni tabella

Ecco la regola d'oro: ogni tabella che memorizza dati dei clienti deve avere una colonna organization_id. Non "dovrebbe averla". Non "si può aggiungere dopo". Deve averla, fin dal primo giorno.

Non serve scrivere codice per capirlo. Concettualmente, ogni riga del tuo database riceve un'etichetta che dice a quale cliente appartiene. Nella tabella delle attività di un task manager, "Disegnare la homepage" porta l'etichetta di Acme; "Rivedere i numeri del terzo trimestre" porta quella di TechStart. Ogni volta che l'applicazione legge dati, chiede solo le righe con l'etichetta del cliente corrente. Ogni volta che scrive dati, marchia la nuova riga con quell'etichetta. Acme vede le attività di Acme. TechStart vede quelle di TechStart. L'etichetta è la chiave dell'appartamento.

Sembra noioso. È anche la base che fa funzionare tutto il resto — incluso il livello di sicurezza che la applica automaticamente a livello di database, che merita (e avrà) un articolo tutto suo.

Il libroThe Solopreneur RevolutionLuis Gonçalves su come costruire un'attività da solopreneur con l'IA mentre sei ancora dipendente.Scopri il libro →

"Ma per ora ho un solo cliente"

Lo sento di continuo. Ecco il film che si svolge quando salti la multi-tenancy:

• Giorno 1: costruisci per un cliente. Tutto funziona. Nessuna etichetta necessaria — tutti i dati appartengono comunque a lui.
• Giorno 30: ottieni un secondo cliente. Ora entrambi vedono i dati dell'altro. Panico. Applicare l'etichetta a ogni tabella a posteriori significa circa tre settimane di lavoro, fermo in produzione e clienti arrabbiati.
• Il film alternativo: costruisci con organization_id dal primo giorno. Al giorno 30, il secondo cliente funziona e basta. Al giorno 300, hai 100 clienti e non hai fatto nessuna modifica al database.

Un mio amico ha costruito il suo SaaS senza multi-tenancy. Quando ha raggiunto il decimo cliente, ha passato tre mesi a ricostruire l'intero database. Tre mesi senza nuove funzioni mentre i clienti aspettavano. Non essere quella persona.

È anche per questo che insisto tanto sul progettare il database prima di scrivere il prompt: le decisioni economiche al primo giorno — una colonna, un'abitudine — diventano brutalmente costose al giorno 300.

Le tre regole che la mantengono veloce e sicura

Regola 1: etichetta ogni tabella, senza eccezioni. Nel momento in cui a una tabella manca organization_id, quella tabella è una fuga di dati in attesa di accadere. Quando istruisci la tua AI, rendila un'istruzione permanente, non una richiesta per singola attività — è esattamente il tipo di regola che appartiene alle tue decisioni da architetto, perché l'AI la salterà volentieri se non insisti.

Regola 2: indicizza l'etichetta. Un indice è la rubrica telefonica del database — gli permette di saltare direttamente alle righe di un cliente invece di leggere ogni riga per controllare l'etichetta. La differenza non è accademica: con 1 milione di righe su 1.000 organizzazioni, una ricerca senza indice richiede circa 2.000 millisecondi. Con l'indice, la stessa ricerca ne richiede circa 5. Chiedi alla tua AI di aggiungere un indice su organization_id per ogni tabella che crea.

Regola 3: non fidarti mai del browser per sapere chi sta chiedendo. L'identità del cliente deve venire dalla sessione di login sul server, mai da qualcosa che il browser invia. Se un utente malintenzionato può dire alla tua app "sono l'organizzazione X", può leggere i dati dell'organizzazione X. Il server sa chi è loggato; è l'unica fonte di verità.

Tre regole. Una colonna. È la differenza tra una demo e un prodotto che puoi vendere al tuo secondo, decimo e millesimo cliente.

12 settimaneLa carriera aziendale non è mai stata il pianoCandidati al Solopreneur Accelerator.Candidati ora →

Domande frequenti

Che cosa significa multi-tenancy in parole semplici?

Più clienti (tenant) condividono un'unica applicazione e un unico database, ma ciascuno può vedere solo i propri dati. Come un palazzo di appartamenti: una struttura, tanti appartamenti privati, una chiave per inquilino. È l'architettura standard dei prodotti SaaS.

Mi serve la multi-tenancy se ho un solo cliente?

Sì — è proprio il momento in cui costa poco. Aggiungere una colonna organization_id al primo giorno non ti costa nulla. Aggiungerla dopo l'arrivo del secondo cliente costa settimane; un founder che conosco ha passato tre mesi a ricostruire al decimo cliente. Inseriscila fin dalla prima tabella.

L'AI può configurare la multi-tenancy al posto mio se non so programmare?

Sì, se le dai la regola in modo esplicito: "ogni tabella che memorizza dati dei clienti deve avere una colonna organization_id, con un indice, e ogni query deve filtrare per essa". Gli strumenti di AI seguono questo pattern in modo affidabile quando glielo dici — e lo saltano in modo imprevedibile quando non lo fai. Tu fornisci la regola; l'AI fornisce l'implementazione.

Un database condiviso è abbastanza sicuro per i dati dei clienti?

Sì, se fatto bene. L'etichetta organization_id più la sicurezza a livello di database (la row-level security, che applica l'etichetta automaticamente a ogni query) è il modo in cui praticamente tutto il SaaS moderno gestisce l'isolamento — lo stesso approccio che serve prodotti con migliaia di organizzazioni. L'opzione insicura è la versione a metà: database condiviso, niente etichette, nessuna applicazione della regola.