Best Postgres Replication Tools in 2026

Postgres replication tools fall into three families in 2026. The built-in methods, streaming replication for standbys and logical replication for selective Postgres to Postgres copies. Self-run change data capture engines such as Debezium, Filament, and PeerDB that read the logical slot and write to warehouses and lakes. And managed pipelines such as Fivetran and Airbyte, billed by rows or gigabytes. Destination, deletes, and who runs the software decide the pick.

What does Postgres replication actually mean?

Postgres replication is any method that keeps a second system in step with committed changes on a Postgres primary, and the word covers two different mechanisms. The Postgres docs separate physical replication, which uses "exact block addresses and byte-by-byte replication", from logical replication, which copies data objects "based upon their replication identity (usually a primary key)."

Physical replication clones the cluster, logical replication ships rows. Streaming replication sends WAL records to a standby "as they're generated", per the warm standby docs, and that standby serves reads but not writes. It only works between the same major version. Logical replication copies a snapshot of each table, then streams later changes, so it crosses versions and lets the subscriber hold its own data.

Logical decoding is also the foundation every external tool builds on. Postgres exposes committed changes through a replication slot and an output plugin, and pgoutput "is the standard one used for the built-in logical replication." A CDC engine opens its own slot and writes wherever Postgres cannot. The restrictions page says "the database schema and DDL commands are not replicated" and "sequence data is not replicated."

How should you choose a Postgres replication tool?

Six criteria separate these tools, and the first one, the destination, eliminates most candidates before anything else matters. Built-in replication only reaches another Postgres. A warehouse or lake needs an engine that writes typed tables or Parquet files.

On deletes, the difference is mechanical. Log based capture sees every committed change. Query based capture polls a column such as xmin, and Fivetran's docs say that mode "does not preserve details about deleted rows." On recovery, Debezium's docs set the ceiling, exactly once in normal operation and "at least once delivery of change events" after a fault.

The best Postgres replication tools in 2026, ranked

The ranking serves a team that owns a production Postgres and needs a current copy somewhere else. Entries two and three are the built-in methods and belong on any Postgres to Postgres shortlist. External tools are ordered by how many of the six criteria they clear.

1. Filament. A Go replication engine that runs as one binary or a Go library, reading Postgres in full, incremental, or CDC mode through pgoutput. Per the Postgres source docs, each table is first read through the slot's exported snapshot, "so the baseline and the change stream share one consistent point." Destinations include Postgres, ClickHouse, Snowflake, BigQuery, Iceberg, and S3. The limit is source breadth, Postgres and MySQL only.

2. Postgres logical replication. The built-in publish and subscribe method, needing nothing beyond wal_level=logical, a publication, and a subscription, and the right default for a selective Postgres to Postgres copy or a cross-version upgrade. The logical replication docs describe a snapshot copied to the subscriber, then changes "sent continually." The limits are the DDL and sequence gaps above, and the subscriber must be Postgres.

3. Postgres streaming replication. The physical method and the only entry that gives you a failover target. The warm standby docs note it is "asynchronous by default" and that shipping between different major versions "is not possible." Pair it with Patroni or repmgr for automatic promotion. It cannot filter tables or feed a warehouse.

4. Debezium. The reference open source CDC engine, Apache 2.0 per its LICENSE, reading pgoutput and publishing each table to its own Kafka topic. Its strength is fan-out to many consumers. The cost is the stack, since the architecture docs say "most commonly, you deploy Debezium by means of Apache Kafka Connect", and no warehouse writer ships in the box.

5. PeerDB. A Postgres-first engine that ClickHouse acquired and now ships as the ClickPipes Postgres connector, with TOAST caching as its best trick. The limits are target and weight. Only ClickHouse and Postgres destinations are actively maintained, the architecture needs Temporal plus a catalog Postgres, and the LICENSE file is AGPLv3 although the README badge says ELv2.

6. pglogical. The 2ndQuadrant extension that gave Postgres logical replication before the core shipped it, still maintained with a maintenance release in July 2026. Its strength is row filtering on older clusters. The README says EnterpriseDB now focuses new features on its descendant, Postgres Distributed, and that "automatic DDL replication is not supported." Pick it for a legacy cluster, not a new design.

7. Fivetran. The widest managed catalog, a connector that supports pgoutput, and the answer for a team that will not operate replication software. The meter is the concern. Fivetran bills by monthly active rows, "the number of distinct rows synced from the source system to your destination system in a given calendar month." Its query based fallback drops deletes, and one-minute syncs sit on the Enterprise tier.

8. Airbyte. The largest open connector catalog, a free self-hosted Core, and CDC that embeds Debezium. The Postgres source docs list "CDC, xmin and standard" methods, and the troubleshooting page notes a CDC source "can only be used with a single Airbyte destination." The platform LICENSE is ELv2 and Cloud bills 4 credits per GB.

9. AWS DMS. The easy answer for a migration into AWS, with full load plus CDC from Postgres into RDS, Aurora, Redshift, or S3. The source docs say DMS "uses either test_decoding or pglogical plugin", and the CDC task docs state "there are no SLAs for CDC latency." Billing is by instance hour, inside AWS only.

10. pgEdge Spock and EDB Postgres Distributed. The two multi-master options, both descended from pglogical. The Spock README provides "multi-master replication for PostgreSQL" under the PostgreSQL license, and EDB PGD adds "DDL replication, replication sets, sequences, stream triggers" on a commercial stack. Pick these when every node must accept writes.

Ten more tools replicate from Postgres but serve one destination, one cloud, or a shrinking niche.

How we ranked these Postgres replication tools

Each entry was scored on the six criteria from its own documentation, its LICENSE file rather than a README badge, and its public pricing page, all fetched on October 1, 2026. Where a tool ran in the 2026-08-31 cohort, a full load of 298,270,427 NYC Taxi rows from one RDS Postgres to another, its result is reported. No tool gets a speed claim on a route without a public run.

The Debezium row is its initial snapshot with a JDBC sink, not the steady-state streaming it is built for, and the benchmark README says so. The methodology verifies row counts, not row contents. Fivetran, Estuary, DMS, and the built-in methods did not run, so they carry no number here.

Where Filament fits against these criteria

Filament clears all six criteria for a Postgres team, and its real limit sits outside them, since it reads Postgres and MySQL and nothing else. Galaxy builds Filament, so weigh this section accordingly. The Postgres source and sink are both beta, per the connector overview, meaning they run end to end but are not yet verified for every environment.

On destination, one engine writes typed tables to Postgres and the warehouses, and Parquet to Iceberg, S3, and GCS. On deletes, CDC streams pgoutput and the Postgres sink applies cdc_merge, where "inserts and updates upsert, and deletes delete."

On recovery, every batch carries a CRC32-C checksum that the sink recalculates. The integrity docs explain the check "is sensitive to row order, column order, nulls, values, and operations. It is not based only on row counts." A failed run resumes from its checkpoint rather than restarting.

On footprint, the local CLI uses SQLite with no Postgres or NATS, and production is one Helm chart with Postgres and NATS JetStream. On cost, the LICENSE is Apache 2.0 and there is no meter.

On the baseline copy, Filament loaded the cohort in 115 s, the fastest wall time of the seven tools measured and 4.3 times faster than pg_dump piped into psql.

How to replicate Postgres with Filament

Two prerequisites on the source, then one pipeline definition. Set wal_level=logical if you want CDC, which the Postgres docs say "can only be set at server start", and give every streamed table a primary key, since incremental and CDC modes reject keyless tables.

Install with one command from the installation page, then create the source, the sink, and the pipeline. The commands below are the documented CLI example for a Postgres to Postgres copy.

curl -fsSL https://getgalaxy.io/filament/install | sh

filament source create production \
  --source-connector postgres \
  --source-connection-method url \
  --source-dsn-env POSTGRES_DSN

filament sink create warehouse \
  --sink-connector postgres \
  --sink-connection-method url \
  --sink-dsn-env POSTGRES_SINK_DSN

filament pipeline create users-copy \
  --source production \
  --sink warehouse \
  --resources users,audit,logs \
  --sync-mode full \
  --write-mode

curl -fsSL https://getgalaxy.io/filament/install | sh

filament source create production \
  --source-connector postgres \
  --source-connection-method url \
  --source-dsn-env POSTGRES_DSN

filament sink create warehouse \
  --sink-connector postgres \
  --sink-connection-method url \
  --sink-dsn-env POSTGRES_SINK_DSN

filament pipeline create users-copy \
  --source production \
  --sink warehouse \
  --resources users,audit,logs \
  --sync-mode full \
  --write-mode

curl -fsSL https://getgalaxy.io/filament/install | sh

filament source create production \
  --source-connector postgres \
  --source-connection-method url \
  --source-dsn-env POSTGRES_DSN

filament sink create warehouse \
  --sink-connector postgres \
  --sink-connection-method url \
  --sink-dsn-env POSTGRES_SINK_DSN

filament pipeline create users-copy \
  --source production \
  --sink warehouse \
  --resources users,audit,logs \
  --sync-mode full \
  --write-mode

The first run reads each table in up to 64 parallel ranges, encodes rows into binary COPY, and checkpoints after every written batch. To turn the copy into a live mirror, set replication: cdc on the source and write_mode: merge on the pipeline. Filament then creates the publication and slot, copies each table through the exported snapshot, and streams changes in bounded catch-up cycles that can run on a cron.

What are the common pitfalls with Postgres replication?

Four failures show up with every tool on this list, built-in methods included.

• Replication slots hold WAL until the consumer confirms it. The logical decoding docs warn that in extreme cases "this could cause the database to shut down to prevent transaction ID wraparound."

• DDL does not travel through logical decoding, so an ALTER TABLE on the primary reaches no subscriber on its own.

• Updates and deletes need a replica identity, and the publication docs say tables without one "cannot support UPDATE or DELETE operations."

• An update that leaves a TOAST column untouched arrives without its value unless the table has REPLICA IDENTITY FULL or the tool caches it.

Which Postgres replication tool fits which job?

Pick by the constraint that breaks first.

For the main reader, a team that keeps data in its own network and needs Postgres mirrored into a warehouse, a lake, or a second Postgres, Filament is the pick because it meets all six criteria with documented behavior. For failover, use streaming replication. For a Kafka change bus, use Debezium.

Related guides

• Database replication, the complete guide for 2026

• Best CDC tools in 2026

• Postgres replication benchmark, 7 tools tested on 298M rows

• Fastest Postgres to Postgres replication, 2026 benchmark

• Zero-downtime Postgres migration, step by step

• Full load vs incremental vs CDC, which to use

• Introducing Filament

Frequently asked questions

What are the main types of Postgres replication?

Postgres ships two methods. Physical streaming replication copies the write-ahead log byte for byte to a standby that is a read-only clone of the whole cluster. Logical replication decodes committed changes to selected tables and sends them through a publish and subscribe model. External tools build on logical decoding to reach warehouses, lakes, and other databases.

What is the difference between streaming replication and logical replication in Postgres?

Streaming replication mirrors the entire cluster at the block level, needs the same major version on both sides, and produces a standby you cannot write to. Logical replication works per table, crosses major versions, and lets the subscriber hold other data, but it does not carry DDL, sequences, or large objects. Use streaming for failover and logical for selective copies.

Which Postgres replication tool is best for high availability?

Built-in streaming replication with a cluster manager such as Patroni or repmgr is the standard answer for failover and read replicas. The standby stays within seconds of the primary and can promote when the primary fails. Logical replication and CDC tools are not failover tools, they move data to other systems.

What is the best open source Postgres replication tool?

It depends on the destination. For Postgres to Postgres the built-in logical replication needs no extra software. For a shared change feed on Kafka, Debezium is the reference engine. For copies into a warehouse, lake, or another Postgres that you run yourself, Filament is an Apache 2.0 engine with checkpointed full, incremental, and CDC reads and the fastest full load in the public cohort.

Does Postgres logical replication replicate schema changes?

No. The Postgres docs state that the database schema and DDL commands are not replicated, so the initial schema is copied with pg_dump and later changes must be kept in sync by hand. Sequences and large objects are not replicated either. Most CDC engines inherit the same limit, while EDB Postgres Distributed and pgEdge Spock add DDL replication.

Why does a replication slot fill up disk?

A replication slot keeps every WAL segment its consumer has not yet confirmed, and the Postgres docs warn that slots persist across crashes and know nothing about the state of their consumers. If the subscriber or CDC tool stops, WAL keeps growing until disk runs out. Set max_slot_wal_keep_size, monitor slot lag, and drop slots nobody uses.

How do you replicate Postgres to Postgres with Filament?

Install the binary, create a source and a sink that each point at a Postgres DSN, then create a pipeline that lists the tables, a sync mode, and a write mode. A full run copies tables in parallel ranges and checkpoints each batch. Setting replication to cdc on the source streams changes through pgoutput after an initial copy taken from the slot's exported snapshot.

Is Filament faster than pg_dump for copying a Postgres database?

In the public 2026-08-31 cohort, Filament copied the NYC Taxi tables from one Postgres to another in 115 seconds, while piping pg_dump into psql took 489 seconds on the same hardware. The cohort does not measure incremental or CDC throughput, so the comparison is limited to the initial copy.