PostgreSQL offers more than one way to replicate, and the choice is usually made early. Someone picks a method during the first architecture pass; it works, and nobody revisits it. The constraint shows up later. 
PostgreSQL replication is therefore better understood as a set of trade-offs than a single feature. This blog post explains the main options, where each fits, and the operational issues that matter once replication is running in production.
What replication is being asked to do
The right PostgreSQL replication method depends on what you need replication to achieve. Common requirements include:
- High availability and failover
Keeping a replica ready to take over if the primary server fails. - Read scaling
Using read replicas for reporting and analytical workloads instead of adding load to the primary. - Disaster recovery
Keeping a replica in another location so a site-level failure does not affect both copies. - Selective distribution
Replicating specific data to warehouses, regional systems, or other subscribers. - Major-version upgrades
Keeping old and new PostgreSQL versions in sync ahead of a shorter cutover.
These requirements pull in different directions, which is why PostgreSQL provides more than one replication mechanism.
How replication works in PostgreSQL
PostgreSQL replication copies changes from a primary server to one or more replica servers. PostgreSQL has two main replication methods: streaming replication and logical replication.
Both use the write-ahead log (WAL), PostgreSQL’s transaction log. PostgreSQL records changes in the WAL before writing them to the database itself. Replication uses those records to keep other servers up to date.
Streaming replication sends WAL records to a replica, which replays them to maintain a copy of the whole database cluster. Logical replication uses logical decoding to turn WAL records into individual data changes, such as inserts, updates, and deletes. This means you can replicate selected tables rather than the entire cluster.
Streaming (physical) replication
Streaming replication keeps one or more standby servers in sync with a primary server by continuously sending them write-ahead log (WAL) records. The standbys replay those records to maintain a physical copy of the PostgreSQL cluster.
A standby is typically created from a base backup using pg_basebackup. Once replication starts, the WAL receiver receives records from the primary and writes them for replay.
With hot_standby enabled, applications can run read-only queries while WAL replay continues. This makes streaming replication useful for read scaling, as well as high availability and failover.
Because streaming replication copies the whole cluster, there are some important limitations:
- You cannot select individual databases or tables to replicate.
- The primary and replica must run the same PostgreSQL major version.
- The replica server remains read-only until it is promoted.
- The replica cannot have different data or a different schema from the primary.
For estates running many replicas, cascading replication lets a standby send WAL to additional standbys, reducing the WAL sender load on the primary server.
Logical replication
Logical replication copies selected data changes from one PostgreSQL database to another. Unlike streaming replication, it uses logical decoding to turn WAL records into row-level changes, so you can choose what gets replicated instead of copying the whole cluster.
Publications, subscriptions, and replication identity
Publications and subscriptions control what is replicated and where it goes. CREATE PUBLICATION defines the tables and data the publisher will make available, while CREATE SUBSCRIPTION connects subscribers to that publication and applies the changes. Logical replication also requires wal_level to be set to logical.
For updates and deletes, PostgreSQL must be able to identify the affected row. A primary key provides the replication identity by default. Without one, you need to configure another replica identity or those operations can fail.
Publications can be limited to individual tables and, in current PostgreSQL versions, specific rows and columns. An existing physical standby can also be converted into a logical subscriber with pg_createsubscriber, avoiding the usual initial table-data copy. Recent pg_createsubscriber improvements have expanded how the tool can be used when setting up logical replication.
Selective and cross-version replication
Logical replication can replicate selected tables and data rather than the entire cluster. It can also replicate between different PostgreSQL major versions, making it useful for downstream systems and upgrading a replication cluster with a shorter cutover.
What logical replication does not carry
Logical replication does not replicate everything automatically. Key limitations include:
- Schema changes and DDL are not replicated, so changes such as ALTER TABLE must also be applied to subscribers.
- Sequence data is not replicated.
- Large objects are not replicated.
- Views, materialized views, and foreign tables cannot be replicated as ordinary published tables.
Check the restrictions for your PostgreSQL version before relying on logical replication for a particular workload.
Synchronous and asynchronous replication
Synchronous and asynchronous replication differ in when PostgreSQL confirms a transaction is committed. The choice affects both data consistency and performance.
- Asynchronous replication confirms the commit once the primary server has written it locally. This reduces latency, but creates a window where committed data could be lost if the primary fails before the replica receives it.
- Synchronous replication waits for confirmation from a standby before completing the commit. This reduces the risk of data loss, but adds network latency to each transaction.
PostgreSQL provides different levels of synchronous replication through synchronous_commit. Depending on the setting, a standby can confirm that WAL has been received, flushed to disk, or replayed and made visible to queries. synchronous_standby_names controls which and how many standbys must respond.
The right choice depends on your recovery point objective (RPO). If committed transactions cannot be lost, synchronous replication provides stronger protection, but standby placement matters: the further WAL has to travel, the more latency each commit can incur.
Replication slots, lag, and the operational failure modes
Replication needs ongoing monitoring. In particular, teams need to watch replication slots, replication lag, and conflicts that can stop changes reaching a replica.
Replication slots and retained WAL
A replication slot prevents the primary server from removing WAL segments until a replica has received them. This allows a disconnected replica to catch up when it returns.
The risk is an inactive or orphaned slot. If its replica never returns, PostgreSQL can continue retaining WAL until pg_wal fills the available disk space. This can happen with a forgotten subscriber, paused subscription, or physical replication slot left behind after a replica is removed.
Monitor slots through pg_replication_slots, remove those that are no longer needed, and use max_slot_wal_keep_size to limit retained WAL where appropriate.
Monitoring lag and slot health
Replication lag shows how far a replica is behind the primary server. Monitor it in both bytes and time: byte lag shows the volume of WAL still to process, while time lag shows how stale the replica's data is.
Alert on replication lag and retained WAL together. A slot with growing retained WAL and no active consumer needs attention, and routine monitoring of PostgreSQL activity can catch it before storage becomes a problem.
Conflicts on logical subscriptions
A conflict on a logical subscriber can stop replication until the problem is resolved. For example, a row created directly on the subscriber may conflict with an incoming replicated row. While replication is stalled, its slot can continue retaining WAL on the publisher.7
Failover also needs planning. Keeping logical subscriptions running through a failover requires failover-enabled logical slots to be synchronized to the standby before promotion.
Choosing a replication method
Choose the PostgreSQL replication method based on what you need it to do:
| If you need to… | Use | Why |
| Provide high availability and failover | Streaming replication | Maintains a complete replica that can be promoted if the primary server fails. |
| Create read replicas | Streaming replication | Allows read-only workloads to run on replicas instead of the primary. |
| Replicate selected tables or data | Logical replication | Lets you choose what is published and sent to subscribers. |
| Replicate across PostgreSQL major versions | Logical replication | Works with row-level changes rather than requiring an identical physical cluster. |
| Feed warehouses or downstream systems | Logical replication | Distributes selected data without copying the whole cluster. |
| Support disaster recovery at another site | Streaming replication | Maintains a full copy of the cluster that can be promoted after a site-level failure. |
Many enterprise environments use both: streaming replication for high availability, read scaling, and disaster recovery, and logical replication for selective distribution and cross-version requirements.
Replication across hybrid and multi-site environments
Distance matters when you replicate across sites. Synchronous replication across a wide-area link adds the network round trip to every commit, so many environments use a nearby synchronous standby and a more distant asynchronous replica.
Bandwidth matters too. WAL volume depends on write activity, and workloads with heavy index maintenance or frequent full-page writes can generate more WAL than the underlying data changes suggest. Measure peak WAL volume and replication lag before relying on a link.
Before placing a replica in another site or region, ask:
- What is this replica for: high availability, disaster recovery, read scaling, or another requirement?
- Does it need synchronous or asynchronous replication, and can the network latency support that choice?
- What is the peak WAL volume, and does the link have enough capacity and headroom?
- Could this replica be promoted, and has failover from this location been tested?
- Can the data legally reside here? Residency and sovereignty rules apply to replicas as well as the primary server.
- Who owns and monitors the replica, replication lag, and slot health if something goes wrong?
Running replication where downtime has a cost
Fujitsu Enterprise Postgres is 100% PostgreSQL compatible, so the PostgreSQL replication mechanisms covered here work in the same way. Existing PostgreSQL skills and knowledge carry across.
For teams running replication in environments where downtime has a high cost, Fujitsu Enterprise Postgres adds:
- 24/7 global enterprise support with SLAs
Get support when issues such as replication lag, stalled subscriptions, or WAL growth need rapid investigation. - Longer version support
Versions are supported for a minimum of seven years and up to ten years after general availability, compared with five years for community PostgreSQL. This gives teams more control over when they plan major-version upgrades. - Flexible deployment
Run PostgreSQL replication across on-premises, hybrid, multi-cloud, Kubernetes, and OpenShift environments to support different infrastructure and multi-site requirements.
Replication behavior is easier to judge against your own workload than against documentation alone. Try Fujitsu Enterprise Postgres with a replication topology that reflects your environment.
Frequently asked questions about PostgreSQL replication
What is the difference between physical and logical replication in PostgreSQL?
Physical replication copies WAL records to create a replica of the entire PostgreSQL cluster. Logical replication uses logical decoding to turn WAL records into row-level changes and can replicate selected tables. Physical replication suits high availability, failover, and read scaling, while logical replication suits selective and cross-version replication.
Does PostgreSQL replication provide automatic failover?
No. PostgreSQL supports replication and standby promotion, but it does not automatically detect a primary server failure and promote a replica. Automatic failover requires external cluster management, such as repmgr, to handle health checks, promotion, and client redirection.
Can you replicate between different PostgreSQL major versions?
Yes, logical replication can replicate data between different PostgreSQL major versions because it works with row-level changes rather than the physical database format. This makes it useful for cross-version replication. Physical replication requires the primary and replica to use the same major version.
What happens if a replication slot is left inactive?
An inactive replication slot can cause WAL to build up on the primary server. PostgreSQL retains the WAL segments the inactive consumer still needs, so pg_wal can eventually fill the available disk space. Remove slots that are no longer required, and consider limiting how much WAL a slot can retain.
How do you monitor PostgreSQL replication lag?
Monitor PostgreSQL replication lag in both bytes and time. Byte lag shows how much WAL the replica still needs to process, while time lag indicates how stale its data is. Monitor pg_replication_slots alongside replication lag, and alert on growing retained WAL or inactive consumers.
PostgreSQL Insider 
