PGConf.dev 2026 The Road to Enterprise-Grade Logical Replication: Feedback and Roadmap Brainstorming
This page contains minutes of logical replication feedback session. Thanks Bryan Doyle to take notes, and Zhijie Hou to summarize it.
Goal and Agenda
- Gather feedbacks from real field
- Prioritize the community’s development efforts
- Brainstorm architectural approaches for the next generation of logical replication features
Meeting summary
DDL Replication
DDL replication remains the largest open item.
Two design directions were discussed:
- Event trigger + JSON deparser
- Deparse DDL into a JSON representation and send it through the replication stream.
- A key point was to generate JSON from catalog state, not only from parse trees.
- ALTER statements require special handling because post-ALTER catalog state alone does not always explain what changed.
- This direction may require storing and sending additional metadata (for example OIDs), so WAL payload size is a concern.
- Some participants suggested "event-trigger-like" behavior without strictly depending on event triggers as the implementation mechanism.
- Decode and replicate catalog WAL records
- Catalog WAL already exists and is consumed by logical decoding internally, but catalog changes are not currently exposed as logical change records.
- One option is to use catalog WAL records as DDL signals on the wire.
- This could avoid shipping low-level table-rewrite inserts by sending logical DDL intent instead.
No final conclusion was reached. The consensus was to continue discussion on pgsql-hackers, with deparsing and logging as a practical baseline.
Considerations:
- Deparsing DDL to JSON
- DDL command capture
- JSON generation from catalog state, especially for ALTER
Automatic conflict detection and resolution
Conflict detection itself is done. Open points:
- Conflict log history: permissions and ownership model for the conflict table (who can read and manage it).
- Conflict resolution: timestamp-based policies (for example last-write-wins using commit timestamps) depend on cross-node clock synchronization.
Performance comparisons with MySQL-based implementations were also mentioned.
Considerations:
- Conflict detection: done
- Conflict history table permissions
- Clock synchronization requirements for timestamp-based resolution
Centralized Decoder
The current architecture still enforces database-level isolation. In practice, this implies one decoder per database, and there is no generic single-decoder-for-all-databases solution today.
A question was raised about whether centralized decoding could help advance slot.xmin earlier (for example, once decoded tuples are persisted). The answer was effectively no, at least with current design constraints:
- Output plugins still need historic snapshots to resolve catalog metadata and filtering.
- Because of that dependency, slot.xmin cannot be safely advanced before downstream processing reaches a safe point.
Considerations:
- Database-wide isolation today
- One decoder per database in practice
- No feasible current design to advance slot.xmin immediately after decode-buffer persistence
Large Object Logical Replication
Headline implementation items were:
- Streaming large objects
- Initial sync behavior
The broader strategic discussion was whether LOB support should be expanded at all.
A concrete failure case was mentioned (OID exhaustion in a Hibernate-based application), but participants also noted ongoing operational overhead in current LOB design (for example per-object ACL metadata).
A recurring view was to discourage LOB usage where possible:
- Prefer regular tables for binary content
- Consider moving LOB support to an explicitly installed extension so usage is deliberate
A technical alternative discussed was a bigint-key plus TOAST approach. That discussion noted a current TOAST limitation: full-value rewrite on update. Improving TOAST for partial update and seek was viewed as a potential long-term replacement path for many LOB use cases.
Considerations:
- LOB streaming
- Initial sync
- Bigint key + TOAST direction
- TOAST chunk/compression tradeoffs
- Partial update and seek support in TOAST
- JSON as an alternative storage target in some use cases
- Explicit extension model for LOB support
Failover and Switchover
Failover and switchover were both listed as ongoing work.
Switchover appeared repeatedly in discussion, indicating that planned role-swap operations are still seen as operationally incomplete in logical replication workflows.
Send Only Changed Columns on UPDATE
Today, logical replication ships the full new tuple on UPDATE.
There is interest in sending only changed columns to reduce traffic and downstream apply cost. This topic is closely related to centralized decoding and row-shape handling.
Avoid PK Requirement or REPLICA IDENTITY FULL
The current system generally requires usable row identity (typically primary key, otherwise REPLICA IDENTITY FULL).
The idea of using tuple identifiers directly on the subscriber side was raised and rejected in discussion:
- Tuple IDs are not exposed to decoding today.
- Exposing them would require capture-side changes.
- Strong preference was to keep changes in the decoding layer, not the WAL/write path.
Considerations:
- Ship only changed columns on UPDATE
- Determine changed columns reliably on the source side
- Row identity is still required
- Tuple ID exposure would require capture-side changes (not preferred)
- Keep work in decoding layer
New Logical Replication Features on Older PostgreSQL Versions
Logical replication is a special case because it is heavily used for major-version upgrades.
A key tension discussed:
- Stable branches should minimize destabilizing changes
- But upgrade workflows may need enough capability in older versions to interoperate with newer replication features
Consideration:
- Targeted backport strategy for upgrade-critical logical replication capability
Logical Replication for Major Version Upgrade
There is no fully "easy mode" workflow today.
Open practical gaps include:
- Sequences and identity handling
- Multi-database clusters
- Operational safety during live upgrade
Stabilizing source behavior during upgrade
A common operational risk is uncoordinated DDL during upgrade. One proposed mitigation was an "upgrade in progress" control (for example a GUC or extension-level mechanism) that blocks unsafe operations while logical-replication-based upgrade is running.
Two paths were discussed:
- Implement DDL replication so DDL during upgrade can flow safely
- Block risky DDL by default when DDL replication is unavailable
Several participants favored the second path as near-term default because it is simpler and safer.
A related suggestion was to propose this as a core extension and gather feedback on pgsql-hackers, along with explicit documentation of current limitations.
Blue/green deployment demand (including cloud environments such as AWS) was cited as a major driver.
Cross-version feature bridging
pg_dump can handle static baseline schema, but it is not a live stream and does not solve dynamic DDL drift during migration windows.
The replication protocol can negotiate version compatibility between sender and subscriber, but feature gaps still remain.
One proposal was to install a newer-version decoding plugin on an older source so change data can be emitted in a format that a newer target understands. This is conceptually similar to existing pgoutput-replacement extension patterns.
A concern raised for delta-driven approaches was schema drift: replaying source-side DDL does not automatically validate compatibility with target-side live state.
JSON-on-the-wire was also discussed here as a potential mechanism for finer publisher/subscriber control over accepted change shape.
Considerations:
- Upgrade guardrail mechanism to block unsafe DDL
- "Upgrade in progress" intent flag model
- DDL replication vs. DDL blocking fallback
- Core extension proposal and hackers feedback
- Document known non-working cases
- Blue/green deployment pressure as key driver
- Cross-version plugin strategy
- Open user-managed gaps: sequences, identities, multi-DB clusters
Suggested Follow-up Actions
- Continue DDL replication design discussion on pgsql-hackers with explicit comparison criteria between JSON deparsing and catalog-WAL-driven approaches.
- Define permission model for conflict history table before broader rollout.
- Review more parallel apply
- Clarify roadmap decision on LOB direction (improve vs. discourage/extensionize).
- Draft an upgrade safety extension proposal focused on blocking unsafe DDL during logical-replication-driven upgrades.
Whiteboard photo
