TL;DR: The best change data capture tools for databases in 2026 are Debezium (open-source, log-based, the industry standard for streaming CDC), Bruin (its open-source ingestr CLI reads the Postgres WAL, MySQL binlog, SQL Server and MongoDB change logs with no Kafka to run, and the SQL models and quality checks downstream live in the same pipeline), Estuary Flow (managed real-time CDC), Fivetran (managed, log-based for the databases it supports), AWS DMS (low-cost CDC inside AWS), Airbyte (CDC plus a large connector catalog), and Striim, Qlik Replicate, and Oracle GoldenGate for enterprise replication. Most teams reach for streaming CDC before they need it. The first question is not "which CDC tool" but "do I actually need log-based CDC, or is a good incremental load enough?"
Change data capture means keeping a destination in sync with a source database by moving only what changed (inserts, updates, deletes) instead of reloading the whole table. Done well, it is how you replicate a production Postgres or MySQL database into a warehouse cheaply and continuously. Done wrong, it is a Kafka cluster you did not need and an on-call rotation you did not want. This guide is about picking correctly.
Two kinds of CDC (and why the difference matters)
- Log-based CDC reads the database's write-ahead log (Postgres WAL, MySQL binlog, SQL Server transaction log). It captures every change, including deletes, in order, with minimal load on the source. This is "real" CDC and it is what you need for low-latency replication or when you cannot miss a delete. It is also more operationally involved.
- Query-based / incremental CDC periodically queries the source for rows changed since the last run, using an updated-at timestamp or an incrementing id. It is far simpler to run, it does not touch the transaction log, and it is plenty for most analytics use cases. Its weaknesses: it can miss hard deletes (unless you soft-delete) and it has latency equal to your sync interval.
A large share of teams that think they need streaming log-based CDC actually need a reliable incremental load every few minutes. Being honest about which one you need is the single biggest cost decision in this whole category.
The contenders
| Tool | CDC type | Open source | Runs as | Best for |
|---|---|---|---|---|
| Debezium | Log-based, streaming | Yes | Kafka Connect (server) | Real-time streaming CDC at scale |
| Bruin (ingestr) | Log-based (WAL, binlog, change streams), batch or streaming | CLI Apache 2.0; ingestr source-available (FSL) | CLI (no server, no Kafka) or managed cloud | Log-based CDC from one command, with the transformations and quality checks in the same pipeline |
| Estuary Flow | Log-based, streaming | Partly (managed service) | Managed cloud | Real-time CDC without running Kafka |
| Fivetran | Log-based (supported DBs) | No | Managed cloud | Zero-maintenance, will pay for it |
| AWS DMS | Log-based | No | Managed (AWS) | CDC within the AWS ecosystem, low cost |
| Airbyte | Log-based (via Debezium) | Yes (self-host) | Server + UI | Connector breadth with CDC on major DBs |
| Striim | Log-based, streaming | No | Managed cloud or self-hosted | Real-time enterprise replication from Oracle, SQL Server, and other operational databases |
| Qlik Replicate | Log-based | No | Self-hosted server + UI | Enterprise replication across many sources, including mainframe and SAP |
| Oracle GoldenGate | Log-based | No | Self-hosted or managed (OCI) | Replication when Oracle Database is the core system |
Best CDC tool by need:
- Real-time streaming CDC on Kafka: Debezium
- Log-based CDC without Kafka, with transformations and quality checks in one pipeline: Bruin (ingestr)
- Real-time streaming CDC without running Kafka: Estuary Flow
- Zero-maintenance managed CDC into a warehouse: Fivetran
- CDC inside the AWS ecosystem at low cost: AWS DMS
- Streaming CDC plus a large SaaS connector catalog: Airbyte
- Enterprise replication from Oracle: Oracle GoldenGate or Striim
- Enterprise replication across legacy sources (mainframe, SAP): Qlik Replicate
Debezium
The open-source standard for log-based streaming CDC. It reads the transaction log and emits change events, typically into Kafka. If you need genuine real-time replication and you have (or want) a streaming platform, Debezium is the reference implementation. The cost is operational: you are running Kafka Connect, managing connectors, and handling schema evolution and offsets. Powerful, and heavier than most teams expect.
Bruin (ingestr)
Bruin is the best fit when you want log-based CDC without operating Kafka. Its open-source ingestr CLI reads each database's own change log: the Postgres WAL through logical replication, the MySQL and MariaDB binlog, SQL Server CDC or Change Tracking, and MongoDB change streams. A run catches up to the current log position and exits, so it fits a schedule; add --stream to keep it running. Deletes stay in the destination, flagged with _cdc_deleted. A Bruin pipeline schedules the load next to the SQL models and quality checks that use it, so replication and everything downstream sit in one project.
ingestr ingest \
--source-uri 'postgres+cdc://user:pass@host:5432/db?publication=my_pub' \
--source-table 'public.orders' \
--dest-uri 'snowflake://...' \
--dest-table 'raw.orders'
For sources without a change log, ingestr's incremental strategies (merge on an updated_at key, append, SCD Type 2) do the same job on a schedule. If you already run Kafka and want change events on topics for many consumers, Debezium is still the natural fit. We build Bruin and ingestr, so weigh this accordingly.
Estuary Flow
Managed, real-time CDC without you standing up Kafka. It gives you log-based capture from databases into warehouses and other destinations with low latency. A good fit if you genuinely need streaming but do not want to operate the streaming infrastructure yourself.
Fivetran
Fully managed, log-based CDC for the databases it supports, with the least maintenance of anything here. You configure a connector and it keeps your warehouse in sync. The tradeoff is cost, which is usage-based and can climb with high-change-volume tables, and that it is closed and cloud-only.
AWS DMS
If you are already in AWS, DMS does log-based CDC into targets like S3, Redshift, and RDS cheaply. It is less polished than the dedicated vendors and its schema handling can be fiddly, but the price is hard to argue with inside AWS.
Airbyte
Airbyte offers CDC on major databases using Debezium under the hood, wrapped in its connector platform and UI. You get streaming CDC plus a large connector catalog, at the cost of self-hosting the Airbyte server (or paying for Airbyte Cloud).
Striim
Commercial real-time replication with log-based CDC from Oracle, SQL Server, Postgres, MySQL, and more into warehouses and Kafka. A strong fit when the source is an enterprise database and latency matters. It is sold and priced as enterprise software.
Qlik Replicate
Formerly Attunity Replicate, a long-standing enterprise CDC product with a GUI and very broad source coverage, including mainframe and SAP. It suits large IT teams with legacy sources, with enterprise pricing to match.
Oracle GoldenGate
Oracle's own log-based replication, and the default when Oracle Database is the core system. It runs self-hosted or as a managed service on OCI. Well proven, with Oracle licensing.
How to choose without over-engineering
- Do you need streaming? If no, run CDC as a scheduled catch-up (Bruin's ingestr, Fivetran, DMS) or a plain incremental load. Both are simpler and cheaper than a streaming stack.
- Do you need to capture hard deletes exactly? If yes and you cannot switch to soft deletes, you need log-based CDC (Debezium, Bruin's ingestr, Estuary, Fivetran, DMS).
- Do you want to run infrastructure? If no, rule out self-hosted Debezium and lean managed (Estuary, Fivetran, DMS) or a serverless CLI (Bruin's ingestr on a schedule).
- Are you cost-sensitive on high-change tables? Usage-priced managed CDC gets expensive on chatty tables. Open-source (Debezium, Bruin's ingestr) or DMS controls that cost.
CDC is one piece of the pipeline
Whichever CDC tool you land on, capturing changes is step one. The changes still need to be modeled into clean tables, quality-checked, and scheduled alongside the rest of your pipeline. ingestr is the ingestion layer of Bruin, an open-source platform that also handles transformation, data quality, and orchestration, so replication and everything downstream live in one place rather than in a CDC tool plus a transformation tool plus a scheduler. If you use streaming CDC, the same principle holds: keep the modeling and quality layer close to where the changes land.
For the wider ingestion landscape see our best data ingestion tools in 2026 guide, and for replicating into a specific warehouse, the guides for Snowflake, BigQuery, and Databricks.
I work at Bruin, so this is an informed but interested take. Corrections welcome at [email protected].