Un'azienda di servizi B2B con un organico di circa quaranta persone ha appena lanciato un nuovo tool interno basato su Supabase per gestire i progetti dei clienti. Il successo è immediato, l'adozione rapida, e presto l'idea di trasformare questo 'tool interno' in un vero e proprio SaaS multi-tenant inizia a farsi strada. Il dilemma è classico: come garantire che i dati di un cliente siano completamente isolati da quelli di un altro, mantenendo performance e gestibilità? Non è solo una questione tecnica, ma una scelta strategica che impatta costi di sviluppo, sicurezza e scalabilità futura.
Nel nostro approccio in Logika.studio, quando affrontiamo la progettazione di un'architettura multi-tenant su piattaforme come Supabase (che offre un'ottima base PostgreSQL con autenticazione e real-time), osserviamo principalmente tre pattern ricorrenti. La scelta non è mai scontata, e spesso il 'migliore' è quello che si adatta alle esigenze attuali del business, prevedendo però un percorso di crescita. Ignorare questi tradeoff può portare a costose re-ingegnerizzazioni.
RLS-only: La Semplicità per Iniziare
Il pattern più immediato e spesso il primo che viene in mente è quello basato esclusivamente sulla Row Level Security (RLS) di PostgreSQL. Supabase, con la sua integrazione nativa e il supporto a Drizzle o altri ORM moderni, rende l'implementazione relativamente semplice. Ogni riga di dati nel database viene associata a un tenant_id e le policy RLS assicurano che un utente possa vedere e modificare solo le righe appartenenti al suo tenant.
Vantaggi:
- Costo: Meno overhead infrastrutturale, poiché tutti i dati risiedono nello stesso database e nelle stesse tabelle. Si sfrutta al massimo un unico piano Supabase, potenzialmente partendo dal livello gratuito o 'Pro' per un costo di 25$/mese, per poi scalare.
- Semplicità di Sviluppo Iniziale: Implementazione rapida per MVP e primi tenant. Next.js 15, Vercel e Clerk per l'autenticazione si integrano fluidamente.
- Gestione Unificata: Backup, monitoring e aggiornamenti riguardano un'unica istanza.
Svantaggi:
- Performance a Scala: Con migliaia di tenant e milioni di righe, le policy RLS possono introdurre un overhead significativo su ogni query, rallentando le performance. Ogni query deve valutare le condizioni di sicurezza.
- Complessità di Policy: La gestione di policy RLS complesse, soprattutto quando si introducono ruoli utente diversi all'interno di un tenant, può diventare un incubo da debuggare e mantenere.
- Isolamento Logico Debole: Sebbene robusto a livello di sicurezza se configurato correttamente, l'isolamento è solo logico. Tutti i dati sono fisicamente nello stesso contenitore. Questo può essere un limite per certi requisiti di compliance. Come abbiamo discusso in un articolo sulla sicurezza AI, la protezione dei dati è multifattoriale.
Quando usarlo: Ideale per startup early-stage, tool interni, o SaaS con un numero limitato di tenant (<100) e requisiti di compliance meno stringenti.
Schema-per-tenant: Bilanciare Isolamento e Gestibilità
Un'evoluzione rispetto all'RLS puro è l'approccio schema-per-tenant. In questo pattern, ogni cliente (tenant) ha un proprio schema all'interno dello stesso database PostgreSQL. Ogni schema contiene le tabelle relative solo a quel tenant (es. tenant_a.users, tenant_a.projects). L'applicazione, al momento della connessione o della sessione, cambia il search_path di PostgreSQL per puntare allo schema del tenant corrente.
Vantaggi:
- Isolamento Logico Forte: I dati di ogni tenant sono separati in schemi distinti, il che offre un livello di isolamento superiore rispetto all'RLS. Questo semplifica backup e restore granulari.
- Performance Migliorate: Senza le costanti valutazioni RLS su ogni query, le performance possono essere migliori a scale intermedie.
- Migrazioni Facilitate: Possibilità di eseguire migrazioni di database specifiche per un singolo tenant, se necessario.
- Scalabilità Cost-Effective: Si usa ancora un unico database, ma con una migliore segmentazione. Il costo del piano Supabase potrebbe essere un 'Business' (circa 250$/mese) per supportare più connessioni e CPU.
Svantaggi:
- Complessità Operativa: La gestione degli schemi (creazione, migrazione, aggiornamento) richiede automazione e attenzione. La gestione delle connessioni e del connection pooling diventa cruciale per evitare problemi di performance.
- Costo di Sviluppo Iniziale: Richiede più lavoro per impostare l'infrastruttura di gestione degli schemi e modificare l'applicazione per gestire il
search_path. - Limiti di Connessione: Anche se meno stringenti di RLS, un singolo database ha limiti sul numero di connessioni simultanee, il che può diventare un collo di bottiglia con molti tenant attivi.
Quando usarlo: SaaS in fase di crescita, con centinaia o migliaia di tenant, che necessitano di un isolamento più robusto e flessibilità nelle migrazioni, ma non sono ancora pronti per l'overhead di un database dedicato per ogni cliente.
DB-per-tenant: L'Isolamento Definitivo
L'approccio più radicale e costoso è quello di dedicare un intero database (e quindi una singola istanza Supabase) a ogni tenant. Ogni cliente ha la sua infrastruttura dati completamente separata.
Vantaggi:
- Massimo Isolamento e Sicurezza: Nessun rischio di 'noisy neighbors'. Ogni tenant ha le sue risorse dedicate, essenziale per requisiti di compliance molto stringenti (es. HIPAA, GDPR in contesti specifici) o per clienti enterprise che richiedono la propria infrastruttura.
- Performance Dedicate: Ogni cliente beneficia delle risorse complete del proprio database, senza contese.
- Flessibilità di Scalabilità: Si può scalare verticalmente un singolo database per un cliente ad alto traffico senza influenzare gli altri.
- Backup e Restore Indipendenti: Estremamente facile gestire operazioni specifiche per ogni tenant.
Svantaggi:
- Costo Infrastrutturale Elevato: Moltiplica il costo del database per il numero di tenant. Anche con piani Supabase 'Pro' a 25$/mese, con 100 tenant si parla già di 2500$/mese solo per i database, più il costo di orchestrazione.
- Complessità di Gestione e Deployment: La gestione di centinaia o migliaia di istanze database separate è un compito enorme. Deployment, monitoraggio, aggiornamenti e patching richiedono automazione sofisticata e team dedicati. È qui che il vantaggio di piattaforme come Supabase (che gestiscono l'infrastruttura) si scontra con la moltiplicazione delle istanze da parte dell'utente.
- Tempo di Sviluppo: Richiede un investimento significativo in automazione per provisionare e gestire i nuovi database.
Quando usarlo: Grandi enterprise, settori altamente regolamentati, o clienti con esigenze specifiche di performance e isolamento che giustificano l'alto costo e la complessità operativa. Raramente è la prima scelta per una startup.
La scelta del pattern multi-tenant è una decisione architetturale chiave. In Logika.studio, abbiamo osservato come spesso l'RLS sia un ottimo punto di partenza per validare un prodotto, per poi evolvere verso un approccio schema-per-tenant man mano che il business cresce e i requisiti di isolamento si fanno più stringenti. Il DB-per-tenant rimane un'opzione per casi d'uso molto specifici e ad alto valore, dove la gestione della complessità è giustificata dai benefici. La chiave è progettare con la scalabilità in mente, sapendo che una transizione tra questi pattern è possibile, ma richiede un'attenta pianificazione.
Se la complessità dell'isolamento multi-tenant ti preoccupa o stai valutando la migrazione del tuo SaaS, il nostro audit gratuito da 30 minuti è disponibile su Logika.studio/audit — analisi rapida, 2-3 punti concreti, zero pitch.
