Based on logical decoding, introduced in PostgreSQL 9.4, EDB Replication Server uses the Write-Ahead Logs (WAL) to extract relevant changes for replication. This replaces the use of triggers, which created overhead on the publication databases, and reduces latency significantly.

Even though application and architecture design aim to avoid data update conflicts, not every conflict can be avoided. This is why EDB Replication Server also offers proper conflict resolution methods to ultimately prevent data inconsistencies.

EDB Replication Server Architecture Overview

EDB Replication Server Architecture Overview

EDB Replication Server is based on publications and subscriptions. Masters provide publications; replicas subscribe to publications. The configuration is held in EDB Replication Server’s control database.

Replication from EDB Postgres Advanced Server 9.4 or higher and PostgreSQL 9.4 or higher uses log-based replication, extracting any changes from the Write-Ahead Logs (WAL) of the master and applying these changes to the replicas reducing the overhead on the master and reducing latency significantly. Trigger-based replication is also available.

Replication from a earlier versions of EDB Postgres Advanced Server and PostgreSQL, as well as replication from Oracle and SQL Server is trigger-based.

Why not to use Slony, BDR or pgLogical?

Why not to use Slony, BDR or pgLogical?

Slony has been a reliable trigger-based single master replication solution for years also offering cross-version replication. EnterpriseDB supports Slony, but Slony does not provide the faster log-based replication and does not offer multi-master replication, features that users of EDB Postgres Replication Server can benefit from in terms of performance and use case compatibility.

Bi-Directional Replication (BDR) is a PostgreSQL fork with multi­-master replication functionality. It is based on PostgreSQL’s logical decoding, as is EDB Postgres Replication Server. BDR has similar functionality, but does not offer the replication of a subset of data (no row­level filtering) and conflict detection is rudimentary. It does not offer single master replication and does not integrate with Oracle nor SQL Server.

pgLogical offers single master replication based on PostgreSQL’s logical decoding - the same method that is used by the EDB Postgres Replication Server. EDB Replication Server has much of the same functionality as pgLogical, but also offers single master replication in heterogeneous database environments and multi­-master replication from within the same graphical user interface (GUI). pgLogical does not offer a GUI and requires more effort to configure and manage than EDB Postgres Replication Server.