Opzioni di modello dati SaaS multi-tenant per un backend no-code

Il problema: mantenere i tenant separati senza rallentare

La multi-tenancy significa che un prodotto software serve molti clienti (tenant), e ogni tenant deve vedere solo i propri dati. La parte difficile è farlo in modo coerente: non solo in una schermata, ma in ogni chiamata API, pannello di amministrazione, esportazione e job in background.

Il tuo modello dati influisce sulle operazioni quotidiane più di quanto molti team si aspettino. Determina permessi, reporting, velocità delle query man mano che cresci e quanto rischioso può essere un "piccolo" bug. Se ti perdi un filtro puoi divulgare dati. Se isoli troppo, il reporting diventa un compito gravoso.

Ci sono tre modi comuni per strutturare un modello dati multi-tenant SaaS:

• Un database dove ogni tabella include un tenant_id
• Schemi separati per tenant all'interno di un database
• Database separati per tenant

Anche se costruisci visivamente in un backend no-code, gli stessi compromessi si applicano. Strumenti come AppMaster generano codice backend reale e strutture di database dal tuo design, quindi le decisioni di modellazione iniziali emergono rapidamente nel comportamento e nelle prestazioni in produzione.

Immagina uno strumento di helpdesk. Se ogni riga del ticket ha tenant_id, è semplice interrogare "tutti i ticket aperti", ma devi applicare i controlli sul tenant ovunque. Se ogni tenant ha il proprio schema o database, l'isolamento è più forte per default, ma il reporting cross-tenant (come "tempo medio di chiusura tra tutti i clienti") richiede più lavoro.

L'obiettivo è una separazione di cui ti puoi fidare senza aggiungere attrito al reporting, al supporto e alla crescita.

Un modo rapido per scegliere: 4 domande che restringono le opzioni

Non partire dalla teoria dei database. Parti da come il prodotto sarà usato e da cosa ti servirà operare ogni settimana.

Quattro domande che di solito rendono la risposta ovvia

1. Quanto sono sensibili i dati e sei soggetto a regole severe? Sanità, finanza e contratti stringenti con i clienti spesso spingono verso un isolamento più forte (schema separato o database separato). Può ridurre il rischio e semplificare le verifiche.

2. Hai bisogno spesso di reporting cross-tenant? Se regolarmente ti servono metriche “tutti i clienti” (uso, ricavi, prestazioni), un singolo database con tenant_id è di solito la soluzione più semplice. Database separati rendono questo più complesso perché devi interrogare molti posti e unire i risultati.

3. Quanto diversi saranno i tenant tra loro? Se i tenant necessitano di campi personalizzati, workflow custom o integrazioni uniche, schemi o database separati possono ridurre la probabilità che le modifiche si propagino. Se la maggior parte dei tenant condivide la stessa struttura, tenant_id rimane pulito.

4. Cosa il tuo team può realisticamente gestire operativamente? Più isolamento di solito significa più lavoro: più backup, più migrazioni, più componenti e più punti in cui possono nascondersi i guai.

Un approccio pratico è prototipare le tue prime due scelte, poi testare i veri punti dolenti: regole di permesso, query di reporting e come le modifiche si applicano mentre il modello evolve.

Approccio 1: un database con tenant_id su ogni riga

Questa è la configurazione più comune: tutti i clienti condividono le stesse tabelle e ogni record di proprietà del tenant porta un tenant_id. È operativo semplice perché gestisci un solo database e un unico set di migrazioni.

La regola è ferrea: se una riga appartiene a un tenant, deve includere tenant_id, e ogni query deve filtrare per esso. Le tabelle tipicamente scoperte da tenant includono users, roles, projects, tickets, invoices, messages, metadati dei file e tabelle di join che collegano dati del tenant.

Per ridurre le fughe, tratta tenant_id come non negoziabile:

• Rendi tenant_id obbligatorio (NOT NULL) nelle tabelle di proprietà del tenant
• Aggiungi indici che iniziano con tenant_id (per esempio, tenant_id, created_at)
• Includi tenant_id nelle regole di unicità (come email uniche per tenant)
• Passa tenant_id attraverso ogni API e flusso di business, non solo nei form della UI
• Fai rispettare lo scoping nel backend, non solo nei filtri lato client

In PostgreSQL, le row-level security possono aggiungere una solida rete di sicurezza, specialmente quando le query vengono generate dinamicamente.

I dati di riferimento rientrano solitamente in due categorie: tabelle condivise (come countries) senza tenant_id, e cataloghi con ambito tenant (come tag personalizzati o pipeline) che includono tenant_id.

Se stai costruendo con AppMaster, un'abitudine semplice evita la maggior parte degli incidenti: imposta tenant_id dal tenant dell'utente autenticato prima di ogni operazione di creazione o lettura nella logica del Business Process, e mantieni quel pattern coerente.

Impatto sui permessi: cosa cambia con ogni approccio

I permessi sono il punto in cui la multi-tenancy ha successo o fallisce. La struttura dati che scegli modifica come memorizzi gli utenti, come scopi le query e come eviti i momenti “oops” nei pannelli admin.

Con un singolo database e tenant_id su ogni riga, i team spesso usano un'unica tabella Users condivisa e collegano ogni utente a un tenant e a uno o più ruoli. La regola principale resta la stessa: ogni lettura e scrittura deve includere lo scopo tenant, anche per tabelle “piccole” come settings, tag o log.

Con schemi separati, spesso mantieni uno strato di identità condiviso (login, password, MFA) in un posto, mentre i dati dei tenant vivono in uno schema per tenant. I permessi diventano in parte un problema di routing: l'app deve indirizzare le query allo schema corretto prima che la logica di business venga eseguita.

Con database separati, l'isolamento è massimo, ma la logica dei permessi si sposta nell'infrastruttura: scegliere la connessione giusta al database, gestire le credenziali e trattare gli account del personale “globale”.

Tra tutti e tre gli approcci, alcuni pattern riducono costantemente il rischio cross-tenant:

• Metti tenant_id nella sessione o nelle claim del token di auth e trattalo come obbligatorio.
• Centralizza i controlli sul tenant in un unico punto (middleware o un Business Process condiviso), non sparpagliati sugli endpoint.
• Negli strumenti admin, mostra chiaramente il contesto tenant e richiedi un cambio tenant esplicito.
• Per l'accesso di supporto, usa l'impersonazione con audit log.

In AppMaster, questo solitamente significa memorizzare il contesto tenant subito dopo l'autenticazione e riutilizzarlo negli endpoint API e nei Business Processes in modo che ogni query rimanga scopingata. Un agente di supporto dovrebbe vedere ordini solo dopo che l'app ha impostato il contesto tenant, non perché l'interfaccia ha applicato un filtro per caso.

Reporting e prestazioni con il modello tenant_id

Con l'approccio a database singolo e tenant_id, il reporting è generalmente semplice. Le dashboard globali (MRR, iscrizioni, uso) possono eseguire una singola query su tutti e i report a livello di tenant sono la stessa query con un filtro.

Il compromesso è la performance nel tempo. Man mano che le tabelle crescono, un tenant molto attivo può diventare un "noisy neighbor" creando molte righe, scatenando scritture e rallentando query comuni se il database deve scansionare troppo.

L'indicizzazione mantiene sano questo modello. La maggior parte delle letture a livello tenant dovrebbe poter usare un indice che inizi con tenant_id, così il database può saltare direttamente alla porzione di dati del tenant.

Una buona baseline:

• Aggiungi indici compositi dove tenant_id è la prima colonna (ad esempio, tenant_id + created_at, tenant_id + status, tenant_id + user_id)
• Mantieni gli indici veramente globali solo quando servono query cross-tenant
• Sorveglia join e filtri che "dimenticano" tenant_id, che possono causare scansioni lente

Retention e cancellazioni richiedono anche un piano perché la storia di un tenant può gonfiare le tabelle per tutti. Se i tenant hanno policy di retention diverse, considera soft delete più archiviazione pianificata per tenant, o spostare le righe vecchie in una tabella di archivio indicizzata per tenant_id.

Approccio 2: schemi separati per tenant

Con gli schemi separati usi ancora un database PostgreSQL, ma ogni tenant ottiene il proprio schema (per esempio, tenant_42). Le tabelle dentro quel schema appartengono solo a quel tenant. È come dare a ogni cliente un “mini-database” senza l'overhead di gestirne molti.

Una configurazione comune mantiene i servizi globali in uno schema condiviso e i dati dei tenant in schemi separati. La divisione riguarda solitamente cosa deve essere condiviso tra tutti i clienti e cosa non deve mai mescolarsi.

Divisione tipica:

• Schema condiviso: tabella tenants, piani, record di fatturazione, feature flag, impostazioni di audit
• Schema tenant: tabelle di business come orders, tickets, inventory, projects, campi personalizzati
• Uno o l'altro (dipende dal prodotto): users e ruoli, specialmente se gli utenti possono accedere a più tenant

Questo modello riduce il rischio di join cross-tenant perché le tabelle vivono in namespace diversi. Può anche rendere più semplice fare backup o restore di un singolo tenant puntando a uno schema.

Le migrazioni sono ciò che sorprende i team. Quando aggiungi una nuova tabella o colonna, devi applicare la modifica a ogni schema tenant. Con 10 tenant è gestibile. Con 1.000, ti serve un processo: tracciare le versioni dello schema, eseguire migrazioni a blocchi e fallire in modo sicuro così che un tenant rotto non blocchi gli altri.

I servizi condivisi come auth e billing solitamente vivono fuori dagli schemi tenant. Un pattern pratico è auth condivisa (una tabella utenti con una tabella di membership tenant) e billing condiviso (ID cliente Stripe, fatture), mentre gli schemi tenant memorizzano i dati di business di proprietà del tenant.

Se usi AppMaster, pianifica presto come i modelli del Data Designer si mappano su shared vs tenant schema e mantieni i servizi globali stabili così gli schemi tenant possono evolvere senza rompere login o pagamenti.

Reporting e prestazioni con schemi separati

Gli schemi separati offrono un isolamento di default più forte rispetto al solo filtro tenant_id perché le tabelle sono fisicamente distinte e i permessi possono essere impostati per schema.

Il reporting è ottimo quando la maggior parte dei report è a livello tenant. Le query restano semplici perché leggi dalle tabelle di un solo tenant senza dover filtrare costantemente tabelle condivise. Questo modello supporta anche tenant “speciali” che richiedono tabelle extra o colonne custom senza costringere tutti gli altri a portarle.

Il reporting aggregato tra tutti i tenant è dove gli schemi iniziano a creare problemi. Devi o avere un livello di reporting che interroga molti schemi, o mantenere tabelle di riepilogo condivise in uno schema comune.

Pattern comuni:

• Dashboard per tenant che interrogano solo lo schema di quel tenant
• Uno schema analytics centrale con rollup notturni da ogni tenant
• Job di export che copiano i dati tenant in un formato adatto a un data warehouse

Le prestazioni sono generalmente solide per i carichi a livello tenant. Gli indici sono più piccoli per tenant e scritture pesanti in uno schema sono meno propense a impattare gli altri. Lo svantaggio è l'overhead operativo: creare un nuovo tenant significa creare uno schema, eseguire migrazioni e mantenere ogni schema allineato quando il modello cambia.

Gli schemi sono adatti quando vuoi isolamento più stringente senza il costo di molti database, o quando prevedi personalizzazioni per tenant.

Approccio 3: database separato per tenant

Con un database separato per tenant, ogni cliente ottiene il proprio database (o il proprio database sullo stesso server). Questa è l'opzione più isolata: se i dati di un tenant vengono corrotti, mal configurati o subiscono un carico elevato, è molto meno probabile che ricada sugli altri.

È ideale per ambienti regolamentati (sanità, finanza, governo) o clienti enterprise che si aspettano separazione rigorosa, regole di retention personalizzate o risorse dedicate.

L'onboarding diventa un workflow di provisioning. Quando un nuovo tenant si iscrive, il sistema deve creare o clonare un database, applicare lo schema base (tabelle, indici, vincoli), creare e memorizzare credenziali in modo sicuro e instradare le richieste API al database corretto.

Se costruisci con AppMaster, la scelta progettuale chiave è dove conservare la directory tenant (una mappa centrale tenant → connessione database) e come assicurare che ogni richiesta utilizzi la connessione giusta.

Upgrade e migrazioni sono il compromesso principale. Una modifica di schema non è più “esegui una volta”, è “esegui per ogni tenant”. Questo aggiunge lavoro operativo e rischio, quindi i team spesso versionano gli schemi ed eseguono migrazioni come job controllati che tracciano lo stato per tenant.

Il vantaggio è il controllo. Puoi aggiornare prima i tenant grandi, osservare le prestazioni e poi distribuire gradualmente le modifiche.

Reporting e prestazioni con database separati

I database separati sono i più semplici da ragionare. Le letture cross-tenant accidentali sono molto meno probabili e un errore di permesso tende a coinvolgere un solo tenant.

Le prestazioni sono un altro punto di forza. Query pesanti, grandi importazioni o un report fuori controllo nel Tenant A non rallenteranno il Tenant B. Questo protegge fortemente dai noisy neighbors e ti permette di ottimizzare risorse per tenant.

Lo svantaggio si vede nel reporting: l'analisi globale diventa la cosa più difficile perché i dati sono fisicamente separati. Pattern pratici includono copiare eventi chiave o tabelle in un database di reporting centrale, inviare eventi a un data warehouse, eseguire report per tenant e aggregare i risultati (quando il numero di tenant è piccolo) e mantenere le metriche di prodotto separate dai dati cliente.

Il costo operativo è l'altro grande fattore. Più database significa più backup, upgrade, monitoraggio e risposta agli incidenti. Potresti anche raggiungere più velocemente i limiti di connessione perché ogni tenant può richiedere il proprio pool di connessioni.

Errori comuni che causano fughe di dati o problemi futuri

La maggior parte dei problemi multi-tenant non sono fallimenti di grande disegno. Sono omissioni piccole che crescono in bug di sicurezza, reporting pasticciato e pulizie costose. La multi-tenancy funziona quando la separazione dei tenant è trattata come un'abitudine, non come una funzionalità aggiunta in seguito.

Un leak comune è dimenticare il campo tenant su una tabella, specialmente tabelle di join come user_roles, invoice_items o tag. Tutto sembra a posto finché una report o una ricerca non unisce attraverso quella tabella e tira righe di un altro tenant.

Un altro problema frequente sono i pannelli admin che bypassano i filtri tenant. Spesso inizia come “solo per il supporto” e poi viene riutilizzato. Gli strumenti no-code non cambiano il rischio: ogni query, Business Process ed endpoint che legge dati tenant ha bisogno dello stesso scoping.

Anche gli ID possono ingannare. Se condividi ID leggibili dall'uomo tra tenant (per esempio order_number = 1001) e assumi siano unici globalmente, gli strumenti di supporto e le integrazioni misceleranno i record. Mantieni identificatori a scope tenant separati dalle chiavi primarie interne e includi il contesto tenant nelle lookup.

Infine, i team sottovalutano migrazioni e backup man mano che scalano. Ciò che è facile con 10 tenant può diventare lento e rischioso con 1.000.

Controlli rapidi che prevengono la maggior parte dei dolori:

• Rendi esplicita la proprietà tenant in ogni tabella, incluse quelle di join.
• Usa un unico pattern di scoping tenant e riutilizzalo ovunque.
• Assicurati che report ed esportazioni non possano essere eseguiti senza scoping tenant (a meno che non siano davvero globali).
• Evita identificatori ambigui per tenant nelle API e negli strumenti di supporto.
• Esercita restore e migrazioni presto, non dopo la crescita.

Esempio: un agente di supporto cerca “fattura 1001” e ottiene il tenant sbagliato perché la lookup ha saltato lo scoping tenant. È un bug piccolo con grande impatto.

Una checklist veloce prima di impegnarti

Prima di fissare un modello multi-tenant, esegui alcuni test. L'obiettivo è catturare fughe di dati presto e confermare che la tua scelta funziona ancora quando le tabelle diventano grandi.

Controlli rapidi che puoi fare in un giorno

• Prova di isolamento dei dati: crea due tenant (A e B), aggiungi record simili, poi verifica che ogni lettura e aggiornamento sia limitato al tenant attivo. Non affidarti solo ai filtri UI.
• Test di rottura dei permessi: effettua il login come utente Tenant A e prova ad aprire, modificare o cancellare un record di Tenant B cambiando solo l'ID del record. Se qualcosa va a buon fine, trattalo come blocker della release.
• Sicurezza del percorso di scrittura: conferma che i nuovi record ottengono sempre il valore tenant corretto (o finiscano nello schema/database giusto), anche quando creati da job in background, importazioni o automazioni.
• Prova di reporting: conferma di poter fare reporting solo tenant e reporting “tutti i tenant” (per lo staff interno), con regole chiare su chi può vedere la vista globale.
• Controllo delle prestazioni: aggiungi una strategia di indici ora (soprattutto per (tenant_id, created_at) e altri filtri comuni) e misura almeno una query lenta di proposito così sai come si presenta il caso “cattivo”.

Per rendere concreto il test di reporting, scegli due domande di cui sai di aver bisogno (una a scope tenant, una globale) ed eseguile su dati di esempio.

-- Tenant-only: last 30 days, one tenant
SELECT count(*)
FROM tickets
WHERE tenant_id = :tenant_id
  AND created_at \u003e= now() - interval '30 days';

-- Global (admin): compare tenants
SELECT tenant_id, count(*)
FROM tickets
WHERE created_at \u003e= now() - interval '30 days'
GROUP BY tenant_id;

Se stai prototipando in AppMaster, inserisci questi controlli nei Business Process (read, write, delete) e crea due tenant nel Data Designer. Quando questi test passano con volumi realistici, puoi impegnarti con fiducia.

Scenario di esempio: dai primi clienti alla scalabilità

Una azienda di 20 persone lancia un portale clienti per i suoi clienti: fatture, ticket e una dashboard semplice. Si aspettano 10 tenant nel primo mese, con piano di crescita a 1.000 nell'anno successivo.

All'inizio, il modello più semplice è quasi sempre un database dove ogni tabella che memorizza dati cliente include tenant_id. È veloce da costruire, facile da reportare e evita setup duplicati.

Con 10 tenant, il rischio più grande non è la performance. È la permessistica. Un filtro mancante (per esempio, una query “lista fatture” che dimentica tenant_id) può divulgare dati. Il team dovrebbe imporre i controlli tenant in un punto coerente (logica business condivisa o pattern API riutilizzabili) e trattare lo scoping tenant come non negoziabile.

Quando si passa da 10 a 1.000 tenant, le esigenze cambiano. Il reporting diventa più pesante, il supporto chiede “esporta tutto per questo tenant” e alcuni tenant grandi iniziano a dominare il traffico rallentando tabelle condivise.

Un percorso di aggiornamento pratico spesso assomiglia a:

1. Mantieni la logica applicativa e le regole di permesso, ma sposta i tenant ad alto volume in schemi separati.
2. Per i tenant più grandi (o clienti con compliance stretta), spostali su database separati.
3. Mantieni un livello di reporting condiviso che legga da tutti i tenant e programma report pesanti fuori picco.

Scegli il modello più semplice che mantiene i dati separati in sicurezza oggi, poi pianifica una migrazione per il problema dei “pochi tenant enormi” invece di ottimizzare per questo dal giorno zero.

Prossimi passi: scegli un modello e prototipalo in un backend no-code

Scegli in base a cosa devi proteggere prima: isolamento dei dati, semplicità operativa o scalabilità a livello tenant. La fiducia arriva costruendo un piccolo prototipo e cercando di romperlo con casi reali di permessi e reporting.

Una guida di partenza semplice:

• Se la maggior parte dei tenant è piccola e ti serve reporting cross-tenant semplice, parti con un database e tenant_id su ogni riga.
• Se vuoi separazione più forte ma gestire un solo database, considera schemi separati per tenant.
• Se i tenant richiedono isolamento duro (compliance, backup dedicati, rischio noisy-neighbor), valuta database separati per tenant.

Prima di costruire, scrivi i confini dei tenant in linguaggio semplice. Definisci ruoli (owner, admin, agent, viewer), cosa può fare ciascuno e cosa significa "globale" (piani, template, log di audit). Decidi come deve funzionare il reporting: solo per tenant o “tutti i tenant” per lo staff interno.

Se usi AppMaster, puoi prototipare questi pattern rapidamente: modella le tabelle nel Data Designer (includendo tenant_id, vincoli unici e indici su cui si baseranno le query), poi applica le regole nel Business Process Editor così ogni lettura e scrittura resta scopingata. Se ti serve un punto di riferimento sulla piattaforma, AppMaster è disponibile su appmaster.io.

Un test pratico finale: crea due tenant (A e B), aggiungi utenti e ordini simili ed esegui gli stessi flussi per entrambi. Prova a esportare un report per il tenant A, poi passa intenzionalmente ID del tenant B negli stessi endpoint. Il prototipo è “sufficientemente sicuro” quando quei tentativi falliscono sempre e i report chiave restano veloci con volumi di dati realistici.