Postgre/hibernate: une base avec 2 schemas ou 2 bases avec 1 schema ?

Bonjour,

J'ai une appli web java/hibernate qui attaque une base de données postgre 
8.3 contenant env 10millions de lignes par an (150Mo/dump).
Je vais devoir faire une autre base possédant exactement la meme structure 
mais contenant d'autres données (volumétrie identique) et attaquer l'une ou 
l'autre de ces bases selon le login de l'utilisateur.

Seule contrainte: la gestion de tous les utilisateurs doit se faire dans une 
seule base.

Je vois 2 possibilités:

1) deux bases de données

Je configure 2 datasources différents pour tomcat.
J'initialise 2 sessionFactories hibernate en changeant juste le 
hibernate.connection.datasource
 et je choisis le bon en fonction du login à chaque requete http.
avantages: impossible de se tromper de schema lorsque l'on lance une 
requete, dump/restore d'une seule base à la fois, rien à faire si un jour il 
fallait séparer les 2 bases (une simple recopie des utilisateurs)
inconvenient: 2 bases à gérer, obligation de faire une verrue pour la 
gestion des utilisateurs car le 2e datasource verra une table d'utilisateurs 
vide.

2) une base de données avec 2 schemas

Je configure un seul datasource pour tomcat.
J'initialise 2 sessionFactories hibernate en changeant juste le 
hibernate.default_schema et je choisis le bon en fonction du login à chaque 
requete http.
avantage: un seul pool de connexion, une seule base à gérer 
(dump/restore,...), il me suffit de forcer le schema public sur la table des 
utilisateurs pour que leur gestion soit transparente depuis l'appli
inconvénient: perf des dump/restore vu que je suis obligé de travailler sur 
les 2 bases en meme temps.


D'après vous, quelle est la meilleure solution tant d'un point de vue SGBD 
que java ?

Suivi positionné sur fcas.