16+ Replication & ETL Extensions for PostgreSQL

pglogical, wal2json, SynchDB, pgsync, and other Postgres extensions for replication, ETL, and change data capture. Ranked by GitHub stars.

Last reviewed: May 15, 2026
16 extensions
1
repmgr
1.7k+7 30d

Replication manager for PostgreSQL

Replication & ETL·GPL-3.0·C
2
wal2json
1.5k+2 30d

Changing data capture in JSON format

Replication & ETL·BSD-3-Clause·C
3
pglogical
1.2k+7 30d

PostgreSQL Logical Replication

Replication & ETL·PostgreSQL·C
4
pgactive
1.1k+7 30d

Active-Active Replication Extension for PostgreSQL

Replication & ETL·Apache-2.0·C
5
pg_bulkload
4900 30d

pg_bulkload is a high speed data loading utility for PostgreSQL

Replication & ETL·BSD-3-Clause·C
6
decoder_raw
3470 30d

Output plugin for logical replication in Raw SQL format

Replication & ETL·PostgreSQL·C
7
decoderbufs
2600 30d

Logical decoding plugin that delivers WAL stream changes using a Protocol Buffer format

Replication & ETL·MIT·C
8

PG Failover Slots extension

Replication & ETL·PostgreSQL·C
9

automated ddl deployment using pglogical

Replication & ETL·MIT·C
10
mimeo
790 30d

Extension for specialized, per-table replication between PostgreSQL instances

Replication & ETL·PostgreSQL·SQL
11

Tools to migrate other databases to PostgreSQL

Replication & ETL·BSD-3-Clause·SQL
12
wal2mongo
180 30d

PostgreSQL logical decoding output plugin for MongoDB

Replication & ETL·Apache-2.0·C
13

build fact tables with Postgres

Replication & ETL·MIT·C
14

Have an accurate view on pglogical replication delay

Replication & ETL·PostgreSQL·C
15

Logical Replication output plugin

Replication & ETL·PostgreSQL·C
16

SQL-based test/example module for WAL logical decoding

Replication & ETL·PostgreSQL·C

What is a PostgreSQL Replication or ETL Extension?

Replication and ETL extensions extend Postgres' logical replication to support heterogeneous targets, capture changes as a stream (CDC — change data capture), or migrate data between systems. wal2json and decoderbufs expose WAL changes as JSON or Protobuf for Debezium-style CDC pipelines into Kafka, Pulsar, or Kinesis. pglogical extends core logical replication with row-level filtering, conflict resolution, and cross-version upgrades. SynchDB replicates from MySQL, SQL Server, and Oracle into Postgres. pgsync moves data between Postgres instances for sharding migrations and read-replica setup.

When to Add a Replication or ETL Extension

Use a CDC extension (wal2json, decoderbufs) when you need to stream Postgres changes to Kafka, search engines like Elasticsearch, or analytics warehouses — Debezium is the standard downstream consumer. Use pglogical when you need bidirectional replication, conflict resolution, or in-place version upgrades that built-in logical replication doesn't handle well. Use SynchDB for heterogeneous database replication (especially Oracle → Postgres migrations). For one-time data migrations, pg_dump and pgsync still cover most needs. Skip these for trivial cases where Postgres' built-in logical replication is sufficient — adding extensions adds operational complexity.

Frequently Asked Questions

What is change data capture (CDC) in Postgres?
CDC captures every row-level change (INSERT, UPDATE, DELETE) in Postgres as a stream of events — typically consumed downstream by Kafka, Pulsar, or a data warehouse. Postgres exposes changes via logical replication slots, and extensions like wal2json and decoderbufs format the output as JSON or Protobuf. The standard production CDC stack is Debezium reading from a Postgres logical slot using wal2json or pgoutput — widely used to keep search indexes, analytical warehouses, and microservices in sync with a transactional Postgres source.
What's the difference between pglogical and built-in logical replication?
Built-in logical replication (since Postgres 10) handles the basic case: stream changes from a publisher to a subscriber, table-by-table. pglogical (developed by 2ndQuadrant/EDB) adds features built-in lacks: row-level filtering with predicates, advanced conflict resolution for bidirectional or multi-master setups, sequence replication, and smoother upgrades between Postgres major versions. For one-way replication on the same version, built-in is enough. For multi-master, complex filtering, or version migration, pglogical is the production-grade choice.
How do I capture Postgres changes as a stream?
Install wal2json (or use pgoutput, the built-in plugin since Postgres 10), set wal_level=logical in postgresql.conf, create a logical replication slot with SELECT pg_create_logical_replication_slot('myslot', 'wal2json'); and consume changes either by polling pg_logical_slot_get_changes() or by attaching Debezium / a similar CDC connector. Debezium then publishes the change events to Kafka where downstream systems (Elasticsearch sync, data warehouses, microservices) consume them.
Can Postgres replicate to MySQL or Snowflake?
Not directly with built-in tools. Postgres logical replication targets other Postgres databases. To replicate Postgres → MySQL, MongoDB, or Snowflake, the standard pipeline is: wal2json + Debezium emitting events to Kafka, then Kafka Connect sink connectors writing to the target. Commercial tools like Fivetran, Airbyte, and Striim offer turnkey Postgres-to-anything replication. For one-time migrations, pg_dump → custom transformation → target import works for static snapshots.
Does CDC work on AWS RDS Postgres?
Yes — RDS supports logical replication on PostgreSQL 13+, including wal2json and the built-in pgoutput plugin. You need to set rds.logical_replication=1 in the parameter group, restart the instance, and ensure your IAM user has rds_replication role. Aurora Postgres supports it identically. Supabase and Neon also support logical replication and Debezium-style CDC. Restrictions vary: some providers cap replication slot count or require VPC peering to reach Kafka.

Manage PostgreSQL Visually

1bench is a modern GUI client for PostgreSQL — install extensions, write queries, and inspect schemas without leaving the IDE.

Try 1bench for PostgreSQL