Hai un'idea per un SaaS B2B. Hai validato il problema, hai i primi prospect interessati, forse hai anche un foglio Excel che gira tra i beta tester. A questo punto arriva la domanda che blocca tutto: come si costruisce tecnicamente una piattaforma che serva decine o centinaia di clienti, ognuno con i propri dati, senza che l'infrastruttura esploda al terzo cliente pagante?
La risposta passa dall'architettura multi-tenant. E capire questa scelta prima di scrivere la prima riga di codice ti risparmia mesi di refactoring costoso.
In questa guida vediamo cos'è concretamente un'architettura multi-tenant, quali strategie esistono per lo sviluppo multi-tenant SaaS, quando usare Laravel e quando no, e quali errori fanno perdere tempo ai founder italiani nella fase di costruzione.
Un SaaS multi-tenant è un'applicazione dove una sola istanza del software serve più clienti distinti, chiamati tenant. Ogni tenant, che sia un'azienda o un team, vede solo i propri dati e opera in modo indipendente dagli altri.
Il contrario è il modello single-tenant: ogni cliente ha la sua istanza separata, il suo server, il suo database. Semplice da gestire per il cliente, un incubo operativo per te che devi aggiornare cinquanta ambienti diversi ogni volta che rilasci una patch.
Il multi-tenant risolve questo problema: aggiorni una volta, tutti i tenant ricevono la nuova versione. I costi infrastrutturali si distribuiscono. La complessità operativa resta gestibile anche con cento clienti.
Il prezzo da pagare è la complessità architetturale iniziale. Devi progettare l'isolamento dei dati fin dall'inizio, perché aggiungerlo dopo è doloroso.
Quando costruisci un SaaS da zero, la prima decisione tecnica reale riguarda come separare i dati tra tenant. Ci sono tre approcci principali.
Database separato per tenant. Ogni cliente ha il proprio database fisico. L'isolamento è massimo: una query mal scritta non può mai "vedere" i dati di un altro tenant. Il backup per cliente è semplice. Il problema è il costo: cento tenant significano cento database da mantenere, migrare, monitorare. Ha senso se vendi a grandi aziende con requisiti di compliance severi (settore finanziario, sanitario) e puoi far pagare prezzi alti.
Schema separato per tenant (su PostgreSQL). Un solo database, ma ogni tenant ha il proprio schema. È il compromesso più usato per SaaS B2B: buon isolamento, costi contenuti, migrazioni gestibili con strumenti come Flyway o le migration di Laravel. Se non hai vincoli di compliance estremi, questa è spesso la scelta più sensata.
Row-level isolation su database condiviso. Un solo database, un solo schema, ogni tabella ha una colonna tenant_id. Economicissimo, ma richiede una disciplina assoluta: ogni query deve filtrare per tenant_id, senza eccezioni. Un errore e i dati di un cliente finiscono visibili a un altro. Per ridurre il rischio si usa Row Level Security di PostgreSQL, che sposta il controllo a livello di database invece di affidarsi solo all'applicazione.
| Strategia | Isolamento | Costo infrastruttura | Complessità migrazione | Adatta a |
|---|---|---|---|---|
| Database separato | Massimo | Alto | Alta | Enterprise, compliance severa |
| Schema separato | Alto | Medio | Media | SaaS B2B mid-market |
| Row-level isolation | Medio | Basso | Bassa | SaaS con molti piccoli tenant |
La scelta dipende dal tuo mercato, non dalla tua preferenza tecnica. Se vendi a PMI con cinquanta dipendenti, lo schema separato ti dà abbastanza isolamento senza farti esplodere i costi. Se vendi a ospedali o banche, il database separato è quasi sempre richiesto contrattualmente.
Laravel è una scelta solida per costruire un SaaS B2B di medie dimensioni. L'ecosistema è maturo, la documentazione è eccellente, e per il multi-tenancy esiste il pacchetto Tenancy for Laravel (tenancyforlaravel.com) che gestisce gran parte della complessità infrastrutturale: routing per tenant, context switching, migrazione degli schemi.
Con Laravel 11 e Tenancy, il flusso tipico funziona così:
cliente.tuoapp.com) o da un header HTTP.tenant_id a ogni query.Questo approccio riduce il rischio di data leak da query non filtrate, che è il problema principale del row-level isolation fatto a mano.
Un aspetto che spesso si sottovaluta: la gestione dei job in coda. Se usi Laravel Queues, ogni job deve portare con sé il contesto del tenant, altrimenti i worker non sanno in quale database operare. Tenancy gestisce questo automaticamente, ma devi configurarlo esplicitamente per i job che escono dal ciclo request/response normale.
Dove Laravel mostra i limiti: se il tuo SaaS ha requisiti di real-time intensivo (WebSocket su decine di migliaia di connessioni simultanee) o processa stream di dati ad alto volume, probabilmente hai bisogno di componenti specializzati accanto a Laravel, non di sostituirlo in toto.
Questo è il punto che quasi nessuna guida tecnica tocca, e secondo noi è un errore grave: molti founder italiani passano settimane a discutere di database separati vs schema separati, e poi lanciano il loro SaaS con un modello di pricing che non si integra affatto con l'architettura scelta.
Se usi database separati per tenant e offri un piano da pochi euro al mese, stai perdendo denaro su ogni cliente. Il costo di provisioning e mantenimento di un database dedicato supera il ricavo. La scelta tecnica deve essere coerente con il ticket medio che puoi ragionevolmente aspettarti dal tuo mercato.
Questo vale anche in senso inverso: se vendi a grandi aziende con ticket medio alto e usi row-level isolation senza Row Level Security di PostgreSQL, stai rischiando un incidente di sicurezza che può costarti il cliente più importante.
Architettura e modello di business si devono progettare insieme, non in sequenza.
Se stai costruendo un SaaS da zero, un MVP che ti permette di acquisire i primi clienti paganti richiede un insieme minimo di componenti. Non serve tutto subito.
Il nucleo irrinunciabile è: autenticazione con supporto multi-tenant (ogni utente appartiene a un tenant), isolamento dei dati tra tenant, gestione del billing (anche basica, con Stripe), e un sistema di onboarding che permetta a un nuovo tenant di attivarsi senza intervento manuale da parte tua.
Quello che puoi rimandare: personalizzazione avanzata per tenant (white-label, temi, configurazioni custom), SSO enterprise, audit log completo, dashboard di analytics interna. Queste funzionalità sono reali esigenze di clienti enterprise, però arrivano dopo, quando hai già validato che qualcuno paga.
Un MVP realizzato con questa logica richiede qualche mese di sviluppo con un team piccolo. La variabile principale è la complessità del dominio applicativo, non dell'architettura multi-tenant in sé. Un SaaS per la gestione delle turni di un ristorante ha una logica di dominio molto più semplice di un SaaS per la pianificazione finanziaria di una holding.
Se stai valutando come strutturare il tuo progetto, raccontaci il tuo caso e vediamo insieme quale approccio ha senso.
Il primo errore è progettare l'isolamento dei dati come un'aggiunta successiva. "Per ora lo facciamo senza multi-tenancy, poi lo aggiungiamo." Questa frase precede quasi sempre un refactoring da tre mesi. L'isolamento dei tenant va nel codice dal primo giorno, anche se il primo cliente sei tu che testi.
Il secondo è copiare l'architettura di un SaaS americano da cento milioni di dollari di ARR. Kubernetes, microservizi, event sourcing, CQRS: tutto bellissimo su carta, tutto sbagliato per un prodotto che non ha ancora dieci clienti paganti. Parti monolitico con Laravel, aggiungi complessità solo quando hai un problema reale da risolvere.
Il terzo errore, sottovalutato, riguarda la gestione delle migrazioni di database in produzione. Con un database condiviso, una migrazione mal scritta blocca tutti i tenant contemporaneamente. Con database o schemi separati, devi migrare ogni tenant in sequenza, il che richiede strumenti e processi specifici. Questo problema va pensato prima di andare in produzione, non dopo.
Costruire una piattaforma SaaS su misura richiede risorse, tempo e una visione chiara di dove vuoi arrivare. Ci sono casi in cui non è la scelta giusta.
Se il tuo vantaggio competitivo non sta nella logica applicativa ma nella distribuzione o nel brand, probabilmente puoi partire con strumenti esistenti e rimandare lo sviluppo custom. Se non hai ancora validato che i clienti pagano per il problema che risolvi, investire in un'architettura multi-tenant completa è prematuro.
Lo sviluppo custom ha senso quando la logica di business è abbastanza complessa o proprietaria da non poter essere replicata con strumenti generici, quando hai già segnali chiari di domanda, e quando il controllo sull'architettura ti dà un vantaggio concreto rispetto ai competitor che usano piattaforme standard.
Q: Cos'è un'architettura multi-tenant in un SaaS?
A: In un SaaS multi-tenant, una singola istanza dell'applicazione serve più clienti mantenendo i dati separati e isolati. Ogni tenant vede solo i propri dati, ma condivide la stessa infrastruttura. Questo riduce i costi operativi rispetto a istanze dedicate per ciascun cliente.
Q: Quale strategia di isolamento dati conviene scegliere?
A: Dipende dal tuo mercato. Database separati per tenant offrono il massimo isolamento ma aumentano i costi. Schema separato per tenant su PostgreSQL è un buon compromesso per la maggior parte dei SaaS B2B. Row-level isolation su database condiviso è la più economica, ma richiede una disciplina assoluta su ogni query.
Q: Quanto ci vuole per costruire un SaaS multi-tenant da zero?
A: Un MVP funzionante con autenticazione, gestione tenant, billing base e due o tre funzionalità core richiede qualche mese di sviluppo con un team piccolo. La variabile principale è la complessità del dominio applicativo, non dell'architettura multi-tenant in sé.
Q: Laravel è una buona scelta per costruire un SaaS multi-tenant?
A: Sì, per SaaS B2B di medie dimensioni è una scelta solida. Il pacchetto Tenancy for Laravel gestisce gran parte della complessità infrastrutturale. Per SaaS con volumi molto alti o requisiti di real-time intensivo, valuta se servono componenti aggiuntivi specializzati.
Q: Quando ha senso sviluppare un SaaS custom invece di usare una piattaforma no-code?
A: Quando il tuo vantaggio competitivo sta nella logica applicativa. Se il processo che vuoi automatizzare è standard, un no-code può bastare. Se la logica di business è complessa o proprietaria, lo sviluppo custom è l'unica strada che non ti chiude in un vicolo cieco nel momento in cui cresci.
Se hai già un'idea di SaaS validata e stai affrontando le prime scelte architetturali, in Press Start possiamo aiutarti a strutturare l'architettura multi-tenant prima di scrivere la prima riga di codice. Raccontaci il tuo progetto
