Snowflake Postgres logical replication¶

Snowflake Postgres allows you to set up logical replication to or from an external source. This may be useful for maintaining a local copy of your data, an on-premises replica, or streaming data to external analytics, ETL, or change data capture (CDC) platforms.

The following are the default settings for logical replication on your instance and each of these can be adjusted as needed for your instances by customizing these configuration parameters:

wal_level = logical
max_wal_senders = 10
max_replication_slots = 10
max_logical_replication_workers = 4

Using the snowflake_admin role, you can set up logical replication publications and subscriptions and create replication slots. See more in the Postgres documentation about logical replication.

Logical replication failover¶

Snowflake Postgres supports logical replication failover for logical replication subscribers of Snowflake Postgres instances acting as logical replication publisher nodes under the following conditions:

• The Snowflake Postgres publisher node is a primary instance. Logical replication failover with read replicas acting as logical replication publisher nodes is not supported by Postgres.
• The Snowflake Postgres publisher primary instance 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;

• Replication slots for non-Postgres subscribers 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 major version upgrades, but you must disable the subscription before finalizing the upgrade and re-enable it when the upgrade is complete.
  • Refresh and Modify failovers.
  • Availability failovers on primary instances that have high availability enabled. If a primary instance without high availability enabled experiences an availability issue that requires replacement, the logical replication subscription will not survive intact.