Este é um tema que me interessa e muito (vou ver se escrevo algo no meu blog a respeito).

O que tem de ser levado em consideração no caso de uma arquitetura multi tenant é, antes de mais nada, o custo. Na essência há duas alternativas:

* Um banco de dados por cliente: a principal vantagem é que fica muito mais fácil você isolar os dados de cada tenant, pois já estão físicamente separados.

A dificuldade neste caso é o fato de ser muito mais caro, pois para inquilino você terá o mesmo overhead. Além disto, a manutenção das tabelas/estruturas é cara, pois você precisará replicá-la em cada uma das instâncias de banco de dados.

Além disto, gerenciar os datasources pode se tornar algo bastante complexo.

* O mesmo banco de dados para múltiplos tenants: a vantagem é o custo reduzido que você tem no overhead, que passa a ser compartilhado pelo seu número de inquilinos.

Fica mais difícil você garantir o isolamento dos dados do usuário: seu código precisa ser mais esperto, mas a estratégia fundamental consiste em, basicamente, incluir uma coluna que identifique o seu inquilino e que será usada em toda consulta. O Hibernate mesmo já da suporte a isto para você.

Uma dúvida que poderia entrar aqui é: "minhas tabelas não ficariam gigantescas?". Sim, ficam bem maiores, mas você pode particioná-las, por exemplo, ou mesmo elaborar estratégias de gestão de dados que possam lhe ajudar a mitigar esta dificuldade.

Outro ponto que deve ser levado em consideração:

* Haverá customização de campos, isto é, o inquilino poderá definir novos campos na aplicação?

Se a resposta for sim, minha sugestão é adotar uma estratégia de persistência mista: algo como relacional/documental. Documental para onde os atributos variem, relacional para o resto. Outra alternativa é usar o próprio Postgres que agora oferece um suporte a este tipo de documento de uma forma bem interessante também.

Apesar do overhead, a opção de um banco de dados para cada cliente, será mesmo a opção a ser utilizada.
Seria possível você falar um pouco mais sobre a complexidade de gerenciar os datasources?

Agradeço a atenção

Oi Agnaldo,

neste caso a dificuldade vai ser realmente o overhead a mais que você irá pagar e o custo de manutenção das suas tabelas. Já passei por alguns projetos que tomaram esta decisão e até agora não vi um caso em que valesse à pena ou mesmo que pudesse ser considerado multi-tenant.

Um equívoco muito comum é ter diversas instâncias da aplicação, cada uma apontando para um datasource distinto, o que espero não ser o seu caso. Os problemas de versionamento costumam ser fatais a médio prazo.

Mas para criar datasources em tempo de execução, o que talvez seja seu caso, conheço este plugin: http://grails.org/plugin/runtime-datasources

Talvez lhe ajude. Tirando isto, o Grails oferece suporte a múltiplos datasources também, o que você pode verificar na documentação oficial: http://grails.org/doc/latest . Se não me engano, nativamente eles são definidos apenas no momento de boot da aplicação, o que não cairia bem para o seu caso.

Bom Dia Kico,

Não estou utilizando várias instâncias da aplicação.
No meu caso quando o cliente logar no sistema, e aplicação deverá identificar a configuração e conexão do banco dele, ou seja tudo estará acontecendo em bancos distintos (bd1, bd2 etc) para cada cliente.

Obrigado pela atenção, estarei verificando o plugin e também a documentação.

Agnaldo,
sei que o Hibernate 4 dá suporte para multi tenancy, mas não cheguei a usar, uso apenas o plugin MultiTenant - SingleDB, mas ele funciona apenas para a abordagem de banco único.
Veja se este link pode te ajudar: hibernate multi tenant
Achei também um artigo com um exemplo de aplicação usando multi tenant em banco de dados separados.

Kico, só para completar sua resposta, existe uma terceira abordagem para implementação de multi tenant, a de schemas separados

Grande resposta Agnaldo, agregou bastante! :)