PostgreSQL 9.0 includes streaming replication, which, for a number of use cases, is likely to be simpler and more convenient than Slony-I.
There are, however, three characteristic kinds of cases where you'll need something like Slony-I, where the built-in WAL-based replication won't work:
- You need to interact between PostgreSQL versions. Slony (and
similar systems like Londiste and Bucardo) can cope with having
nodes running different versions of PostgreSQL.
WAL-based replication requires that all databases use identical versions of PostgreSQL, running on identical architectures.
- You only want to replicate parts of the changes that are going on.
WAL-based replication duplicates absolutely everything.
- You need for there to be extra behaviours taking place on
subscribers, for instance, populating cache management information.
WAL-based replication duplicates absolutely everything, and nothing extra that changes data can run on a WAL-based replica.
Steve Singer also discusses the matter in 9.0 Streaming Replication vs Slony .
As observed up front, the streaming replication built into PostgreSQL, which has progressed since its beginnings in version 8.1, can satisfy some users' replication requirements. For those with requirements that are not compatible with its strictures, replication systems like Slony-I will continue to be useful.
PostgreSQL 9.4 introduced Logical Replication, which uses logical decoding of WAL data as an alternative to trigger-based data capture. In the long run, this strategy seems likely to be more performant than Slony, and to eventually obsolesce Slony for many use cases not involving upgrades between PostgreSQL versions. However, Logical Replication/Logical Decoding will only support recent versions of PostgreSQL (and inter-PostgreSQL-version support may be aspirational moreso than actual), so if you have a database running on 9.3 or earlier, there is a likelihood that short-outage-upgrades will require something like Slony that runs against a diverse set of versions of PostgreSQL.