Replication / Subscribers

max_logical_replication_workers

• What it does: Sets the maximum number of logical replication worker processes that can run simultaneously across all subscriptions on the subscriber server.
• Why it matters: This parameter controls the total capacity for logical replication on the subscriber side. Each logical replication slot and apply operation requires worker processes. Setting this too low can cause replication delays and backlog, especially when multiple subscriptions are active or during initial synchronization. Setting it too high may consume excessive system resources and affect overall database performance.
• Ideal value & Best Practice: Default 4 is often too low for production systems with multiple subscriptions. Set to at least the number of subscriptions plus 2-3 for overhead. For systems with heavy logical replication workloads, values between 8 and 16 are common. Monitor worker usage and adjust based on the number of active subscriptions and replication volume.

max_parallel_apply_workers_per_subscription

• What it does: Sets the maximum number of parallel apply workers that can be used for each individual subscription.
• Why it matters: This parameter enables parallel processing of changes within a single subscription, significantly improving replication performance for tables with high write volumes. Parallel apply workers can process different transactions concurrently, reducing replication lag and improving throughput. However, each additional worker consumes more CPU and memory resources.
• Ideal value & Best Practice: Default 2 is a good starting point. Increase to 4-8 for subscriptions with very high transaction volumes or large tables. Consider the number of CPU cores available and the characteristics of your workload. For mostly sequential workloads, lower values may be sufficient. Monitor CPU usage and replication latency when increasing this value.

max_sync_workers_per_subscription

• What it does: Sets the maximum number of table synchronization workers that can be used for initial data copy during subscription creation.
• Why it matters: This parameter controls the parallelism of the initial table synchronization phase when creating a new subscription. Higher values can significantly reduce the time required for initial data synchronization by copying multiple tables concurrently. However, this process is resource-intensive and can impact database performance during the synchronization phase.
• Ideal value & Best Practice: Default 2 is conservative. Increase to 4-8 for faster initial synchronization, especially when dealing with many tables. Consider reducing during peak production hours to minimize performance impact. For very large databases, monitor system resources carefully and adjust based on available memory and I/O capacity.

---

Try pghealth Free Today 🚀

Start your journey toward a healthier PostgreSQL with pghealth.
You can explore all features immediately with a free trial — no installation required.

👉 Start Free Trial