ProGate 1.3 adds highly available CDC replication and Shardman support

On 7 July 2026, Postgres Professional introduced ProGate 1.3.0, an update to its toolkit for migration, one-time data transfer and continuous replication between database systems. Postgres Pro Shardman can now be used as a target, while the prosync utility adds a high-availability mode for CDC replication.

The operational significance is not a headline speed increase. It is the option to reduce the risk of synchronization stopping during a long migration. The vendor announcement does not, however, replace validation against the buyer’s schema and workload.

What ProGate 1.3.0 adds

According to Postgres Professional, the release includes:

• migration into Postgres Pro Shardman through procopy;
• continuous replication into Shardman through prosync;
• rule-based routing of rows between Shardman segments;
• a high-availability prosync mode with an active instance and standbys;
• Oracle 11g as a source alongside versions 12c, 18c and 19c;
• improvements for Oracle RAC and PostgreSQL-to-Oracle scenarios;
• additional security checks and events in procheck;
• environment-variable substitution in configuration files.

Environment-variable substitution is useful in automated deployments because addresses and sensitive parameters do not have to be written directly into configuration. Secrets should still come from a controlled store and remain outside normal logs.

How prosync high availability works

Several prosync instances with the same configuration can operate together. One acts as leader, while the others remain on standby and are ready to continue replication if the active instance fails. This protects the change-capture and transfer process from a single instance failure.

It does not make the entire migration automatically fault tolerant. The source and target databases, network, transaction logs, state storage, identities and failover rules remain dependencies. A test must therefore confirm not just that the standby starts, but also the position from which synchronization resumes.

What to test before moving into Shardman

Row routing can distribute data across segments during migration. A faulty routing condition can also create a systematic problem by sending records to the wrong segment or producing an uneven distribution.

Before production cutover, test:

1. a complete initial load and row-count reconciliation;
2. type, encoding, XML, geometry and custom-object conversion;
3. data distribution across segments and skew;
4. CDC lag at normal and peak load;
5. failover from the prosync leader to a standby;
6. missing or repeated changes after failover;
7. network interruption and transaction-log growth;
8. a reversible stop and rollback procedure.

These checks belong in the wider infrastructure migration plan, even when the destination is not a public cloud.

Replication is not a backup

CDC moves legitimate changes quickly, but it may also propagate an accidental deletion or incorrect update. Point-in-time recovery still requires independent backups, retained logs and tested restoration. Our backup and fault-tolerance guide explains these layers.

Replication also needs its own telemetry: lag by time and volume, last confirmed transaction position, reconnect frequency, leader and standby state, conversion errors and reconciliation results. Those signals should feed the wider IT infrastructure observability layer.

What the announcement does not disclose

The public source does not provide comparative benchmarks, guaranteed lag, automatic failover time, a complete matrix of data-type limitations or project-specific licence terms. Zero lost changes or a particular RPO therefore cannot be promised from the feature list alone.

ProGate 1.3.0 broadens the options for staged database migration and reduces the continuous-replication process’s dependence on one instance. The practical result will depend on whether routing, leader change, data integrity and recovery are tested before final cutover.