Logical Replication

Logical replication is a migration scenario for minimal downtime. But in SPG99, it should be treated as an advanced path that must be confirmed and tested in your environment beforehand.

Why a separate pilot is needed

Logical replication depends on prerequisites on the PostgreSQL side and on runtime configuration. Before you design the cutover, make sure the following are agreed for your scenario:

• support for the required mode on the source and the target;
• requirements for publications, subscriptions, and replication workers;
• acceptable behavior for slots, lag, and the cutover window.

When this path makes sense

Use it if:

• the downtime window is very limited;
• the data volume is large and a full pg_restore is inconvenient;
• you have time for a test run and validation before production.

General workflow

1. Configure a publication on the source database.
2. Prepare the target database in SPG99.
3. Create the subscription on the target side, if this is confirmed for your environment.
4. Wait for stable synchronization.
5. At cutover, freeze writes on the source, wait for minimal or zero lag, and switch applications to the new DSN.

What matters for the user

• a separate manual start for the database is not needed in the managed environment;
• during replication, it is useful to track the actual lag, logs, and database state;
• a production switch always requires a test on a separate tenant or in a test environment.

Practical recommendation

If you do not need minimal downtime at any cost, it is almost always more reliable and simpler to choose pg_dump / pg_restore. Logical replication is justified only where its complexity is truly worth the business requirement.