Slony-I is a "master to multiple slaves" replication system for PostgreSQL supporting cascading (e.g. - a node can feed another node which feeds another node...) and failover.

The big picture for the development of Slony-I is that it is a master-slave replication system that includes all features and capabilities needed to replicate large databases to a reasonably limited number of slave systems.

Slony-I is a system designed for use at data centers and backup sites, where the normal mode of operation is that all nodes are available.

A fairly extensive "admin guide" comprising material in the Git tree may be found here. There is also a local copy.

The original design document is available here; see also initial description of implementation..

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.

2.0.5 fixes more than 24 issues found from 2.0.4 and earlier versions, remedying many issues found during an extensive testing period.

Slony-I source code has been migrated to use Git.

There are several addresses at which one may get at the repository via the various protocols that Git supports:

  • git://
  • ssh://

At present, we do not have a way to automatically send email out when changes are committed (as was the case with CVS). There is, however, an automatically generated RSS feed .

This release of the 2.0.x stream includes fixes to the issues introduced in 2.0.3. 2.0.3 installations are encourged to upgrade.

Slony-1 2.2.8 engine documentation
Slony-1 2.1.4 engine documentation
Slony-1 2.0.8 engine documentation
Slony-1 1.2.23 engine documentation
Steven Singer 2014-07-07
The next bug fix release in the 2.2.x series is now available. This release includes the following
  • Fixes for PG 12
  • Makefile changes (vpath support)
  • Win32 fixes to compile + removal of default HAVE_PGPORT from win32.mak
  • Documentation fixes
The next bug fix release in the 2.2.x series is now available. This release includes the following
  • Fixes for PG 11
  • Fix bug in with regex in 'set add sequence'
  • Add support to Slonik to specify the share direcotry using the environment environment variable SLONY_SHARE_DIR
  • Add slon config setting remote_listen_serializable_transactions to use read committed instead of read-only-serializable deferable
  • Add slon config setting enable_version_check to disable the slony version check that ensures all nodes run the same slony version
The next bug fix release in the 2.2.x series is now available. This release includes the following
  • slonik_build_env can now accept multiple -schema options on the command line
  • Support for PG10. This involved changes to PG version detection
  • Disallow createEvent and data changes in the same transaction.
  • Fix some failover issues when doing a multi-node failover with a cascade node
  • Bug 341 - suppress log trigger/deny when running in 'local' mode
  • Fix issue when receiving DDL from non origin nodes
This release includes the following bug fixes
  • Bug 359 dditional parameter to GetConfigOptionByName() in PG 9.6
  • Misc other fixes to compile against PG 9.6
  • PG 9.5 makefile fix for win32
  • Remove 'unsupported' warning for PG 9.5
The next bug fix release in the 2.2.x series is now available. 2016-06-02
This release includes the following bug fixes
  • Bug 349 - Issue with quoting of cluster name - only hit when processing DDL
  • Bug 350 - Make cleanup_interval config parameter work as expected
  • Bug 345 - 345 Fix bug when dropping multiple nodes at once
  • Bug 354 - Fix race condition in FAILOVER
  • Bug 356 - Perform TRUNCATE ONLY on replicas (when replicating a truncate)
The next bug fix release in the 2.2.x series is now available. 2015-01-18
This release includes the following bug fixes
  • Bug 338 - Have ddlScript return a bigint instead of a integer
  • fixing Deadlock with application during minor version slony upgrade
  • Bug 342 FAILOVER fixes for some multi-node configurations
  • Remove HAVE_POSIX_SIGNALS from config.h
  • Bug 344 Do not abort reading slon config values when an unrecognized one is encountered
The next bug fix release in the 2.2.x series is now available. 2014-07-07
Slony 2.0.8 has been released. The final 2.0.x release is now available. This release includes some minor bug fixes
  • Bug 230 - log_timestamps was always treated as true on some platforms(AIX)
  • Bug 233 - Fix segfault when subscribing to a set that does not exist.
  • Bug 236 :: Fix default formatting of timestamp in logs
  • Fix issue with FAILOVER when failing over an origin with 382 multiple sets.
  • Bug 315 :: Fixes to the compile time include directories
Slony 2.2.2 has been released. This bug fix release in the 2.2.x series includes
  • Bug 327 - Fix invalid free() in the logApply trigger
  • Include server include paths on --with-pgport builds for slonik
This bug fix release in the 2.2.x series includes
  • Fixes to the UPDATE FUNCTIONS for upgrades from releases earlier than 2.2.0
  • Fixes to the FAILOVER logic(bug 318)
  • Fixes slon to avoid constant database connection & disconnection (bug 321)
  • Fixes to CLONE PREPARE processing (bug 322)
Among other issues a full list can be found in the release notes
Slony 2.2.1 has been released. 2013-11-04
Slony 2.2.0 has been released. This release of Slony includes the following major changes from the 2.1.x series
  • Shared Libraries are now named so as to allow having multiple versions of Slony installed simultaneously on a database cluster
  • Let DDL for EXECUTE SCRIPT to be specified inline
  • Added a RESUBSCRIBE NODE command to reshape clusters.
  • The FAILOVER process has been reworked to be more reliable.
  • Major "protocol" change; rather than constructing cursors to query logged updates, version 2.2 now uses the COPY protocol to stream data into log tables on subscribers.
A full list of changes can be found in the release notes