Eu tenho o mesmo problema para resolver e também considerando variantes. Como tenho anos de experiência na criação de aplicativos SaaS multi-tenant, também selecionei a segunda opção com base em minha experiência anterior com bancos de dados relacionais.

Ao fazer minha pesquisa, encontrei este artigo no site de suporte do mongodb (adicionado desde que se foi):https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-cases/multi -tenant.html

Os caras afirmaram evitar as segundas opções a qualquer custo, o que, pelo que entendi, não é particularmente específico do mongodb. Minha impressão é que isso é aplicável para a maioria dos dbs NoSQL que pesquisei (CoachDB, Cassandra, CouchBase Server, etc.) devido às especificidades do design do banco de dados.

Coleções (ou buckets ou como eles chamam em diferentes bancos de dados) não são a mesma coisa que esquemas de segurança no RDBMS, apesar de se comportarem como contêineres para documentos, eles são inúteis para aplicar uma boa separação de locatários. Não encontrei banco de dados NoSQL que possa aplicar restrições de segurança com base em coleções.

Claro que você pode usar a segurança baseada na função do mongodb para restringir o acesso no nível do banco de dados/servidor. (http://docs.mongodb.org/manual/core/authorization/)

Eu recomendaria a 1ª opção quando:

• Você tem tempo e recursos suficientes para lidar com a complexidade do projeto, implementação e teste deste cenário.
• Se você não tiver muitas diferenças de estrutura e funcionalidade no banco de dados para diferentes locatários.
• O design do seu aplicativo permitirá que os locatários façam apenas personalizações mínimas em tempo de execução.
• Se você deseja otimizar o espaço e minimizar o uso de recursos de hardware.
• Se você vai ter milhares de inquilinos.
• Se você deseja expandir rapidamente e com bom custo.
• Se você NÃO for fazer backup de dados com base em locatários (mantenha backups separados para cada locatário). É possível fazer isso mesmo neste cenário, mas o esforço será enorme.

Eu iria para a variante 3 se:

• Você terá uma pequena lista de inquilinos (várias centenas).
• As especificidades do negócio exigem que você seja capaz de suportar grandes diferenças na estrutura do banco de dados para diferentes locatários (por exemplo, integração com sistemas de terceiros, importação e exportação de dados).
• O design do seu aplicativo permitirá que os clientes (inquilinos) façam alterações significativas no tempo de execução do aplicativo (adicionando módulos, personalizando os campos etc.).
• Se você tiver recursos suficientes para expandir rapidamente com novos nós de hardware.
• Se você precisar manter versões/backups de dados por locatário. Além disso, a restauração será fácil.
• Existem restrições legais/regulamentares que obrigam você a manter locatários diferentes em bancos de dados diferentes (até mesmo data centers).
• Se você deseja utilizar totalmente os recursos de segurança prontos para uso do mongodb, como funções.
• Há grandes diferenças de tamanho entre os inquilinos (você tem muitos inquilinos pequenos e poucos inquilinos muito grandes).

Se você postar detalhes adicionais sobre sua inscrição, talvez eu possa lhe dar conselhos mais detalhados.