Logical replication

Crunchy Bridge allows you to set up logical replication to an external source. This may be useful for you to have a local copy of your data, on-prem replica, or stream data to data analytics / ETL / CDC platforms like Snowflake, BigQuery, Databricks, etc.

The default settings for logical replication on your provision are:

wal_level = logical
max_wal_senders = 10
max_replication_slots = 10Copy

With Crunchy Bridge superuser rights, you can set up the replication publisher and subscriber and create replica slots. Be sure to also check the networking and permissions for your external sources to configure this. See more in the Postgres docs about logical replication.

Logical replication failover

Crunchy Bridge supports logical replication failover for logical replication subscribers of Crunchy Bridge clusters acting as logical replication publisher nodes under the following conditions:

• The Crunchy Bridge publisher node is a primary cluster. Logical replication failover with read replica nodes acting as logical replication publisher nodes is not supported by Postgres.
• The Crunchy Bridge publisher/primary cluster is on Postgres 17 or later.
• If the subscriber was created with Postgres's CREATE SUBSCRIPTION, it must have been created using the failover = true option.
  • To migrate a pre-existing subscription to a failover-enabled subscription, use this process:

ALTER SUBSCRIPTION subname DISABLE;
ALTER SUBSCRIPTION subname SET (failover = true);
ALTER SUBSCRIPTION subname ENABLE;
Copy

• Non-Postgres subscribers using replication slots created with pg_create_logical_replication_slot() must use the function's failover => true option. Subscribers using logical replication slots that were not created with that option must be rebuilt with a new slot using that option for logical replication failover to work.
• With the above requirements met, logical replication failover will work for:
  • Postgres Upgrade operations, but you must disable the subscription before finalizing the upgrade and re-enable it when the upgrade is complete.
  • Cluster Refresh and Cluster Resize failovers.
  • Availability failovers on primary clusters that have High Availability (HA) enabled. If a primary cluster without HA enabled experiences an availability issue that requires replacement, the logical replication subscription will not survive intact.