pglogical 2.3.3 extends logical replication to PostgreSQL 13
PostgreSQL 13 support gives pglogical users another target for logical replication. Extension compatibility still leaves decisions about schemas, initial synchronization and application cutover.
A database upgrade that relies on replication needs support from the replication software on the destination version. pglogical 2.3.3 adds PostgreSQL 13 support, according to the announcement posted on October 29. Its release dateline is October 5. For an installation using this extension, the new compatibility removes one specific obstacle to including PostgreSQL 13 in a logical replication arrangement.
The announcement describes pglogical as an extension implementing logical replication. That matters to upgrade planning because the extension's compatibility is a separate question from whether PostgreSQL itself has shipped. A migration using an extension needs the extension available in the participating server environments. Availability of a new server release does not answer that requirement automatically.
I prefer PostgreSQL for relational work, and its substantial extension system is part of that preference. Compatibility work like this makes the extension model useful across major releases. It also puts a concrete dependency into an upgrade decision, since the database and replication extension have to support the intended arrangement together.
Logical decoding supplies changes to consumers
The PostgreSQL 13 logical decoding documentation describes infrastructure that streams SQL modifications to consumers. Logical replication slots identify streams, and an output plugin determines their format. Plugins can use new row values for inserts and updates. Availability of old row values for updates and deletes depends on replica identity.
This explains why logical replication needs more than a network connection between two servers. The source must produce a usable change stream, and the consumer must interpret and apply it. Row identity affects how a change refers to an existing row. Schema compatibility affects whether the destination can represent the incoming change with the intended meaning.
The logical decoding infrastructure can serve consumers beyond one particular replication extension. That distinction is useful when reading an extension compatibility announcement. PostgreSQL supplies mechanisms, while the extension supplies a particular replication system built around them. Support for a new major version has to account for the interfaces and behaviour that system actually uses.
Physical streaming solves a different problem
The streaming replication documentation describes a standby receiving WAL records from a primary as they are generated. Streaming avoids waiting for a complete WAL file before transferring its contents. The standby still needs the records required to continue recovery, whether received directly or obtained from an available archive.
That description emphasizes continuity of the physical recovery stream. A server that falls behind far enough to lose required WAL may need reinitialization from a new base backup. Replication slots or sufficient retained WAL can address that retention problem. These are concrete obligations of maintaining the standby's recovery input.
A logical migration has a different objective. It needs a destination that can accept the selected data changes in its own database objects. Calling both arrangements replication is reasonable, but it does not make their initialization and compatibility requirements interchangeable. An upgrade procedure should identify which mechanism it relies on before describing what the new server version changes.
The extension's requirements remain explicit
The pglogical 2.3.3 manual describes providers, subscribers and replication sets. It works at database scope rather than copying an entire server. Its supported uses include major-version upgrades and selective replication. The extension must be installed on both sides, and the documentation requires corresponding tables with compatible names, schemas and column types.
The manual also distinguishes starting a subscription from finishing synchronization. Creating the subscription initiates background work. A separate wait function waits for the required initial schema and data synchronization to finish. For an already configured subscription named migration_to_13, that operation is expressed as follows:
SELECT pglogical.wait_for_subscription_sync_complete('migration_to_13');
That distinction has a direct implication for a migration procedure. Successful creation of a subscription establishes that setup began, but does not establish that the destination is ready for an application to use. Initial synchronization is a milestone with its own meaning. Application cutover needs an explicit decision about which server accepts subsequent work.
I regard the new version support as permission to design that migration using a supported destination, with the remaining steps still described separately. Extension installation, schema compatibility and synchronization each establish different facts. The application transition should use those facts to identify the intended destination database state when connections move to the new server.
The benefit of the compatibility release is therefore specific. A pglogical user can include PostgreSQL 13 in the extension's replication arrangement. The release announcement does not replace the arrangement's schema requirements or turn subscription creation into a completed migration. Its practical value comes from making the new major version available within the replication system's documented model.