Vários clientes; um aplicativo hospedado. Você está descrevendo um banco de dados multilocatário.

Ao construir um banco de dados multilocatário, você precisa considerar

• consultando
• custo
• isolamento e proteção de dados
• manutenção e
• recuperação de desastres.

As soluções de vários locatários variam de um banco de dados por locatário (nada compartilhado) a uma linha por locatário (tudo compartilhado).

"Nada compartilhado", "banco de dados separado" ou um banco de dados por locatário

• Mais caro por cliente. (Um grande número de clientes implica um grande número de servidores.)
• Mais alto grau de isolamento de dados.
• A recuperação de desastres para um único locatário é simples e direta.
• A manutenção é teoricamente mais difícil, porque as mudanças precisam ser realizadas em cada banco de dados. Mas seus dbms podem suportar facilmente a execução de procedimentos armazenados em cada banco de dados. (O SQL Server tem um procedimento armazenado de sistema não documentado, sp_msforeachdb, por exemplo. Você provavelmente pode escrever o seu próprio.) "Nada compartilhado" também é o mais facilmente personalizável, mas também gera mais problemas de manutenção.
• Menor número de linhas por tabela. A velocidade de consulta está próxima do ideal.

"Tudo compartilhado" ou "esquema compartilhado" ou "um banco de dados por planeta"

• Menor custo por inquilino.
• Menor grau de isolamento de dados. Cada tabela tem uma coluna que identifica a qual inquilino uma linha pertence. Como as linhas de locatário são misturadas em todas as tabelas, é relativamente simples expor acidentalmente os dados de outro locatário.
• A recuperação de desastres para um único locatário é relativamente complicada; você precisa restaurar linhas individuais em muitas tabelas.
• A manutenção estrutural é mais simples, pois todos os inquilinos compartilham as mesas. No entanto, aumenta a carga de comunicação, porque você precisa se comunicar e coordenar cada alteração com cada locatário. Não é facilmente personalizável.
• O maior número de linhas por tabela. A consulta rápida é mais difícil, mas depende de quantos locatários e quantas linhas. Você pode facilmente entrar no território do VLDB.

Entre "nada compartilhado" e "tudo compartilhado" está "esquema compartilhado".

"Esquema compartilhado"

• Os locatários compartilham um banco de dados, mas cada locatário tem seu próprio esquema nomeado. O custo fica entre "nada compartilhado" e "tudo compartilhado"; grandes sistemas normalmente precisam de menos servidores do que "compartilhar nada", mais servidores do que "compartilhar tudo".
• Isolamento muito melhor do que "compartilhar tudo". Não tanto isolamento quanto "não compartilhou nada". (Você pode GRANT e REVOKE permissões em esquemas.)
• A recuperação de desastres para um único locatário requer a restauração de um dos muitos esquemas. Isso é relativamente fácil ou bastante difícil, dependendo de seus dbms.
• A manutenção é mais fácil do que "não compartilhar nada"; não é tão fácil como "compartilhar tudo". É relativamente simples escrever um procedimento armazenado que será executado em cada esquema em um banco de dados. É mais fácil compartilhar tabelas comuns entre locatários do que com "nada compartilhado".
• Geralmente, mais locatários ativos por servidor do que "nada compartilhado", o que significa que eles compartilham (degradam) mais recursos. Mas não tão ruim quanto "compartilhar tudo".

A Microsoft tem um bom artigo sobre arquitetura multilocatário com mais detalhes. (O link é para apenas uma página de um documento de várias páginas.)