Best CDC Tools in 2026

Change data capture tools fall into three groups in 2026. Open source engines you run yourself, such as Debezium, Filament, PeerDB, and OLake. Managed pipelines priced by row, credit, or gigabyte, such as Fivetran, Airbyte Cloud, and Estuary. And enterprise suites such as Striim, Qlik Replicate, and AWS DMS. The pick depends on which logs a tool reads, how its first copy meets the stream, and how the bill grows.

What is change data capture and how does it work?

Change data capture is the practice of recording every insert, update, and delete a database commits and delivering that record somewhere else, in order. The SQL Server docs define it as a feature that "records activity on a database when tables and rows have been modified."

Log-based capture reads the database's own journal, so it sees every change and barely touches production. Postgres exposes that journal through logical replication. It needs wal_level=logical, a publication, a replication slot, and the built-in pgoutput plugin. MySQL exposes the binary log in row format. Oracle reads redo through LogMiner and MongoDB offers change streams.

The alternatives are weaker. Trigger-based capture writes a shadow row on every change and taxes every transaction. Query-based capture polls a timestamp or a column such as Postgres xmin, which Fivetran's docs say "may scan full tables", and it misses deletes without a separate delete scan. This list ranks only tools that read the log.

How should you choose a CDC tool?

Five criteria separate these tools, and source coverage comes first because a tool that cannot read your database is not a candidate. The other four decide how much it hurts to run. On recovery, Debezium's docs set the ceiling for the whole category, "exactly once" normally and "at least once" after a fault.

The best CDC tools in 2026, ranked

The ranking is for the most common reader of this page. That is a team that reads Postgres or MySQL, lands changes in Postgres, a warehouse, or a lake, and would rather run the tool than rent it. A team on Oracle or SQL Server should start at entries two, four, seven, and nine.

1. Filament. A Go replication engine that runs as one binary, a Go library, or a Helm chart, reading Postgres through pgoutput and MySQL through the binlog. Per the Postgres source docs, each table is read through the slot's exported snapshot, "so the baseline and the change stream share one consistent point." No meter, no Kafka. The limit is coverage, with no SQL Server, Oracle, or MongoDB source yet.

2. Debezium. The reference open source CDC engine, with the widest source list here, Postgres, MySQL, SQL Server, Oracle, MongoDB, and Db2, per the 3.6 connector list. Its strength is fan-out, since Kafka "allows many clients to independently consume these same data change events", per the README. The cost is the stack. The architecture page says you "most commonly" deploy it through Kafka Connect.

3. PeerDB. A Postgres-first engine that ClickHouse acquired in July 2024 and now ships as the ClickPipes Postgres connector. Its best trick is TOAST caching, which the docs say "eliminates the need of setting REPLICA IDENTITY FULL." The limits are targets and weight. Only ClickHouse and Postgres destinations are actively maintained, the architecture needs Temporal plus a catalog Postgres, and the LICENSE file is AGPLv3.

4. Estuary Flow. A managed streaming platform with log-based capture for Postgres, MySQL, SQL Server, Oracle, and MongoDB. Its claim is delivery. The materialization docs promise "end-to-end 'exactly once' semantics" when the endpoint is transactional. The tradeoffs are location and price. Pricing is $0.50 per GB plus $100 per connector each month, private deployment needs an annual contract, and the source license is BSL 1.1 until 2029.

5. Fivetran. The widest managed catalog, with "700+ fully managed connectors" per its pricing page, and real logical replication through pgoutput on Postgres. The concerns are the meter and the fallback. Fivetran bills by monthly active rows, so the invoice tracks your volume. Its query-based mode reads xmin and, per the connector docs, "does not preserve details about deleted rows." One-minute syncs are Enterprise only.

6. Airbyte. Airbyte embeds Debezium inside its Postgres, MySQL, SQL Server, and MongoDB sources and adds the largest open connector catalog with a free self-hosted Core. Its CDC docs say "we do not treat CDC sources as infinite streaming sources", so it drains the log on a schedule.

Destinations land a raw table plus a final table, a layout now being phased out. The platform LICENSE is ELv2, connectors are MIT, and Cloud bills 4 credits per GB.

7. AWS DMS. Database Migration Service captures changes from Oracle, SQL Server, MySQL, Postgres, and MongoDB with each engine's native log API, per the CDC task docs. It is the easy answer for an all-AWS shop that needs Oracle. The same page says it "does not provide real-time replication" and has "no SLAs for CDC latency." Pricing is by instance hour or serverless capacity, inside AWS only.

8. Striim. A streaming-native, log-based platform with Oracle, SQL Server, MySQL, Postgres, and MongoDB readers, per its connector list, aimed at the enterprise buyer that also wants in-flight transforms. The pricing page offers a free developer tier up to 25 million events a month, then Cloud priced on "the data you move" and a self-hosted Platform, both on quote.

9. Qlik Replicate. The former Attunity Replicate, acquired in 2019, and still the log-based workhorse where Oracle, Db2, and Sybase sit beside SQL Server, MySQL, and Postgres, per its product page. Its strength is legacy reach. Pricing is quote only and the software is proprietary.

Seven more tools read the log but serve one database, one destination, or one cloud.

How we ranked these CDC tools

Each entry was scored on the five criteria using its own documentation, its LICENSE file rather than a README badge, and its public pricing page, all fetched on September 24, 2026. Where a tool ran in the 2026-08-31 cohort, a full load of 298,270,427 taxi rows from Postgres to Postgres, 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. The benchmark overview says the cohort "does not currently measure incremental catch-up, steady-state CDC throughput, or recovery after failure." Read the table as the baseline copy every CDC pipeline starts with.

Where Filament fits against these criteria

Filament clears four of the five criteria for a Postgres or MySQL team and misses the first for everyone else. Galaxy builds Filament, so weigh this section accordingly. Both sources are beta, per the connector overview, meaning they run end to end but are not yet verified for every environment.

On consistency, the Postgres source copies through the slot's exported snapshot, and the MySQL source takes a brief read lock so the binlog position and the snapshot agree. On recovery, the runs docs state that "CDC saves its stream position only after a successful commit", and the Postgres sink makes cdc_merge idempotent on the primary key.

On footprint, the local CLI uses SQLite and an in-process bus, and production is one Helm chart with Postgres and NATS JetStream, no Kafka. On cost, there is no meter and the LICENSE is Apache 2.0. Every batch also carries a CRC32-C checksum verified on both sides of the write, per the integrity docs.

On the baseline copy, Filament loaded the cohort in 115 s, the fastest wall time of the seven tools measured, splitting large tables into up to 64 parallel ranges.

How to run CDC with Filament

Three prerequisites on the source, then one pipeline definition. Set wal_level=logical (a restart, per the Postgres docs), grant the connector user REPLICATION, and give every selected table a primary key, since CDC rejects keyless tables.

The pipeline below adapts the documented CLI example to CDC. Each key is documented on its connector page.

version: 1

sources:
  production:
    type: postgres
    config:
      connection_method: url
      dsn: env:POSTGRES_DSN
      replication: cdc

sinks:
  warehouse:
    type: postgres
    config:
      connection_method: url
      dsn: env:WAREHOUSE_DSN

pipelines:
  orders-cdc:
    source:
      ref: production
    sink:
      ref: warehouse
    resources:
      - orders
      - customers
    sync_mode: cdc
    write_mode

version: 1

sources:
  production:
    type: postgres
    config:
      connection_method: url
      dsn: env:POSTGRES_DSN
      replication: cdc

sinks:
  warehouse:
    type: postgres
    config:
      connection_method: url
      dsn: env:WAREHOUSE_DSN

pipelines:
  orders-cdc:
    source:
      ref: production
    sink:
      ref: warehouse
    resources:
      - orders
      - customers
    sync_mode: cdc
    write_mode

version: 1

sources:
  production:
    type: postgres
    config:
      connection_method: url
      dsn: env:POSTGRES_DSN
      replication: cdc

sinks:
  warehouse:
    type: postgres
    config:
      connection_method: url
      dsn: env:WAREHOUSE_DSN

pipelines:
  orders-cdc:
    source:
      ref: production
    sink:
      ref: warehouse
    resources:
      - orders
      - customers
    sync_mode: cdc
    write_mode

The first run creates a publication named filament, opens a slot with an exported snapshot, and copies both tables through it. Every later run is a bounded catch-up cycle from the oldest resource LSN to pg_current_wal_lsn(), so continuous CDC is a loop you can put on a cron. Verify with a row count on each side, then watch confirmed_flush_lsn in pg_replication_slots advance.

What are the common pitfalls with CDC tools?

Four failures show up with every tool on this list.

• Replication slots retain WAL until acknowledged, so a stopped consumer fills disk. The Postgres docs point to max_slot_wal_keep_size.

• DDL does not travel through logical decoding. The restrictions page says "DDL commands are not replicated."

• Updates that leave a TOAST column untouched arrive without its value unless the table has REPLICA IDENTITY FULL or the tool caches it.

• Tables without a primary key cannot be merged, and most tools reject them for CDC outright.

Which CDC tool fits which job?

Pick by the constraint that breaks first.

For the main reader, a Postgres or MySQL team that keeps data in its own network, Filament is the pick because it meets the consistency, recovery, footprint, and cost criteria with documented behavior. For Oracle, SQL Server, or a shared change bus, take Debezium, DMS, or Qlik.

Related guides

• What is change data capture, the complete guide

• Full load vs incremental vs CDC, which to use

• Postgres logical replication, the complete guide

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

• Database replication, the complete guide for 2026

• Introducing Filament

Frequently asked questions

What is a CDC tool?

A CDC tool reads a database's transaction log and turns every committed insert, update, and delete into an ordered stream of change events, then applies or publishes them somewhere else. Log-based tools tail the write-ahead log or binlog. Query-based tools poll a timestamp or transaction id and cannot see hard deletes.

What are the best open source CDC tools?

Debezium (Apache 2.0) is the most widely deployed and covers the most databases. Filament (Apache 2.0) is a single Go binary for Postgres and MySQL. PeerDB (AGPLv3) is Postgres-first and maintained by ClickHouse. OLake (Apache 2.0) writes Iceberg, and Maxwell (Apache 2.0) sends MySQL binlogs to Kafka or Kinesis.

Does CDC require Kafka?

No. Debezium's main topology runs on Kafka Connect, but Debezium Server, PeerDB, Estuary, Fivetran, Airbyte, and AWS DMS all stream changes without a Kafka cluster. Kafka earns its place when many independent consumers need the same ordered change feed, not when one warehouse needs a current copy of a table.

What is the difference between log-based and query-based CDC?

Log-based CDC reads the database's own transaction log, so it sees every change including deletes and adds almost no load to production tables. Query-based CDC polls tables on a timestamp or a system column such as Postgres xmin, which can scan whole tables and misses hard deletes unless the tool adds a separate delete scan.

Which CDC tool is best for PostgreSQL?

For a team that runs its own software and moves Postgres into Postgres, a warehouse, or a lake, Filament fits the criteria here most closely as of September 2026. It has checkpointed pgoutput streaming, a consistent snapshot bootstrap, and the fastest full load in the public cohort. Debezium fits a shared Kafka feed, and PeerDB fits a ClickHouse target.

Can CDC tools handle schema changes automatically?

Partly. Postgres logical decoding does not carry DDL, so no tool sees an ALTER TABLE in the stream itself, and Airbyte's docs note that changes made by ALTER do not appear in the logs. Most tools add new columns at the destination and leave type changes and dropped columns alone. Plan for add-only evolution and a re-sync when a type changes.

Why do replication slots fill up disk?

A Postgres replication slot holds WAL until the consumer acknowledges it. If the CDC tool stops or falls behind, the server keeps every segment and pg_wal grows without limit unless max_slot_wal_keep_size is set. Set that parameter, monitor slot lag, and use a tool that acknowledges its position on a fixed interval.

How do you run CDC from Postgres with Filament?

Set wal_level to logical, give the connector a user with the REPLICATION privilege, and point a pipeline at the tables with replication set to cdc and write mode set to merge. Filament creates the publication and slot, copies each table through the slot's exported snapshot, then streams changes in bounded catch-up cycles from the last committed position.