Quali sono i vantaggi dell'utilizzo dell'architettura multi-tenant con schemi di db separati per cliente?

"I think it would add a level of complexity to the app"

... contrario a cosa - usando solo uno schema per tutti gli inquilini?

Quindi in genere è vero il contrario. L'implementazione della multi-tenancy in uno schema aggiunge la complessità a ogni singola tabella in cui i dati potrebbero appartenere a diversi titolari, il che significa che questo tipo di complessità andrà anche nella tua app. Soprattutto quando ci sono molte tabelle, con schemi separati in realtà riduce la complessità della tua app. Rendi lo schema un parametro configurabile in fase di esecuzione, quindi puoi sviluppare la tua app quasi come se ci fosse un solo tenant.

Inoltre, rende le attività amministrative individuali come il backup / ripristino individuale per inquilino molto più facile. Puoi persino consentire a diversi tenant di avere versioni diverse dello schema in produzione contemporaneamente.

Avere uno schema per tutti i tenant è utile solo se una grande porzione dei dati nello schema è la stessa per tutti i tenant e che i dati non sono gestiti individualmente dai locatari.

Ovviamente, ciò che dovresti evitare in un approccio basato su più schemi sono le diverse personalizzazioni dello schema per i singoli titolari - questo infatti aggiungerebbe un tipo di complessità che vuoi evitare. Assicurati che le modifiche dello schema siano sempre implementate da script con versione (e non "al volo"), così puoi eseguire automaticamente quegli script su tutti gli schemi (ne hai bisogno, anche quando usi un singolo schema, dato che in genere hai almeno un database di sviluppo, un database di test e un database di produzione da gestire).

A seconda del DBMS, potresti anche considerare di utilizzare diverse istanze di database, che potrebbero offrire un'esperienza di ridimensionamento migliore. Per un sistema come Oracle, diversi schemi potrebbero essere l'opzione migliore a causa del sovraccarico amministrativo della gestione delle diverse istanze DB. Per un sistema come MySql, diverse istanze di database potrebbero essere un approccio valido, forse migliore (dipende dal tuo caso).

Un'architettura multi-tenant ha il vantaggio della scalabilità e della sicurezza. Quando si hanno tutti i dati del cliente in una tabella, tutti i clienti hanno accesso a tutti i dati dei clienti, non calcolando il codice che si scrive per limitare questo accesso. In un'architettura multi-tenant puoi configurare diversi utenti nel db e avere un design molto più semplice del processo di autenticazione.

Da un punto di vista della scalabilità non hai più bisogno di enormi indici da cercare per rallentare le tue query. I dati non hanno alcuna relazione, almeno da un cliente pov, perché appartengono a clienti diversi. Ha senso separare i dati per questo motivo.

Se imposti l'architettura anche in diverse istanze, puoi assegnare le risorse laddove necessario e un ulteriore livello di sicurezza.

L'utilizzo di diverse istanze può essere molto buono, oltre a complicare le cose a seconda delle funzionalità dell'applicazione.

Non sono d'accordo sul fatto che questa architettura aggiunga complessità all'applicazione. Se mai, dovrebbe semplificare.