Canonical: https://molo17.com/solutions/postgresql-cdc/ Markdown mirror: https://molo17.com/solutions/postgresql-cdc/index.md Title: PostgreSQL CDC and real-time replication | MOLO17 Description: Log-based PostgreSQL CDC with wal2json replication slots. Replicate changes to warehouses, data lakes, and streams in real time with Gluesync. Start a trial. [Solutions](/solutions/) PostgreSQL CDC SOLUTION · POSTGRESQL CDC # PostgreSQL change data capture and real-time data replication **Real-time PostgreSQL CDC from the write-ahead log, without polling your production tables.** Gluesync by MOLO17 provides PostgreSQL CDC through a dedicated source agent that captures committed changes from the write-ahead log. The agent reads logical decoding output from a replication slot with the wal2json plugin, then delivers those changes continuously to the databases, warehouses, lakes, and event streams your teams already use. Manage every pipeline from Core Hub, the Gluesync control plane. [Start a Gluesync trial](/get-gluesync/) [Talk to us](/contacts/) VENDOR COMPATIBILITY ## Battle-tested on every PostgreSQL you run The same Gluesync PostgreSQL agent is tested against each vendor offering below, self-managed or fully managed, so capture behaves the same wherever PostgreSQL runs. - **PostgreSQL** Source Target Tested - **Amazon Aurora PostgreSQL** Source Target Tested - **Amazon RDS for PostgreSQL** Source Target Tested - **EDB Postgres** Source Target Tested - **Google Cloud SQL PostgreSQL** Source Target Tested - **Microsoft Azure Database for PostgreSQL** Source Target Tested WHO THIS IS FOR ## PostgreSQL teams moving a system of record into modern platforms - PostgreSQL DBAs who must approve replication from a documented list they can review: `wal_level`, replication slots, a replication role, and `wal2json`. The runtime role does not need `SUPERUSER` - Data platform leads feeding Snowflake, BigQuery, Amazon Redshift, data lakes, or Kafka from a PostgreSQL system of record, who want one control plane for sources and targets instead of a Kafka Connect cluster to run - Engineers who prototyped Debezium or a script around logical replication and now own replication slots, WAL retention, and on-call for a pipeline the business treats as infrastructure - Teams replacing AWS DMS, Qlik Replicate, or Fivetran HVR for PostgreSQL sources who want a commercial CDC path with [best-in-class enterprise support, rated 4.9/5 by customers](/support/#customer-ratings) and [heterogeneous targets](/integrations/?source=PostgreSQL#integration-finder), instead of a DIY replication setup THE PROBLEM ## PostgreSQL data that only moves in batches becomes stale PostgreSQL is usually the system of record, so scheduled extracts and timestamp-based polling leave analytics and downstream applications working from a copy that is already behind. Every poll also competes with the production workload for CPU and I/O. Buyers searching for PostgreSQL CDC or real-time PostgreSQL to Snowflake usually weigh three options: native logical replication, which is built for PostgreSQL-to-PostgreSQL subscribers; Debezium on Kafka Connect, which means running that stack yourself; and cloud-managed migration services, which stop at the cloud boundary. Gluesync addresses that pattern with **per-agent CDC**. A PostgreSQL source agent reads the write-ahead log through logical decoding, and target agents write to the destinations you choose. Kafka is one target option, not a requirement for the pipeline. HOW IT WORKS ## How Gluesync does PostgreSQL CDC ### Logical decoding through replication slots The PostgreSQL agent consumes changes through logical decoding. It reads the WAL records exposed by a replication slot, using the `wal2json` output plugin, and replays them continuously. The agent accepts both wal2json message formats, version 1 and version 2, and detects the format automatically. - **Replication slot:** the agent creates the slot it reads from, and it drops that slot during teardown. - **TRUNCATE:** captured from the WAL and forwarded to the target like any other change. ### What your DBA will be asked to enable The agent needs a server with logical replication enabled and a role that can read the source tables. This is the checklist; full statements are in the setup guide. 1. Set `wal_level` to `logical`. 2. Set `max_replication_slots` to at least the number of entities in the Gluesync configuration, and `max_wal_senders` to at least the number of slots. We recommend setting `max_wal_senders` slightly higher. 3. Allow replication connections for the agent in `pg_hba.conf`. 4. Install `wal2json` for your PostgreSQL major version. On releases that provide the `output_plugin_libraries` parameter, including the minor releases published on 13 August 2026, `wal2json` must be listed in it. Extend the list rather than replacing it, using separate SQL string literals: `ALTER SYSTEM SET output_plugin_libraries = 'pgoutput', 'test_decoding', 'wal2json';`, then `SELECT pg_reload_conf();`. 5. Create a role with `REPLICATION` and `LOGIN`, and grant it `SELECT` on the source tables. The role does not need `SUPERUSER`. 6. Set `REPLICA IDENTITY` to `DEFAULT` or `FULL` on each table you replicate. Only the table owner or a superuser can change it. ### Before and after images Tables set to `REPLICA IDENTITY FULL` include the old row values in each change, which Gluesync uses as before and after images. Gluesync uses them automatically once the setting is in place, so it applies only the changes that occurred, which saves bandwidth and processing time. Set it per table with `ALTER TABLE your_table_name REPLICA IDENTITY FULL;`. ### Connectivity, TLS, and topology - **Connection settings:** host or IP address, port (default 5432), database name, username, and password in the web UI. The REST API also accepts `enableTls` and `certificatePath`. - **TLS:** the agent supports TLS on the connection. - **Bi-directional sync:** enable Recursion Protection on the source. The replication role then needs `EXECUTE` on four `pg_replication_origin` functions, listed in the setup guide. ### Architecture around Core Hub Lightweight agents sit close to each system. Core Hub orchestrates them through its web UI and REST APIs and routes changes between source and target agents. A pipeline groups the PostgreSQL source agent, its target agents, and the entities they replicate; a snapshot seeds each target before CDC takes over. Core Hub and agents deploy with Docker, Docker Compose, or Kubernetes. [Explore the general CDC streaming architecture →](/solutions/cdc-streaming/) CAPTURE OPTIONS ## PostgreSQL capture method PostgreSQL has one Gluesync source agent, so the decision is not which agent but whether your server, or your managed service, lets you set `wal_level` and install `wal2json`. | Agent | Capture technique | Versions | Best for | | --- | --- | --- | --- | | [PostgreSQL agent ↗](https://docs.molo17.com/gluesync/latest/agents/postgresql-intro.html) | WAL logical decoding through replication slots, using the wal2json output plugin | PostgreSQL 10.0 and later, self-managed or managed (Amazon Aurora, Amazon RDS, Google Cloud SQL, Azure Database for PostgreSQL, EDB Postgres); wal2json required | Log-based capture on PostgreSQL 10 or later where you can set `wal_level` to `logical` and install `wal2json`. | TARGETS AND TOPOLOGIES ## Keep PostgreSQL as the system of record while modernizing destinations Use the [integrations directory](/integrations/?source=PostgreSQL#integration-finder) to pair PostgreSQL as a source or target with relational engines, NoSQL stores, cloud warehouses, object and lake storage, or event streams, subject to each agent's documented source and target role. As a target, the PostgreSQL agent bulk loads through `COPY` into a staging table, and tables with identity or auto-increment columns skip bulk mode. Gluesync keeps pace with your change volume at any scale. [MOLO17 Professional Services](/solutions/professional-services/) can size the deployment with your team. Target agents write in optimized batches, never row by row, and switch to native bulk load for both snapshots and CDC on targets such as [Snowflake](/solutions/replicate-to-snowflake/), [Google BigQuery](/solutions/replicate-to-bigquery/), [Amazon Redshift](/solutions/replicate-to-redshift/), [Microsoft SQL Server](/solutions/replicate-to-sql-server/), and [PostgreSQL](/solutions/replicate-to-postgresql/). - Offload reporting and API reads from the primary to another database or cache: see [database offload](/solutions/database-offload/) - Keep Snowflake, BigQuery, Amazon Redshift, or a data lake current with every committed transaction: see [warehouse sync](/solutions/warehouse-sync/) - Publish PostgreSQL changes to Apache Kafka or another event stream for services that consume them: see [CDC streaming](/solutions/cdc-streaming/) - Run a snapshot, then CDC, to keep PostgreSQL and a new platform aligned until cutover: see [cloud migration](/solutions/cloud-migration/) FAIR, HIGH-LEVEL COMPARISON ## Where Gluesync fits among PostgreSQL CDC approaches | Approach | What buyers usually get | Where Gluesync fits | | --- | --- | --- | | PostgreSQL native logical replication | Built into PostgreSQL with publications and subscriptions, using pgoutput. Subscribers are PostgreSQL instances, so other destinations need additional tooling | Gluesync reads the write-ahead log through wal2json and delivers to non-PostgreSQL targets under one Core Hub. See [CDC streaming](/solutions/cdc-streaming/) | | Debezium with Kafka Connect | Open-source connectors that you run on Kafka Connect, with offsets, schema history, sinks, and upgrades on your team | A productized PostgreSQL agent on wal2json, with Core Hub operations and MOLO17 support. Read the [Debezium alternative](/solutions/debezium-alternative/) comparison | | AWS DMS and other cloud-managed CDC | Managed inside one cloud, with source and target options that follow that provider's list | Agents run where PostgreSQL runs and deliver to targets across providers. Amazon Aurora, Amazon RDS, Google Cloud SQL, Azure Database for PostgreSQL, and EDB Postgres are all supported sources | | Qlik Replicate and Fivetran HVR-class commercial CDC | Mature replication portfolios with broad source coverage. Packaging and licensing vary by product | Agent-based commercial CDC on wal2json with Core Hub. See [migrating to Gluesync](/migrate-to-gluesync/) | | DIY scripts and table polling | Full control, with slot monitoring, WAL retention alerts, and recovery work owned by your team | A productized agent that drops its slot at teardown and reports source lag, with Core Hub monitoring. Read [PostgreSQL logical replication: slots, WAL and pgoutput](/blog/postgresql-logical-replication-slots-wal-pgoutput/) | RELATED CONTENT ## PostgreSQL CDC research and implementation detail - [PostgreSQL logical replication: slots, WAL and pgoutput](/blog/postgresql-logical-replication-slots-wal-pgoutput/) - [Log-based CDC explained](/blog/real-time-replication-log-based-cdc/) - [From MS SQL Server on-premise to PostgreSQL on AWS (webinar, Spanish)](/blog/webinar-on-real-time-data-replication-from-ms-sql-to-postgresql-on-aws/) - [Debezium alternative: managed CDC versus Kafka + Debezium](/solutions/debezium-alternative/) - [CDC streaming without source overhead](/solutions/cdc-streaming/) - [PostgreSQL agent overview ↗](https://docs.molo17.com/gluesync/latest/agents/postgresql-intro.html) - [PostgreSQL CDC: WAL-based setup with Gluesync ↗](https://docs.molo17.com/gluesync/latest/agents/postgresql-change-data-capture-wal.html) - [PostgreSQL troubleshooting ↗](https://docs.molo17.com/gluesync/latest/agents/postgresql-troubleshooting.html) FAQ ## PostgreSQL CDC questions What is PostgreSQL CDC with Gluesync? Change data capture from PostgreSQL by reading committed changes from the write-ahead log through logical decoding and the wal2json output plugin, then delivering those changes to configured targets through Gluesync agents and Core Hub. Which PostgreSQL versions does the source agent support? The PostgreSQL agent captures changes from PostgreSQL 10.0 and later. What does the DBA need to enable on the database? Set wal\_level to logical, set max\_replication\_slots and max\_wal\_senders high enough for your entities, and create a role with REPLICATION and LOGIN that can read the tables. Set REPLICA IDENTITY to DEFAULT or FULL on each table, and install wal2json, listing it in output\_plugin\_libraries on releases that have that parameter. The role does not need SUPERUSER. Which output plugin does Gluesync use for PostgreSQL CDC? wal2json, the required output plugin for the PostgreSQL agent. Does Gluesync support managed PostgreSQL services? Yes. The PostgreSQL agent is tested against Amazon Aurora PostgreSQL, Amazon RDS for PostgreSQL, Google Cloud SQL for PostgreSQL, Azure Database for PostgreSQL, and EDB Postgres, from PostgreSQL 10.0. The same wal\_level, replication slot, and wal2json prerequisites apply on every service. Can Gluesync also write to PostgreSQL? Yes. The PostgreSQL agent supports the target role over the built-in JDBC driver, with TLS, bulk load through COPY into a staging table, and the TRUNCATE before snapshot option in Core Hub. CDC BY SOURCE DATABASE ## Other sources Gluesync captures from - [Cosmos DB CDC](/solutions/cosmos-db-cdc/) - [Couchbase CDC](/solutions/couchbase-cdc/) - [Db2 LUW CDC](/solutions/db2-luw-cdc/) - [DynamoDB CDC](/solutions/dynamodb-cdc/) - [IBM i CDC](/solutions/ibm-i-cdc/) - [Informix CDC](/solutions/informix-cdc/) - [MariaDB CDC](/solutions/mariadb-cdc/) - [MongoDB CDC](/solutions/mongodb-cdc/) - [MySQL CDC](/solutions/mysql-cdc/) - [Oracle CDC](/solutions/oracle-cdc/) - [SAP ASE (Sybase) CDC](/solutions/sap-ase-cdc/) - [SAP HANA CDC](/solutions/sap-hana-cdc/) - [ScyllaDB CDC](/solutions/scylladb-cdc/) - [SQL Server CDC](/solutions/sql-server-cdc/) - [YugabyteDB CDC](/solutions/yugabytedb-cdc/) ## Evaluate Gluesync against your PostgreSQL write-ahead log Start a Gluesync trial on your infrastructure, or talk to MOLO17 about server prerequisites, managed service settings, and targets. [Start a Gluesync trial](/get-gluesync/) [Talk to MOLO17](/contacts/)