One very interesting observation fell out in the #slony
development meeting... There are cases where users have attempted to migrate from Slony to built-in replication, and headed back, and it expresses a significant case where built-in replication has a big hole...
Built-in replication (and the mechanisms being built atop logical decoding http://www.postgresql.org/docs/9.4/static/logicaldecoding.html
have the same issue) has a problem where the database is very busy, having a LOT of WAL updates, but the data that needs to be replicated is a small subset.
In that case, you have a LOT of WAL files that need to be both processed and kept (needs to be kept long enough to ensure data has reached other replicas), and perhaps transported.
I know we had a case at work where we wanted to use WAL replication for a data warehouse system, and found that the nightly re-indexing of certain tables led to a lot more gigabytes of WAL files heading downstream than our network links would permit.
But to not digress further, if the database is otherwise-busy, there will be a LOT of WAL data, and if the updates that need to be replicated are minor in volume, WAL-based capture is turning out to be impractical. Cheaper to pay for some extra triggers and logging of data (as is done by Slony).