Best CDC Tools in 2026

Updated November 9, 2026

Change data capture tools read a database’s own change log and replay every committed insert, update, and delete somewhere else, in order. Postgres exposes that log through logical replication, MySQL through the binlog, SQL Server through change tables, Oracle through redo, and MongoDB through change streams. Nine tools lead in 2026. Filament by Galaxy, Debezium, and PeerDB are engines you run yourself. Estuary, Fivetran, and Airbyte are managed pipelines priced by gigabyte, row, or credit. AWS DMS, Striim, and Qlik Replicate are enterprise suites. The right pick depends on which logs a tool reads, how it recovers after a crash, and where it is allowed to run.

The best change data capture tools in 2026, ranked

The ranking is for the most common reader of this page, a team that reads Postgres or MySQL, lands changes in a database, warehouse, or lake, and would rather run the tool than rent it. A team on Oracle or SQL Server should read the coverage table below first.

1. Filament. A Go replication engine you run on your own hosts. It reads Postgres through pgoutput and MySQL through the binlog, and neither source carries the preview flag in the connector overview. Each Postgres table is read through the slot's exported snapshot, "so the baseline and the change stream share one consistent point," per the Postgres source docs. No meter and no Kafka. The limit is coverage, with no SQL Server, Oracle, or MongoDB source yet.

2. Debezium. The reference open source engine, with the widest source list here, including Postgres, MySQL, MariaDB, SQL Server, Oracle, MongoDB, Db2, and Cassandra, per the 3.7 connector list. Its strength is fan-out to many consumers. The cost is the stack, since you "most commonly" deploy it through Kafka Connect, per the architecture page.

3. PeerDB. A Postgres-first engine that ClickHouse acquired in July 2024. Its TOAST caching "eliminates the need of setting REPLICA IDENTITY FULL," per the docs. The limit is targets. Only ClickHouse, ClickHouse Cloud, and Postgres destinations are actively maintained, and the README lists the license as AGPLv3.

4. Estuary Flow. A managed streaming platform with log-based capture for Postgres, MySQL, SQL Server, and Oracle, per its connector list, plus MongoDB through change streams. Its claim is delivery, with "end-to-end exactly once semantics" into transactional endpoints, per the materialization docs. Pricing is $0.50 per GB plus $100 a month for each of the first six connectors, 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 log-based capture on all five major databases. It bills monthly active rows with 500,000 free, and one-minute syncs need Enterprise or Business Critical. On Postgres, its fallback is now "Query-Based" and only sees deletes with the Capture Deletes option, per the connector docs.

6. Airbyte. Open source, with connectors under the Elastic License 2.0, per its license page. Its certified sources capture Postgres, MySQL, SQL Server, and MongoDB, and Oracle needs a paid Enterprise connector. Its CDC docs say "we do not treat CDC sources as infinite streaming sources," so it drains the log on a schedule. Cloud Standard starts at $20 a month with 5 credits, per its pricing page.

7. AWS DMS. Database Migration Service reads native logs from Oracle, SQL Server, MySQL, and Postgres, per the CDC task docs, and also lists MongoDB as a source. The same CDC page says it "does not provide real-time replication." Pricing is by instance hour or serverless capacity.

8. Striim. A streaming platform whose readers capture Oracle, SQL Server, MySQL, Postgres, and MongoDB. 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 workhorse where Oracle, Db2, and Sybase sit beside SQL Server, MySQL, Postgres, and MongoDB, per its support matrix. Pricing is quote only.

Which sources does each change data capture tool support?

All nine read Postgres and MySQL. SQL Server and Oracle narrow the field to Debezium, Estuary, Fivetran, AWS DMS, Striim, and Qlik Replicate, with Airbyte adding Oracle only on its Enterprise tier.

Coverage comes from each tool's connector docs, checked on October 19, 2026. Filament's labels come from its connector overview, which flags a connector as preview until live validation confirms it is stable.

Which platforms support change data capture in modern architectures?

Filament, Debezium, Estuary, Fivetran, and Airbyte cover the common modern stack, a cloud database feeding a warehouse, a lakehouse, or a stream. They differ in the target they land in and in what sits in the middle.

• Filament writes to Postgres, Iceberg, ClickHouse, S3, and NATS JetStream, which are marked stable, and to Snowflake and Redshift, which are still in preview, per the connector overview. No Kafka sits in the path.

• Debezium fits event-driven systems where many services read one ordered feed. Debezium Server and the embedded engine drop the Kafka requirement, per the architecture page.

• Estuary fits streaming into warehouses and lakes from a managed service.

• Fivetran and Airbyte fit scheduled ELT into a warehouse.

For lakes, OLake writes Iceberg or Parquet from Postgres, MySQL, MongoDB, and SQL Server, and Google Datastream captures MySQL, Oracle, SQL Server, Postgres, and MongoDB into BigQuery, Cloud Storage, or Iceberg.

Which ETL and ELT tools support change data capture?

Fivetran, Airbyte, and Estuary are the main ELT tools with log-based change data capture, and Striim and Qlik Replicate are the ETL suites. Filament also runs extract and load with CDC on Postgres and MySQL. What separates them is the fallback when the log is not available.

Fivetran offers Teleport Sync on SQL Server, which compares row hashes between syncs with no log access, and the same method on MySQL is capped at 400 tables. Airbyte keeps cursor and xmin modes beside CDC on its Postgres source. Both fallbacks are query-based and miss hard deletes unless the tool adds a delete scan.

Which change data capture tools support SQL Server and Oracle?

Debezium, Estuary, Fivetran, AWS DMS, Striim, and Qlik Replicate all capture both. Filament and PeerDB support neither today, and Airbyte reads Oracle only through a paid Enterprise connector.

Fivetran supports Oracle 11g R2 through 21c and says LogMiner is "no longer available for new Oracle connections," per its Oracle docs. Debezium's adapters come from its Oracle connector docs, the DMS methods from its CDC task docs, and Airbyte's from its Oracle Enterprise page.

Which data integration tools offer real-time change data capture?

Debezium, Estuary, and Striim stream changes continuously. Fivetran, Airbyte, AWS DMS, and Filament deliver in scheduled or catch-up cycles, so their freshness is the interval you pay for or schedule.

Fivetran syncs every 15 minutes on Standard and every minute on Enterprise, per its pricing page. Airbyte Cloud runs hourly on Standard, every 15 minutes on Plus, and every 5 minutes on Pro, per its pricing page. AWS DMS says "there are no SLAs for CDC latency," per its CDC task docs. Filament runs each CDC pass as a bounded catch-up to the current log position, so continuous capture is a loop you put on cron or a Kubernetes job.

What are the most reliable change data capture tools?

Every tool here resumes from a saved log position after a crash, and most deliver at least once, so duplicates can follow a fault. Reliability comes down to when the position is saved and whether the target write is idempotent.

Debezium's exactly-once page states that "Debezium provides at-least-once delivery guarantees" by default. Striim's recovery docs describe both modes. Fivetran's checkpoints come from its core concepts, Airbyte's from its protocol docs, and Qlik's from its recovery guide.

Filament's runs docs state that "CDC saves its stream position only after a successful commit," and its Postgres sink docs say "Delivery is at-least-once," with merge writes that converge on the primary key. Every batch also carries a CRC32-C checksum the sink recomputes before the write, per the integrity docs.

No data loss also depends on the source. A tool can only resume if the log it needs still exists, so set slot and binlog retention to cover your longest outage.

Which change data capture platforms run in hybrid, private, or BYOC environments?

Filament, Debezium, PeerDB, Airbyte Core, Striim Platform, and Qlik Replicate all run on your own hosts. Estuary and Fivetran offer vendor-managed options inside your network on enterprise contracts.

• Filament runs on your own hosts in your own cloud, with no data passing through a vendor.

• Estuary offers private deployments and BYOC in your AWS, GCP, or Azure account, both on annual Enterprise plans, per its pricing docs.

• Fivetran offers Hybrid Deployment on Enterprise and Business Critical, per its pricing page.

• Striim sells a self-hosted Platform and a Dedicated Cloud, and Qlik sells a client-managed install for on-premises or any VM.

• AWS DMS runs only inside AWS.

What is change data capture and how does it work?

Change data capture records every change a database commits and delivers it elsewhere, in order. Log-based capture reads the database's own journal, Postgres logical replication, the MySQL binary log, Oracle LogMiner, or MongoDB change streams, so it sees every change and barely touches production. Query-based capture polls a timestamp and misses hard deletes, so this list ranks only tools that read the log. The CDC methods guide compares every approach on Postgres.

How we ranked these change data capture tools

Each tool was scored on source coverage, snapshot consistency, recovery, footprint, and cost, using its own docs, LICENSE file, and pricing page, all rechecked on October 19, 2026. Where a tool ran in the public seven-tool benchmark, 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 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 pipeline starts with.

How to run change data capture with Filament

Set wal_level=logical on Postgres, which needs a restart per the Postgres docs, grant the connector user REPLICATION, and give every selected table a primary key. Then define one pipeline. The keys follow the CLI guide and the replication modes page.

version: 1

sources:
  shop:
    type: postgres
    config:
      connection_method: url
      dsn: env:SHOP_DSN
      replication: cdc

sinks:
  analytics:
    type: postgres
    config:
      connection_method: url
      dsn: env:ANALYTICS_DSN

pipelines:
  orders-cdc:
    source:
      ref: shop
    sink:
      ref: analytics
    resources:
      - orders
      - customers
    sync_mode: cdc
    write_mode: merge

version: 1

sources:
  shop:
    type: postgres
    config:
      connection_method: url
      dsn: env:SHOP_DSN
      replication: cdc

sinks:
  analytics:
    type: postgres
    config:
      connection_method: url
      dsn: env:ANALYTICS_DSN

pipelines:
  orders-cdc:
    source:
      ref: shop
    sink:
      ref: analytics
    resources:
      - orders
      - customers
    sync_mode: cdc
    write_mode: merge

version: 1

sources:
  shop:
    type: postgres
    config:
      connection_method: url
      dsn: env:SHOP_DSN
      replication: cdc

sinks:
  analytics:
    type: postgres
    config:
      connection_method: url
      dsn: env:ANALYTICS_DSN

pipelines:
  orders-cdc:
    source:
      ref: shop
    sink:
      ref: analytics
    resources:
      - orders
      - customers
    sync_mode: cdc
    write_mode: merge

The first run creates a publication named filament, opens a slot with an exported snapshot, and copies both tables through it, splitting large tables into as many as 64 parallel ranges. Every later run is a bounded catch-up to the current WAL position, and the slot only acknowledges a position once it is durable. On MySQL, the source docs prefer GTID checkpoints, which survive replica promotion, and the binlog guide covers the server settings.

What are the common pitfalls with change data capture tools?

Four failures show up with every tool on this list.

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

• DDL does not travel through logical decoding. The restrictions page says "schema and 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 change data capture tool fits which job?

Source coverage decides first, and recovery and deployment decide the rest.

A Postgres or MySQL team that keeps data in its own network should start with Filament. Oracle, SQL Server, or a shared change bus points to Debezium, DMS, Striim, 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

• Database replication, the complete guide for 2026

• Introducing Filament

Frequently asked questions

What is a change data capture tool?

A change data capture 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.

Which change data capture tools support SQL Server and Oracle?

Debezium, Estuary, Fivetran, AWS DMS, Striim, and Qlik Replicate capture both. Airbyte reads SQL Server on its certified source and Oracle only through a paid Enterprise connector. Filament and PeerDB do not support either today. Filament's change data capture sources are Postgres and MySQL, and neither is flagged as preview.

Which change data capture tools deliver exactly once?

Estuary promises exactly-once delivery into transactional endpoints. Debezium offers exactly-once on Kafka Connect 3.3 or later and is at-least-once by default. Striim is exactly-once only on targets that support it. Filament is at-least-once, and its merge writes are idempotent on the primary key, so a replayed change converges to the same row.

Which change data capture tools can run in my own cloud?

Filament, Debezium, PeerDB, Airbyte Core, Striim Platform, and Qlik Replicate run on your own hosts. Estuary offers private and BYOC deployments on annual Enterprise plans, and Fivetran offers Hybrid Deployment on Enterprise and Business Critical. AWS DMS runs only inside AWS.

What are the best open source change data capture tools?

Debezium (Apache 2.0) is the most widely deployed and covers the most databases. Filament (Apache 2.0) handles Postgres and MySQL in one Go binary. PeerDB (AGPLv3) is Postgres-first and maintained by ClickHouse. Airbyte is open source with ELv2 connectors, and OLake (Apache 2.0) writes Iceberg.

Does change data capture require Kafka?

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

Which change data capture 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 October 2026. It has a consistent snapshot bootstrap, commit-gated checkpoints, per-batch checksums, and the fastest full load in the public cohort. Debezium fits a shared Kafka feed, and PeerDB fits a ClickHouse target.

Can change data capture tools handle schema changes automatically?

Partly. Postgres logical decoding does not carry DDL, so no tool sees an ALTER TABLE in the stream itself. 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 capture 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.