Logical vs Physical Replication: When to Use Each

About Remac: Remac is a high-performance, database-agnostic transaction log processor. It turns native database transaction logs into governed data streams, replicas, audit records, recovery data, and replayable events.

Remac supports logical and physical processing modes, which makes the boundary between them important.

PostgreSQL supports physical and logical replication. Physical replication sends native WAL to a compatible standby. Logical replication sends selected row changes to a subscriber through PostgreSQL's logical replication system.

Both modes read the same Write-Ahead Log, but they consume it differently and serve different purposes. Physical replication is for high availability and disaster recovery. Logical replication is for selective table syncing, cross-version upgrades, and Change Data Capture.

Choosing between them depends on what you need. Many production setups run both.

---

Physical Replication

Physical replication streams native WAL from a primary server to one or more compatible standby servers. Each standby replays that WAL through PostgreSQL's recovery system and maintains the same physical database state, subject to PostgreSQL's documented exclusions and compatibility rules.

How It Works

The primary writes WAL as part of normal operation. A WAL sender process streams those bytes over a replication connection to the standby's WAL receiver process. The standby writes the incoming bytes to its own pg_wal directory and replays them continuously through PostgreSQL's recovery mechanism.

Asynchronous streaming is the default. The primary does not wait for the standby to confirm receipt, so a primary failure can leave the standby without the latest committed WAL.

With synchronous replication, the primary waits for the configured standby confirmation before it reports the commit. The exact loss and visibility boundary depends on synchronous_commit, the selected synchronous standbys, the confirmation level, and the failover procedure.

The standby is read-only. With hot_standby = on, clients can connect and run read queries, but all writes are prohibited. The PostgreSQL documentation is specific: INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, and even temporary tables are blocked. The transaction_read_only parameter is hardcoded to true during recovery.

What You Get

Physical standby. WAL replay maintains the cluster's physical database state. Temporary and unlogged data are not protected in the same way, and configuration outside the database cluster requires separate management.

A failover target. If the primary becomes unavailable, an operator or failover system can promote a suitable standby. The possible data-loss boundary depends on the replication mode, commit settings, WAL received by the standby, and promotion procedure.

Point-in-time recovery. PITR is a WAL archiving capability, not a streaming replication feature. Both use physical WAL. A valid base backup and a complete WAL archive let you restore to a selected target within the retained recovery window.

Cluster-wide scope. Physical replication does not require a publication for each table. It requires physical replication configuration, a compatible base backup, and wal_level = replica or higher.

What You Don't Get

Per-table control. Physical replication is all-or-nothing. You cannot select specific tables or databases. The entire cluster is replicated because the WAL operates at the storage level, not the table level.

Cross-version compatibility. The PostgreSQL documentation states that log shipping between servers running different major release levels is not possible. The hardware architecture must also match. Even minor version differences, while likely to work, are not formally supported.

Cross-system logical delivery. Native physical WAL is tied to PostgreSQL's physical compatibility rules. A non-PostgreSQL destination cannot apply those bytes as logical row changes.

Writable standby. If you need a writable copy of the database, physical replication is the wrong tool.

---

Logical Replication

Logical replication decodes the WAL into structured data-change messages, primarily row-level INSERT, UPDATE, and DELETE changes, plus TRUNCATE operations. Instead of raw bytes, the subscriber receives operations such as "insert this row into the orders table" or "update column status to 'shipped' for row 1001."

How It Works

On the publisher, the WAL is decoded by the built-in pgoutput output plugin into a stream of structured messages. A logical replication slot tracks the subscriber's position and retains the WAL it still needs, subject to configured slot-retention and invalidation limits.

A publication defines which tables and which operations to include:

CREATE PUBLICATION orders_pub FOR TABLE orders, order_items;

On the subscriber, a subscription connects to the publisher and starts receiving changes:

CREATE SUBSCRIPTION orders_sub
    CONNECTION 'host=primary dbname=mydb'
    PUBLICATION orders_pub;

With the default copy_data = true, a new subscription performs an initial table synchronization. Dedicated table synchronization workers copy existing data. Each worker then catches up with changes that occurred during its copy before normal replication takes over.

Logical replication requires wal_level = logical on the publisher. For details on WAL levels and replication slots, see PostgreSQL WAL: How It Works.

What You Get

Per-table control. Publish only the tables you need and subscribe to the resulting publications. Filter by operation type (INSERTs only, no DELETEs, and so on).

Cross-version compatibility. Logical replication works between different major PostgreSQL versions. This is one of its primary use cases: performing major version upgrades with minimal downtime by replicating to a subscriber running the new version, then switching over.

External logical processing. Logical decoding exposes structured change messages that an external processor can convert for non-PostgreSQL sinks. This is separate from PostgreSQL's built-in publication and subscription apply path.

Multiple subscribers. The same publication can serve multiple subscribers, each consuming independently via its own replication slot.

Writable subscriber. Unlike a physical standby, a logical replication subscriber is a normal PostgreSQL database that accepts writes.

What You Don't Get

DDL replication. Schema changes are not replicated. If you add a column on the publisher, you must add it manually on the subscriber. The PostgreSQL documentation recommends applying additive schema changes to the subscriber first to avoid errors when new columns appear in replicated data.

Sequence synchronization. Sequence state is not replicated. The row data generated by sequences is replicated (the actual column values), but the sequence object itself still shows its start value on the subscriber. If you plan to promote the subscriber to a primary, you need to update sequences manually.

Full cluster copy. Logical replication operates at the table level. System catalogs, roles, permissions, extensions, and server configuration are not replicated.

PITR. WAL archiving (which enables point-in-time recovery) operates on the physical WAL and pairs naturally with physical replication. Logical replication does not participate in this mechanism. Archiving decoded change events and replaying them is possible through external tooling, but it is not a built-in PostgreSQL feature.

Large object replication. Large objects (those stored via PostgreSQL's large object API) are not replicated.

---

Comparison

---

Using Both Together

Many production deployments run both modes because they solve different problems.

A common setup uses physical replication for a high-availability standby and logical replication to send selected changes to Kafka, a search index, or a data warehouse.

This works because both modes read the same WAL. Setting wal_level = logical (required for logical replication) includes everything that physical replication needs. The logical level is a superset of replica. A single primary can serve physical standbys and logical subscribers simultaneously.

The cost includes logical decoding work, replication connections, retained WAL, network traffic, and any added WAL caused by the selected settings. Measure these costs with the real workload and retention policy.

---

Where to Go from Here

Use physical replication when the required result is a compatible PostgreSQL cluster for standby or recovery work. Use logical replication when the result needs selected tables, cross-version movement, or decoded changes. Run both when those requirements coexist.

PostgreSQL WAL: How It Works explains the shared WAL mechanics. What is Change Data Capture explains how log-based CDC builds on logical decoding.

For the broader picture of how replication fits into transaction log processing, see What is Transaction Log Processing.

Join the Remac waitlist for product updates.

External reference note: The external technical information and linked references in this article were current when we published it. External systems, documentation, and defaults can change after publication.

---

Further Reading:

• High Availability, Load Balancing, and Replication. Official PostgreSQL documentation covering physical replication, streaming replication, and failover strategies.
• Log-Shipping Standby Servers. Official documentation on physical standby configuration, version requirements, and synchronous replication.
• Hot Standby. Official documentation on read-only query support for physical standbys.
• Logical Replication. Official documentation on logical replication concepts, publications, and subscriptions.
• Logical Replication Restrictions. Official list of current limitations including DDL, sequences, and large objects.
• Continuous Archiving and Point-in-Time Recovery. Official documentation on WAL archiving and PITR.