Question: What version compatibility is required for PostgreSQL logical replication?


Logical replication in PostgreSQL allows changes from one database server (the publisher) to be streamed to one or more other servers (subscribers). It's a powerful feature introduced in PostgreSQL 10 that enables use cases such as selective table replication, cross-version replication, and more. Understanding version compatibility is crucial for setting up logical replication successfully.

Version Compatibility

For logical replication to work, the PostgreSQL versions play a critical role. Here are the key points concerning version compatibility:

  • Publisher and Subscriber Version: The subscriber must be running a PostgreSQL version that is the same as or newer than the publisher's version. This ensures that the subscriber can understand the replication format produced by the publisher.

  • Cross-Version Replication: Logical replication supports cross-version replication, allowing you to replicate data from an older version of PostgreSQL to a newer version. This capability facilitates smoother upgrades to newer PostgreSQL versions by minimizing downtime.

Example Scenario: Upgrading PostgreSQL with Logical Replication

A common use case for logical replication is performing zero-downtime upgrades between major PostgreSQL versions. Here's a simplified step-by-step guide:

  1. Setup Logical Replication on the Old Version:

    • On your existing PostgreSQL server (e.g., version 10), configure a publication for the databases or tables you want to replicate.
      -- On publisher (version 10) CREATE PUBLICATION my_publication FOR ALL TABLES;
  2. Subscribe from the New Version:

    • Set up a new PostgreSQL server with a higher version (e.g., version 12).
    • Configure this new server as a subscriber.
      -- On subscriber (version 12) CREATE SUBSCRIPTION my_subscription CONNECTION 'host=old_server dbname=mydb user=replicator password=secret' PUBLICATION my_publication;

This setup will start replicating data from the old server (publisher) to the new server (subscriber). Once the initial data sync is complete and ongoing changes are being replicated in real-time, you can gradually switch your application's database connections from the old server to the new server.

Caveats and Considerations

  • DDL Replication: Logical replication does not automatically replicate schema changes (DDL). You need to apply those changes manually on the subscriber.
  • Sequence Data: If you're replicating tables that include sequences (e.g., serial columns), remember to set up sequence replication to ensure values are consistent.
  • Performance Impact: While logical replication is designed to minimize impact on the publisher, it's essential to monitor performance and adjust your configuration as necessary.

In conclusion, logical replication offers a flexible solution for replicating data across different PostgreSQL versions. By understanding and managing version compatibilities and operational nuances, you can leverage logical replication for various purposes, including disaster recovery, scaling out read operations, or performing zero-downtime upgrades.

Was this content helpful?

White Paper

Free System Design on AWS E-Book

Download this early release of O'Reilly's latest cloud infrastructure e-book: System Design on AWS.

Free System Design on AWS E-Book
Start building today

Dragonfly is fully compatible with the Redis ecosystem and requires no code changes to implement.