>The scenario where the cost seems regrettable is where someone is using
>a PostgreSQL in an ISP web hosting context, where it would certainly be
>nice to have 50 customers' data in separate databases.  Slony-I really
>isn't attuned to that scenario.
>
>But if the load on the system is low enough that you can afford to have
>50 databases hosted on one postmaster, then it seems improbable that
>load balancing is one of the goals.  I think, for that scenario, I'd
>point to PITR as being "the answer."  Slony-I isn't intended to be the
>answer to every problem.
>  
>
Hi the list,

After reading all you interesting answers, here are my conclusions :

Hosting 50+50 Slony clusters on *each* server is definitively not a 
viable solution.
So :
 - wether I group them into 50 schemas in one big database, and I use 
Slony to handle replication,
 - wether I keep my 50 databases distinct, and I use PITR.
In both cases, any failover will apply anyway to the 50 "entities" 
(databases or schemas).
So I abandon completely the idea of managing switchover/failover of each 
entity separately.

The question is now : which replication system will be the most adapted 
to this situation (Slony or PITR) ?
 - In the first case (50 schemas / 1 database / 1 Slony), I think I will 
loose some flexibility (administration, migration of one entity to other 
servers, etc...).
 - In the second case (50 databases and PITR), I think I will be able to 
handle switchover/failover in a similar manner than slony, but keeping 
flexibility, allowing for example to still use Slony to migrate one 
database to another server (correct me if I'm wrong) !

Moreover, Christopher is completely right on the fact that I don't need 
load-balancing at all. I only need switchover/failover.
So, it seems that PITR is really the right solution for my case.

I think that I will setup the following scenario, on each server 
(working by pairs) :
    - 50 live databases hosted on one running instance of PostgreSQL,
    - 50 other databases replicated via PITR (coming from the other 
server), and ready to be serviced if needed, by a distinct PostgreSQL 
instance (on a different TCP port).

So, in normal operation, 100 distinct databases should be splitted over 
a pair of servers (running 50 databases per server).
And in case of switchover/failover, one of them would be servicing the 
whole 100 databases.

Does it seem ok ?

Thank you very much !
Philippe Ferreira.