max_parallel_apply_workers_per_subscription

Definition PG 18 manual

Maximum number of parallel apply workers per subscription. This parameter controls the amount of parallelism for streaming of in-progress transactions with subscription parameter streaming = parallel.

The parallel apply workers are taken from the pool defined by max_logical_replication_workers.

The default value is 2. This parameter can only be set in the postgresql.conf file or on the server command line.

How it works

Maximum number of parallel apply workers per subscription. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

A subscription leader can use up to this many parallel workers to apply suitable in-progress transactions. More workers do not parallelize every transaction and consume the global logical-replication and background-worker pools.

Monitor and change max_parallel_apply_workers_per_subscription together with max_logical_replication_workers, max_sync_workers_per_subscription, max_worker_processes. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Operational considerations

Changing it on the wrong primary, standby, sender, or subscriber role.

Watching only configured bytes/time instead of actual lag, slot position, and worker state.

Failing over to a node that lacks the old primary's capacity or prerequisites.

Using infinite waits or WAL retention to hide a failed consumer.

Workload guidance

OLAP: Read standbys and logical subscribers often see long queries or large transactions. Put explicit bounds on replay/apply and monitor lag, worker saturation, slot restart_lsn, and conflict cancellations.

OLTP: Size max_parallel_apply_workers_per_subscription from topology, failover roles, slot/subscription count, and reconnect headroom. Test worst-case primary latency, standby replay, and disk retention before production.

SMALL: Configure only replication capacity that is actually used. Even a small topology needs bounded timeouts and slot lifecycle; unlimited retention is not reliability.