Você desejará ter usado bancos de dados separados:

• Se você quiser conceder permissões aos próprios bancos de dados para clientes ou superusuários.
• Se você quiser restaurar apenas o banco de dados de um cliente sem afetar os dados dos outros.
• Se houver preocupações regulatórias que regem seus dados e violações de dados, e você descobrir tardiamente que esses regulamentos só podem ser atendidos com bancos de dados separados. (Atualização:pouco mais de 4 anos após a redação desta resposta, o GDPR entrou em vigor)
• Se você quiser mover facilmente os dados de seus clientes para vários servidores de banco de dados ou expandir ou mover clientes maiores/mais importantes para um hardware diferente. Em uma parte diferente do mundo.
• Se você quiser arquivar e desativar facilmente dados antigos de clientes.
• Se seus clientes se preocupam com o isolamento dos dados deles e descobrem que você fez o contrário.
• Se seus dados forem intimados e for difícil extrair apenas os dados de um cliente, ou se a intimação for muito ampla e você precisar produzir todo o banco de dados em vez de apenas os dados de um cliente.
• Quando você esquece de manter a vigilância e apenas uma consulta passa sem incluir AND CustomerID = @CustomerID . Dica:use uma ferramenta de permissões com script, ou esquemas, ou envolva todas as tabelas com visualizações que incluem WHERE CustomerID = SomeUserReturningFunction() , ou alguma combinação destes.
• Quando você obtém permissões erradas no nível do aplicativo e os dados do cliente são expostos ao cliente errado.
• Quando você deseja ter diferentes níveis de proteção de backup e recuperação para diferentes clientes.
• Quando você percebe que construir uma infraestrutura para criar, provisionar, configurar, implantar e, de outra forma, ativar/desativar novos bancos de dados, vale a pena o investimento, pois isso força você a se tornar bom nisso.
• Quando você não permite a possibilidade de alguma classe de pessoas precisar acessar os dados de vários clientes e precisa de uma camada de abstração em cima de Customer porque WHERE CustomerID = @CustomerID não vai cortá-lo agora.
• Quando os hackers atacam seus sites ou sistemas e você facilita a obtenção de todos os dados de todos os seus clientes de uma só vez, depois de obter credenciais de administrador em apenas um banco de dados.
• Quando o backup do banco de dados leva 5 horas para ser executado e depois falha.
• Quando você precisa obter a edição Enterprise do seu DBMS para poder fazer backups compactados para que a cópia do arquivo de backup pela rede demore menos de 5 horas mais .
• Quando você precisa restaurar todo o banco de dados todos os dias para um servidor de teste que leva 5 horas e executar scripts de validação que levam 2 horas para serem concluídos.
• Quando apenas alguns de seus clientes precisam de replicação e você precisa aplicá-la a todos os seus clientes, e não apenas a esses poucos.
• Quando você quer enfrentar um cliente do governo e descobrir que eles exigem que você use um servidor e banco de dados separados, mas seu ecossistema foi construído em torno de um único servidor e banco de dados e é muito difícil ou levará muito tempo para mudar .

Você ficará feliz por ter usado bancos de dados separados:

• Quando um lançamento piloto para um cliente explode completamente e os outros 999 clientes não são afetados. E você pode restaurar a partir do backup para corrigir o problema.
• Quando um de seus backups de banco de dados falha e você pode corrigir apenas esse backup em 25 minutos, em vez de iniciar todo o processo de 10 horas novamente.

Você desejará ter usado um único banco de dados:

• Quando você descobre um bug que afeta todos os 1.000 clientes e é difícil implantar a correção em 1.000 bancos de dados.
• Quando você obtém permissões erradas no nível do banco de dados e os dados do cliente são expostos ao cliente errado.
• Quando você não permitiu a possibilidade de alguma classe de pessoas precisar de acesso a um subconjunto de todos os bancos de dados (talvez dois clientes se fundam).
• Quando você não pensou em como seria difícil mesclar dois bancos de dados de dados diferentes.
• Quando você mescla dois bancos de dados de dados diferentes e percebe que um era o errado e não planejava se recuperar desse cenário.
• Quando você tenta ultrapassar 32.767 clientes/bancos de dados em um único servidor e descobre que esse é o máximo no SQL Server 2012.
• Quando você percebe que gerenciar mais de 1.000 bancos de dados é um pesadelo maior do que você jamais imaginou.
• Quando você percebe que não pode integrar um novo cliente apenas adicionando alguns dados em uma tabela e precisa executar vários scripts assustadores e complicados para criar, preencher e definir permissões em um novo banco de dados.
• Quando você precisar executar 1.000 backups de banco de dados todos os dias, certifique-se de que todos sejam bem-sucedidos, copie-os pela rede, restaure-os em um banco de dados de teste e execute scripts de validação em cada um deles, relatando quaisquer falhas de forma que será garantido para ser visto, e que são fáceis e rapidamente acionáveis. E então 150 deles falham em vários lugares e precisam ser corrigidos um de cada vez.
• Quando você descobre que precisa configurar a replicação para 1.000 bancos de dados.

Só porque listei mais razões para uma não significa que seja melhor.

Alguns leitores podem obter valor de MSDN:Multi -Arquitetura de dados do locatário . Ou talvez Padrões de design de aplicativo de locação SaaS . Ou mesmo Desenvolvendo multilocatários Aplicativos para a nuvem, 3ª edição