PostgreSQL 16 separates replication placement, workers and privileges

PostgreSQL 16, released on September 14, gives database teams more choices about where replication work runs and who can administer it. Its standby publishing, parallel apply and delegated subscription features work at different layers of the same pipeline.

PostgreSQL Slonik logo by Daniel Lundin, © PostgreSQL Global Development Group. Official vector source; BSD licence and full notice. Proportionally rasterized and padded; the mark is unchanged. PostgreSQL and Slonik are trademarks of the PostgreSQL Community Association of Canada. Sulat isn’t affiliated with or endorsed by the project.

The release announcement presents standby logical replication as a way to move downstream replication work away from a busier primary. The operational details show why that change still requires coordination with the primary, and why faster apply doesn’t remove permission checks.

A standby publisher still depends on the primary

Logical decoding converts the write-ahead log into changes that another system can consume. PostgreSQL 16 allows a logical replication slot on a hot standby, making the standby a source for downstream consumers.

The 16.0 documentation recommends enabling hot_standby_feedback so the primary retains system-catalog rows needed for decoding. It also strongly recommends a physical replication slot between primary and standby. Without one, feedback protects those rows only while the connection remains alive.

If required catalog rows disappear, the logical slot can be invalidated. Reducing the primary’s wal_level below logical also invalidates existing logical slots on the standby once it detects the change. Offloading decoding therefore changes where work runs while retaining dependencies on the upstream server’s configuration and cleanup. Replication slots retain required log and catalog resources even without an active consumer, so this design still needs storage monitoring.

Even slot creation can depend on primary activity. An idle primary may delay the transaction information a standby needs; the new pg_log_standby_snapshot() function can prompt that information on the primary.

Parallel apply needs an explicit choice

On the receiving side, large transactions can use parallel apply workers. The subscription reference makes the boundary clear: streaming defaults to off. Setting it to parallel lets incoming changes go directly to an available parallel apply worker.

If no worker is free, PostgreSQL writes the changes to temporary files and applies them after the transaction commits. Simply upgrading doesn’t switch every subscription into parallel operation, and selecting the option doesn’t guarantee a worker will always be available.

Delegating creation doesn’t delegate every table

The new pg_create_subscription role lets administrators grant subscription-creation capability without making the recipient a superuser. The user also needs CREATE permission on the database.

Applying changes has a separate boundary. By default, replication performs table operations as the relevant table owner, so the subscription owner must be able to SET ROLE to those owners. This connects a replication deployment to the database’s ownership structure, rather than treating permission to create the subscription as sufficient for every target.

The security documentation describes an alternative, run_as_owner=true, but warns that table owners could then execute code with the subscription owner’s privileges, including through triggers. That option changes the trust relationship as well as the permission requirements.

Together, these features let teams distribute replication load and delegate its setup more precisely. The launch’s practical advance comes from those separate controls: source placement, worker availability and table-level authority each remain visible decisions.