Hi, Marcin,

We switched this December from using dbmirror to Slony-1 to mirror our 
main application database, which is moderate in size -- maybe 16gb on 
disk -- but sees plenty of activity.  We use a custom built 
load-balancing library to distribute SELECTs over our cluster, which 
consists of a master and single (for now) slave.

Our proximate reason for moving off of dbmirror -- setting aside the 
project's quiescent state -- was the rate of growth of the log tables.  
  Because they were so active (we were seeing maybe 200 
transactions/minute, in addition to the dbmirror UPDATE/DELETE volume), 
the tables were ballooning in size, and the SELECT from "Pending" was 
taking, at our lowest moment, well over 10 seconds.  We solved this 
problem by introducing another problem, perhaps even a scarier one: 
every 30 minutes, dbmirror would pause, drop and rebuild it's logging 
tables, and then resume.  This is clearly a *grotesque* hack, 
unsuitable for a production system, and we resolved to get out from 
under it as soon as humanly possible.

Thus, with the invaluable assistance of Josh Berkus, and the Slony-1 
list, we switched over to Slony.  Now, Slony overhead is about 5-10%, 
and more to the point, has stayed stable despite a significant increase 
in usage.  Performance-wise, we could not possibly be happier.  
Administratively, as well, Slony has a more active community, and just 
feels less ad-hoc than dbmirror.  I'm not denigrating the dbmirror, 
mind; it got us past the "one big box" stage in our database 
architecture, which was huge.  It just wasn't suited to the volume of 
data that we're pouring through the system, currently.

Best,
jfb
-- 
James Felix Black
Programmer, iParadigms LLC
(510) 287-9720 x 250