One of the key features any Enterprise considers when choosing a database technology for their architecture solution stack is that of replication. Oracle and MySQL both have built in replication solutions, but as of yet PostgreSQL doesn't support a built in replication solution. There are many replication solutions available however, and different companies are using different solutions customized for their needs.
Among all of the solutions, Slony is probably the most widely tested and deployed within organizations, although it does have the following limitations:
* Replicated tables must have a unique or primary key
* It does not support replication of large objects
* Schema changes are not propagated (though they can be coordinated)
* It does not support synchronizing databases outside of replication
* There are limitations on version compatability; you can not replicate from PostgreSQL 8.2 to PostgreSQL 8.4 for example
* It is more difficult to set up than many other replication solutions
One new alternative to Slony is a project known as RubyRep, which is designed to avoid some of the limitations of Slony. RubyRep has full stack solution from comparing two databases to start replicating them.
In the talk, I will explore the RubyRep usage with examples for following actions: