Set replica identity before publishing PostgreSQL updates and deletes

Check row-identification readiness before accepting a publication that must carry updates and deletes.

Source facts

PostgreSQL 17 publications need a table replica identity to replicate UPDATE and DELETE operations. A primary key normally supplies it; a qualifying unique index or REPLICA IDENTITY FULL can be used in other cases. Without a suitable identity, those operations can fail on the publisher even though inserts still work. FULL uses the whole row and can cause inefficient subscriber searches when no suitable index is available. Publication membership alone does not establish update readiness.

Source: PostgreSQL 17 — Publication.

Applicability

This applies to PostgreSQL 17 publication design for logical replication. It addresses row identification, rather than the separate schema synchronization or sequence handover requirements.

DSE recommendation

DSE recommends reviewing every published table against its actual application operations before enabling the publication. Record the selected identity and the matching subscriber arrangement. Avoid making FULL the automatic answer for every keyless table; ask the database designer whether an appropriate key is possible and how subscriber lookup cost will be evaluated. Include update and delete behavior in the deployment acceptance plan, even when the initial data copy and insert-only demonstration have already succeeded.

Verification

In a test subscription, exercise inserts, updates, and deletes for each intended identity pattern. Inspect publisher errors and subscriber results, and compare representative lookup behavior where FULL is proposed. Retain the reviewed table list and identify any tables intentionally published only for supported operations.

Official reference

PostgreSQL 17 — Publication. Reviewed October 15, 2026.