Che cos'è un'architettura di database multi-tenant?

L’architettura di database multi-tenant è un modello per archiviare molti clienti in un unico livello dati, isolati per riga, schema o database dedicato. Quei tre gradi di isolamento esauriscono tutto lo spazio decisionale – il resto di questo tema ne è solo la conseguenza: come girano le migrazioni, quanto costa un ripristino, dove vive il noisy neighbor (il vicino rumoroso) e fino a che punto ogni pattern scala.

Punti chiave

I tre pattern, in SQL

-- Pattern 1 · Schema condiviso ("pool"): un solo insieme di tabelle, il tenant su ogni riga
CREATE TABLE invoices (
  tenant_id uuid   NOT NULL,
  id        bigint GENERATED ALWAYS AS IDENTITY,
  total     numeric(10,2),
  PRIMARY KEY (tenant_id, id)      -- il tenant in testa: pronto per indici e sharding
);
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_rows ON invoices
  USING (tenant_id = current_setting('app.tenant')::uuid);

-- Pattern 2 · Schema per tenant ("bridge"): un solo database, un namespace ciascuno
CREATE SCHEMA tenant_acme;          -- le stesse tabelle, ripetute per ogni tenant

-- Pattern 3 · Database per tenant ("silo"): separazione fisica completa
CREATE DATABASE tenant_acme;        -- l'isolamento più forte; N copie di tutto

Su un backend gestito la stessa garanzia si esprime senza SQL: il controllo degli accessi vive sui dati stessi, quindi l’isolamento tiene su ogni percorso – API, dashboard o SDK:

// JavaScript / Node.js — Back4app JS SDK
// The same query for every tenant — ACLs scope results server-side
const query = new Parse.Query('Invoice');
const invoices = await query.find({ sessionToken: user.getSessionToken() });
// Only rows this tenant's role can read come back. No WHERE clause to forget.

// Flutter / Dart — Back4app Flutter SDK
// The same query for every tenant — ACLs scope results server-side
final query = QueryBuilder<ParseObject>(ParseObject('Invoice'));
final response = await query.query();
// The session's role decides which rows exist, before results leave the server
if (response.success) {
  print('${response.results?.length} invoices visible to this tenant');
}

// iOS / Swift — Back4app Swift SDK
// The same query for every tenant — ACLs scope results server-side
let query = Invoice.query()
query.find { result in
  if case .success(let invoices) = result {
    print("\(invoices.count) invoices visible to this tenant")
  }
}

// Android / Kotlin — Back4app Android SDK
// The same query for every tenant — ACLs scope results server-side
val query = ParseQuery.getQuery<ParseObject>("Invoice")
query.findInBackground { invoices, e ->
  if (e == null) {
    Log.d("Billing", "${invoices.size} invoices visible to this tenant")
  }
}

Schema condiviso vs. schema per tenant vs. database per tenant

Le insidie nei dettagli

• L’indicizzazione parte dal tenant. tenant_id va in ogni tabella – anche dove i join lo fanno sembrare ridondante – e apre ogni indice composito: (tenant_id, created_at), non il contrario. Ogni query reale è limitata a un tenant; gli indici dovrebbero esserlo altrettanto.
• Le migrazioni si moltiplicano con l’isolamento. La flessibilità del silo si paga con un livello di orchestrazione: tracciamento delle versioni per tenant, logica di ritentativo, rilevamento della deriva. I team sottovalutano questa riga più di ogni altra della tabella.
• La sicurezza a livello di riga ha le sue clausole in piccolo operative. Le policy si appoggiano a impostazioni per connessione, che interagiscono con le modalità di pooling delle connessioni – il tenant va impostato per transazione, e il pooler va testato. Va anche verificato quali ruoli aggirano RLS; i percorsi da superutente sono il buco classico.
• L’aritmetica delle connessioni. Un pool per ogni database di tenant esaurisce in fretta le connessioni; i progetti a schema condiviso condividono un solo pool – un altro vantaggio silenzioso del pattern pool, che emerge solo su larga scala.
• L’asimmetria del ripristino spinge alla ripartizione in tier. “È possibile ripristinare soltanto i nostri dati a ieri?” è una domanda da contratto enterprise; se la risposta deve essere sì, quel tenant appartiene a un silo – il che porta direttamente all’ibrido.

Scalabilità e stato finale ibrido

La via di crescita del pattern pool è lo sharding per tenant: più database a schema condiviso, ciascuno con una fetta di tenant, e un catalogo che associa tenant → shard (il progetto open source Citus lo ha integrato in PostgreSQL, compreso lo spostamento di un tenant molto attivo su un nodo proprio). Combinato con la ripartizione in tier, questo produce l’architettura verso cui converge la maggior parte dei SaaS maturi: il tier gratuito nel pool, i tenant di taglia media nel pool su più shard, e i pochi tenant regolamentati o enormi in silo – con tenant_id conservato in ogni schema, dappertutto, così che qualunque tenant possa cambiare tier senza una riprogettazione. La mobilità dei tenant è la proprietà da progettare dal primo giorno; è quasi impossibile aggiungerla in un secondo momento.

Casi d’uso tipici

• SaaS B2B. Il caso fondativo: ogni workspace, organizzazione o team del prodotto è un tenant in uno di questi pattern.
• Prodotti freemium su larga scala. Migliaia di piccoli tenant gratuiti nel pool a un costo marginale vicino a zero – l’economia che rende possibili i piani gratuiti.
• Settori regolamentati. Clienti della sanità, della finanza e del legale che esigono per contratto dei silo – serviti dalla stessa codebase grazie all’ibrido.
• Agenzie e piattaforme. Una sola applicazione al servizio di molte organizzazioni clienti, ciascuna con il proprio confine.
• Piattaforme interne multi-team. I reparti come tenant su strumenti condivisi – stessi pattern, modello di minaccia più clemente.

Quale pattern conviene scegliere? Matrice decisionale

E la meta-risposta: conviene scegliere per tier, non per azienda – i progetti ibridi mettono ogni tenant nel pattern più economico che soddisfa i suoi requisiti, e lo spostano quando i requisiti cambiano.

Limiti e trade-off

• Schema condiviso: il bisogno più forte di un isolamento applicato dal database – un filtro mancato è una violazione, ed è per questo che RLS o le ACL del livello dati non sono negoziabili, non un irrobustimento opzionale.
• Schema per tenant: la scomoda via di mezzo – orchestrazione delle migrazioni come nel silo, isolamento più debole che nel silo, e limiti ai metadati del database che arrivano sorprendentemente presto.
• Database per tenant: tutto × N – migrazioni, backup, monitoring, connessioni, costi – e l’analisi fra tenant che diventa un progetto di data engineering.
• Tutti e tre: il contesto di tenant invade tutto (query, cache, job, log), e passare da un pattern all’altro costa caro senza disciplina sugli identificatori dal primo giorno: identificatori globalmente univoci e colonne tenant_id dappertutto, anche nei silo.

I dati multi-tenant su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. La sua risposta alla regola di ferro di questo articolo – far rispettare l’isolamento nel database – sono le ACL per oggetto, i ruoli per tenant e i permessi di classe, verificati dalla piattaforma a ogni richiesta e da ogni superficie, come mostrano le schede di codice qui sopra. È il pattern a schema condiviso, liberato dal rischio della clausola WHERE; l’approfondimento di ingegneria sulla sicurezza a livello di riga percorre l’intero pattern su un database documentale, e la vista a livello di hosting dello stesso tema copre il livello di infrastruttura che gli sta sopra.