PostgreSQL replication: built-in options, their limits, and when a CDC tool helps

For an executive: most PostgreSQL estates need nothing beyond the built-in replication, run and monitored properly. The assessment says which parts do, and why.

Before choosing a method, write down what the copy is for. The answer changes the design more than any setting does.

Relateddisaster recovery page

Streaming replication sends the primary's write-ahead log (WAL) to one or more standby servers, which replay it. The standby is an exact copy of the whole cluster and can serve read-only queries. It is the usual basis of PostgreSQL high availability.

The decisions that matter are few. Asynchronous replication keeps the primary fast but can lose the last few transactions on failover; synchronous replication waits for a standby to confirm, which protects those transactions and adds delay to every commit. PostgreSQL itself does not decide when to fail over: a failover manager, or a person following a written runbook, promotes the standby and moves the applications. Without that piece, a standby is a copy, not availability.

Logical replication publishes row changes from chosen tables (a publication) to another PostgreSQL database that subscribes to them. It needs wal_level set to logical, which takes a restart. It works across major versions and the subscriber stays writable, so it suits reporting copies, consolidation and upgrades. Its limits are known, and worth listing before production finds them:

Change data capture (CDC) reads the changes a database makes and applies them elsewhere; our change data capture page compares the capture methods. iblync is Interkey's own data migration and replication platform, and PostgreSQL is on its published connector list. It helps where the built-in options stop:

• A different target. Changes from PostgreSQL can be applied to another engine on iblync's connector list, with type and field mapping agreed per project.
• Throttling and queueing. Replication is throttled so production keeps its capacity, and if the target is unavailable, changes queue instead of failing and are applied on recovery.
• Two-way sync. iblync supports bi-directional synchronisation for a transition in which two systems both take writes; our bidirectional sync page covers the conflict rules this needs.
• Proof. iblync's own site states that validation uses checksums and row counts. The pass conditions for your data are agreed before anyone relies on the copy.

Relatedchange data capture pageiblyncbidirectional sync pagereal time replication page

• A standby in a second data hall, with a written and rehearsed promotion runbook.
• A reporting copy fed by logical replication, so month-end reports stop slowing the application.
• A major-version upgrade in which the new cluster subscribes to the old one and the switch takes minutes, not a long dump and restore.
• A feed into another platform through CDC, with mapping and validation, while PostgreSQL stays the system of record.

Estates that run several engines tend to ask the same questions of each; our pages on MySQL replication and SQL Server replication cover those sources.

One team for the assessment, design, build, monitoring and rehearsals, with support from Riyadh in Arabic and English. The standby, the replica and the replication tooling can run on infrastructure inside the Kingdom, which matters when the data is personal or regulated; where each copy may live is settled before any copy is made. If replication lag is already a worry on a running estate, our PostgreSQL monitoring page covers how to watch it.

Quotes are per engagement, after the assessment. The drivers are the number of clusters and copies, the change rate, whether a copy must be synchronous, how many tables lack keys, how often the schema changes, whether the target is another engine, the deployment model, and who runs replication afterwards. iblync itself is priced by quotation, per source system, target system and data volume.