Best Change Data Capture (CDC) Tools in 2026: Log-Based, Managed, and Open-Source Compared

Why most CDC comparisons get it wrong

Most lists of CDC tools treat log-based CDC and incremental sync as if they are interchangeable options on a spectrum. They are not. They are fundamentally different approaches with different latency profiles, source database requirements, and failure modes. Choosing the wrong category does not mean picking a slightly slower tool, it means building the wrong kind of pipeline entirely.

This guide makes that distinction the organizing principle. The nine tools below are grouped by what they actually do, evaluated on criteria that matter in production, and compared honestly including their real limitations and pricing realities. If you have already read three articles on this topic and felt like you were reading the same list with different logos, this one is different.

One important note on framing: CDC is a technique, not a product category. Some tools on this list are pure CDC engines. Others are broader data integration platforms that use CDC as one of several ingestion modes. Knowing which is which prevents a lot of architectural mistakes downstream.

What is Change Data Capture (CDC)?

Change Data Capture is the process of identifying row-level changes in a source database -- inserts, updates, and deletes -- and propagating them to downstream systems without copying the entire table on every run.

The alternative is full table extraction: read everything, compare with the last snapshot, figure out what changed. That approach works until it doesn't, usually around the point where your tables hit a few hundred million rows and your batch window starts eating into business hours.

CDC solves this by reading what actually changed, not inferring it after the fact. In log-based CDC, the gold standard -- the tool reads the database transaction log directly. Every committed transaction is already recorded there. The CDC engine replays those events to downstream systems, often within milliseconds of the original commit.

The three CDC methods compared

When trigger-based CDC makes sense: it is mostly useful for legacy databases that do not expose transaction logs to external tools. The operational overhead is significant (triggers fire on every write, creating additional load) and you should migrate away from it as soon as the underlying database supports log access.

Why teams switch to CDC (and what they give up with batch)

The honest version of this section is not just a list of benefits. Teams switch to CDC because batch pipelines have broken something important to them. Here are the real scenarios:

• Data freshness failures: a nightly ETL job means your analytics dashboard is always showing yesterday. Your fraud model is scoring transactions against 24-hour-old feature data. CDC closes that window to seconds.
• Database load problems: full table scans to detect changes hammer production databases, especially during business hours. Log-based CDC generally creates less source load than repeated full-table scans, although log reading and retention still consume database resources.
• Scale breaking batch windows: a 4-hour ETL job that worked fine on 10GB tables breaks when the table hits 500GB. Steady-state CDC processing depends primarily on change volume rather than total table size, although initial snapshots and backfills still scale with table size.
• Event-driven architecture adoption: teams building microservices or streaming analytics need a reliable change event stream, not a scheduled file. CDC is the standard way to turn a relational database into an event source.

What you give up: CDC is harder to operate than batch. You need to think about WAL retention limits, replication slot management, schema evolution, and delivery guarantees. The tools in this list handle varying amounts of that complexity for you, which is a core factor in the evaluation below.

How we evaluated these tools

The criteria below reflect what actually determines whether a CDC pipeline stays healthy in production. For Estuary, these come from direct production experience. For other tools, they are drawn from G2 user reviews, Gartner Peer Insights, official documentation, and practitioner feedback on r/dataengineering.

• CDC method accuracy: log-based CDC is the standard for real-time pipelines. Tools using incremental queries are noted clearly because the behavior difference is significant.
• End-to-end latency: measured from source commit to destination write, not just pipeline throughput. Sub-second, seconds, and minutes are meaningfully different for downstream use cases.
• Delivery guarantees: at-least-once delivery is the minimum. Exactly-once semantics matter for financial data, audit logs, and anything where duplicate processing has consequences.
• Operational complexity: how much do you need to know to keep it running? Kafka cluster management, connector offsets, and schema evolution are all real operational costs.
• Connector depth, not just count: a tool that lists 500 connectors but has shallow CDC support for your specific database version is worse than a tool with 20 connectors that are deeply tested.
• Pricing transparency: CDC tools that hide pricing behind sales calls are noted. Pricing that scales predictably with data volume is differentiated from pricing that can spike unexpectedly.
• Schema evolution handling: what happens when an upstream team adds a column, renames a field, or drops a table? Pipelines that break silently on DDL changes are a production risk.

The best CDC tools in 2026: tool-by-tool breakdown

1. Estuary

Best for: Teams that need real-time CDC, historical backfills, streaming transformations, and batch data movement without operating Kafka infrastructure

CDC method: Log-based CDC for supported databases; incremental and batch ingestion for other sources | Latency: Sub-second for supported real-time pipelines; configurable for scheduled delivery | Deployment: Public SaaS, Private Deployment, or Bring Your Own Cloud

Estuary is a managed data movement platform that combines real-time CDC, streaming, and batch ingestion in one system.

It captures source data into persistent datasets called collections. These collections can feed multiple destinations, transformations, or applications without extracting the same data from the source again.

This architecture allows teams to use one pipeline for the initial historical backfill and ongoing real-time changes instead of maintaining separate batch and streaming systems.

CDC and delivery architecture

Estuary uses log-based CDC to capture inserts, updates, and deletes from supported databases, including PostgreSQL, MySQL, MongoDB, SQL Server, and Oracle.

When a CDC pipeline starts, Estuary performs an initial backfill of the selected source data and then transitions to continuously capturing new changes from the database log.

Captured records are written to durable collections before being delivered to downstream systems. A collection can supply multiple materializations, allowing the same source data to be delivered to warehouses, databases, search systems, event platforms, and cloud storage.

Materializations continuously read collections and update destination resources. For transactional destinations, Estuary can commit destination updates and processing checkpoints together to provide exactly-once processing. Delivery behavior can vary for non-transactional destinations such as webhooks and messaging systems.

Estuary also supports real-time transformations using SQL and TypeScript. Teams can filter, join, aggregate, enrich, or restructure data before delivering it downstream.

Where Estuary fits

Estuary is a good fit when:

• You need continuously updated data rather than scheduled replication jobs.
• You want to combine historical backfills and ongoing CDC in the same pipeline.
• You need to deliver one source dataset to multiple destinations.
• You want real-time transformations without operating a separate stream processor.
• You need log-based CDC without managing Kafka, Kafka Connect, or connector offsets.
• You require Private or BYOC deployment for networking, residency, or compliance requirements.
• You want the option to configure slower delivery intervals for destinations where continuous loading would increase compute costs.

Estuary provides more than 200 source and destination connectors, covering databases, SaaS applications, cloud storage, data warehouses, event systems, and APIs.

Schema handling

Estuary detects changes to source schemas through its connector discovery process. AutoDiscover and schema evolution workflows can update collections and connected data flows when new fields or resources appear.

Additive changes can often be incorporated without rebuilding the entire pipeline. Breaking changes, such as incompatible data-type changes, renamed fields, or removed fields, may require review and an explicit schema evolution.

Pricing model

Estuary uses a combination of data-volume and connector-instance pricing.

Published pricing includes:

• Data movement: $0.50 per GB processed into or out of Estuary.
• Connector instances: The first six active connector instances cost $100 per month each, prorated by task hour. Additional connector instances cost $50 per month each.
• Free tier: Up to two connector instances and 10 GB of data movement per month.
• Private and BYOC deployments: Require an annual agreement and additional deployment fees.

Teams should estimate costs using both data volume and the total number of active source and destination connector instances.

Honest limitations

• Estuary’s 200-plus connector catalog is smaller than the catalogs offered by Fivetran and Airbyte. Connector availability should be confirmed for less common sources.
• Private and BYOC deployments require a commercial license, additional setup, and an annual plan.
• Log-based CDC requires database configuration and permissions, such as PostgreSQL logical replication or MySQL binary logging.
• Collections, captures, materializations, and derivations introduce concepts that teams accustomed to traditional job-based ETL may need time to learn.
• Estuary is not a general-purpose message broker for arbitrary application events. Kafka or another event platform may still be appropriate for broader messaging requirements.

2. Debezium

Best for: Engineering teams that want open-source, low-latency CDC with full control over infrastructure and change events

CDC method: Transaction-log and native change-stream capture | Latency: Typically sub-second to seconds | Deployment: Self-managed through Kafka Connect, Debezium Server, Debezium Engine, or the incubating Debezium Platform

Debezium is an open-source CDC platform that converts committed database inserts, updates, and deletes into structured change events.

It supports PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, MongoDB, Db2, Cassandra, and Google Cloud Spanner, with additional incubating connectors.

Debezium usually performs an initial snapshot of selected tables and then continuously reads changes from the database log. Events include operation type, before-and-after values, timestamps, and source-log positions.

Where Debezium fits

Debezium is a good fit when:

• Kafka and Kafka Connect are already part of your infrastructure.
• Multiple applications need to consume the same database changes.
• You need complete control over event formats, retention, and processing.
• You are building event-driven services or implementing the transactional outbox pattern.
• Your team can operate and monitor CDC infrastructure.

Kafka Connect is Debezium’s most common deployment model, but Kafka is not mandatory. Debezium Server can send changes to systems such as Amazon Kinesis, Google Cloud Pub/Sub, Apache Pulsar, Redis Streams, and NATS JetStream.

Pricing model

Debezium is free and open source under the Apache License 2.0.

There are no Debezium licensing or usage charges. However, teams must account for:

• Kafka, Kafka Connect, or alternative messaging infrastructure.
• Compute, storage, networking, and topic retention.
• Schema registry and monitoring infrastructure.
• Database and connector configuration.
• Engineering time for upgrades, scaling, incident response, and recovery testing.

For teams that already operate Kafka, these costs may fit naturally into the existing platform. For teams introducing Kafka primarily for CDC, infrastructure and operational costs can be significant.

Honest limitations

• Debezium is a CDC engine, not a fully managed data integration platform.
• Teams must operate Kafka Connect, Debezium Server, or an embedded Debezium Engine.
• Delivering changes into warehouses may require separate sink connectors or custom consumers.
• Delivery is at least once by default, so duplicate events are possible during recovery.
• Database logs, PostgreSQL replication slots, connector offsets, and schema changes require monitoring.
• The software is free, but infrastructure and engineering costs can be significant.

3. Fivetran

Best for: Organizations that prioritize broad connector coverage, managed data movement, automated schema handling, and enterprise governance

CDC method: Log-based or native change capture for supported databases; query-based and incremental extraction for other sources; HVA and HVR options for high-volume replication | Latency: Seconds to scheduled minutes, depending on the connector and destination | Deployment: SaaS, Hybrid Deployment, or self-hosted HVR

Fivetran is a managed data movement platform with more than 700 connectors spanning databases, SaaS applications, ERP systems, files, events, and cloud services.

Its main strength is operational simplicity. Fivetran manages connector maintenance, extraction, destination loading, schema updates, retries, and monitoring. This makes it a strong option for organizations that need to centralize data from many different systems without maintaining custom pipelines.

CDC approach

Fivetran’s change capture method depends on the source connector. Supported database connectors can use transaction logs or native database change mechanisms. For example, MySQL can read binary logs, while PostgreSQL supports logical replication.

Some database connectors also provide query-based or snapshot-comparison methods when transaction-log access is unavailable. SaaS and application connectors generally retrieve incremental changes through source APIs rather than database CDC.

For demanding database workloads, Fivetran offers High-Volume Agent connectors. These connectors are designed for high-volume database replication and are available with Fivetran’s SaaS and Hybrid deployment models.

Fivetran HVR is the self-hosted option for enterprise database and file replication. It supports continuous log-based change capture and provides more control over where replication components run.

Where Fivetran fits

Fivetran is a good fit when:

• You need to integrate a large mix of databases, SaaS applications, files, and enterprise systems.
• You want a managed platform that handles connector maintenance and source API changes.
• You need log-based CDC from supported production databases without operating Kafka.
• You want configurable schema change handling for new schemas, tables, and columns.
• You need high-volume database replication through HVA or a self-hosted deployment through HVR.
• Security, access controls, private networking, and centralized governance are important requirements.

Fivetran also supports soft-delete and history modes. Soft-delete mode maintains the current state of a source table, while History Mode preserves previous versions of changed records using a slowly changing dimension structure.

Pricing model

Fivetran uses a Monthly Active Rows pricing model. MAR measures the number of unique rows inserted, updated, or deleted during a calendar month.

A row that changes several times within the same table during the month is generally counted once. However, costs can increase when pipelines affect large numbers of unique rows, replicate data through multiple connections, or use many high-volume sources.

Teams should evaluate pricing using representative production data and monitor MAR at the table and connection levels.

Honest limitations

• The full connector catalog should not be interpreted as 700 log-based CDC connectors. Many SaaS, file, and application connectors use scheduled incremental extraction.
• End-to-end latency varies by connector, configured sync frequency, destination, and deployment model.
• Fivetran’s standard managed connectors are designed primarily to load data into warehouses, lakes, and databases rather than publish a general-purpose event stream for multiple consumers.
• MAR-based costs can grow when a large number of unique rows change each month.
• HVA connectors require eligible enterprise plans, while self-hosted HVR introduces additional infrastructure and operational responsibilities.
• Log-based database connectors may require DBA assistance to configure replication permissions, transaction logs, network access, and log-retention settings.

4. Qlik Replicate

Best for: enterprises running high-volume, mission-critical replication across heterogeneous database environments including mainframes, SAP, and Oracle

CDC method: Log-based  |  Latency: Seconds  |  Deployment: Self-managed Qlik Replicate; managed replication available through Qlik Talend Cloud

Qlik Replicate (formerly Attunity Replicate) is one of the oldest and most battle-tested enterprise CDC platforms available. It was built from the ground up for the specific problem of replicating data across different database technologies at high volume, with the operational reliability requirements of a Fortune 500 data center.

Where Qlik Replicate differentiates itself is in the breadth of legacy and enterprise source support. It handles mainframe sources (IBM Db2 for z/OS, IMS), SAP applications (via HANA and ABAP and other extraction methods), and legacy enterprise databases that other tools often struggle with. If your organization has a heterogeneous mix of enterprise systems built up over decades, Qlik Replicate is worth evaluating seriously.

Where it fits

• Large-scale Oracle, SQL Server, DB2, and SAP replication where you need very high throughput and proven enterprise support
• Regulated industries (banking, healthcare, insurance) where the tool's audit trail, change logging, and support history matter for compliance
• Organizations already in the Qlik ecosystem that want a CDC solution integrated with Qlik's broader data management and analytics platform

Honest limitations

• Commercial pricing is not publicly disclosed; expect enterprise-level costs
• Limited built-in transformation capabilities; complex data reshaping happens downstream
• Heavier to set up and operate than modern SaaS CDC platforms; benefits from experienced DBA involvement
• Less suited for teams that need rapid iteration or self-service pipeline creation

5. Oracle GoldenGate (OCI GoldenGate)

Best for: large enterprises running Oracle database environments who need mission-critical CDC with high availability and disaster recovery support

CDC method: Log-based (redo logs)  |  Latency: Seconds  |  Deployment: Managed (OCI) or self-hosted

GoldenGate has been doing log-based database replication longer than most of the other tools on this list have existed. It was the standard for Oracle-to-Oracle replication in large enterprises through the 2000s and 2010s, and OCI GoldenGate extends that to a managed cloud service with broader database support.

The tool's core strength is in scenarios where data correctness and uptime are non-negotiable. Active-active replication (both source and target accept writes and stay in sync), bidirectional sync, and near-zero downtime migrations are all production-tested capabilities. The complexity of setting these up is high, but for organizations that genuinely need them, there is no cleaner solution.

The Oracle-centricity trade-off

GoldenGate works best when Oracle is either the source or the target. The non-Oracle connectors (MySQL, PostgreSQL, SQL Server) work but have historically received less investment and testing depth than the Oracle-to-Oracle path. If you are not running Oracle databases, start with a different tool.

Honest limitations

• Among the highest licensing costs in the CDC market; typically requires an Oracle support contract alongside the GoldenGate license
• Requires experienced Oracle DBAs to configure and maintain; not self-service
• The best capabilities are Oracle-to-Oracle; non-Oracle use cases have more rough edges
• Modern SaaS CDC tools have narrowed GoldenGate's advantage significantly for teams not already invested in the Oracle ecosystem

6. Striim

Best for: enterprises that need CDC and real-time stream processing in a single runtime, without assembling a separate Flink or Spark cluster for in-flight transformations

CDC method: Log-based + streaming  |  Latency: Sub-second to seconds  |  Deployment: Managed cloud or self-hosted

Striim was founded by several engineers who worked on Oracle GoldenGate, and that heritage shows. The CDC capture engine is mature and reliable. What differentiates Striim from pure CDC tools is the built-in stream processing layer: you can filter rows before they reach the destination, join multiple change streams, enrich events with reference data lookups, and aggregate in-flight -- all within Striim, without routing the data through a separate Flink or Spark job.

This integration has real value for teams building operational analytics or event-driven architectures where you need to transform data close to the source before it lands in a warehouse or a downstream system. The alternative -- raw CDC into Kafka, then Flink for processing, then a sink to the destination -- involves three separate systems with three separate failure modes.

Where Striim fits and where it does not

Striim is a strong fit when transformations are complex and latency-sensitive. If your CDC pipeline is mostly "replicate these tables as-is to Snowflake", Striim's processing layer adds cost without adding value. Use a simpler managed CDC tool for that pattern.

Honest limitations

• Commercial pricing; costs are not publicly listed and scale with data volume and feature usage
• Striim's SQL-based streaming query language has a learning curve, particularly for teams coming from batch ETL backgrounds
• Historical reprocessing is less flexible than on platforms designed around event log replay
• Self-hosted deployments require JVM-based infrastructure management

7. AWS Database Migration Service (DMS)

Best for: AWS-native teams that want managed CDC without running Kafka, primarily for database migrations or ongoing replication into AWS analytics services

CDC method: Log-based  |  Latency: Seconds to minutes  |  Deployment: Managed AWS service using provisioned replication instances or AWS DMS Serverless

AWS DMS is the path of least resistance for CDC within an AWS-first architecture. It captures changes from database transaction logs and delivers them to Amazon Redshift, S3, RDS databases, DynamoDB, Kinesis Data Streams, and other supported targets.

The setup experience is genuinely simple for standard use cases. If you are replicating a MySQL RDS instance to Redshift, you can have a working CDC pipeline in an afternoon. AWS handles the instance management, failover, and upgrades.

The limitations that matter in practice

AWS DMS is a replication tool, not a data integration platform. It does not support complex transformations during replication. The latency on some source/target combinations can drift into the minutes range during high-volume periods. And the tool is firmly tied to AWS -- if you have data sources on-premises or in another cloud, the integration path is more complex.

A pattern worth noting: AWS DMS works well as a bridge into Kinesis Data Streams, where you can then use more capable stream processing (Kinesis Analytics or Flink on EMR) for transformations before landing in Redshift or S3. This is often a better architecture than relying on DMS alone for complex pipelines.

Honest limitations

• Primarily AWS ecosystem only; multi-cloud or on-prem-first architectures are awkward
• Latency can degrade under high load; DMS instances need to be right-sized for your change rate
• Limited transformation capabilities -- designed for replication, not enrichment or reshaping
• Pricing is based on replication-instance usage for AWS DMS Standard or DMS Capacity Unit usage for DMS Serverless, with additional storage and data-transfer costs where applicable.

8. Airbyte

Best for: Teams that want broad connector coverage, open-source flexibility, custom connector development, and a choice between managed and self-hosted deployment

CDC method: Log-based CDC for supported databases; cursor-based incremental extraction and full refresh for other sources | Latency: Scheduled, typically minutes to hours depending on the plan and configuration | Deployment: Airbyte Cloud, Enterprise Flex, open-source Core, or Self-Managed Enterprise

Airbyte is an open-source data replication platform with more than 600 source and destination connectors. Its catalog covers databases, SaaS applications, APIs, files, data warehouses, and data lakes.

Most Airbyte connectors are open source, allowing teams to inspect, modify, or extend their behavior. Airbyte also provides a no-code Connector Builder and development kits for creating integrations that are not available in the existing catalog.

CDC approach

Airbyte provides log-based CDC for PostgreSQL, MySQL, Microsoft SQL Server, MongoDB, Oracle, SAP HANA, and IBM Db2.

The exact capture mechanism depends on the database. PostgreSQL reads changes from the write-ahead log, MySQL uses the binary log, SQL Server uses its CDC feature, and MongoDB uses change streams. Several relational database connectors use Debezium internally to read and track database changes.

The first CDC sync creates a snapshot of the selected tables. Subsequent syncs read inserts, updates, and deletes from the saved transaction-log position.

Airbyte runs CDC through scheduled synchronization jobs. Each job reads the changes accumulated since the previous sync. It does not treat database CDC connections as continuously running event streams.

For SaaS applications and APIs, Airbyte typically uses cursor-based incremental extraction. These connectors request records created or modified after the cursor saved during the previous sync.

Where Airbyte fits

Airbyte is a good fit when:

• You need to connect a broad mix of databases, SaaS applications, APIs, files, and data warehouses.
• You want access to open-source connector code and the ability to customize it.
• You need log-based CDC from one of Airbyte’s supported database sources.
• Scheduled data delivery is sufficient for analytics and warehouse workloads.
• You want to build a missing integration using Airbyte’s Connector Builder or CDKs.
• You need a choice between managed cloud, hybrid, and self-managed deployment.
• Your team wants database CDC without maintaining a separate Kafka cluster.

Airbyte offers several sync modes, including full refresh, incremental append, and incremental append with deduplication. This allows teams to choose whether the destination should preserve every incoming version or maintain the latest version of each record.

Deployment options

Airbyte provides multiple deployment models:

• Airbyte Cloud: A managed service where Airbyte operates the control plane and replication infrastructure.
• Enterprise Flex: A hybrid model with a managed control plane and data planes running inside the customer’s infrastructure.
• Airbyte Core: The free, open-source version that teams deploy and operate themselves.
• Self-Managed Enterprise: A commercial self-hosted edition with governance, security, access control, and enterprise support features.

Pricing model

Airbyte Core is free and open source, but teams are responsible for infrastructure, upgrades, monitoring, and operational support.

Airbyte Cloud uses usage-based credits for its standard plans. Database and file replication is generally measured by data volume, while API and custom-source usage is measured by rows processed. Higher cloud and enterprise plans may use committed data-worker capacity.

Actual costs depend on source type, data volume, sync frequency, and the number of concurrent replication jobs.

Honest limitations

• Airbyte CDC is schedule-driven rather than continuously streaming. Data freshness depends on sync frequency and job duration.
• Most of Airbyte’s 600-plus connectors are not log-based CDC connectors. SaaS, API, and file connectors generally use incremental or full-refresh extraction.
• CDC requires primary keys for incremental replication on most supported database sources. Tables without primary keys may require full refresh.
• CDC captures row-level INSERT, UPDATE, and DELETE operations. Operations such as TRUNCATE and ALTER are not delivered as change records.
• New CDC tables or columns may require schema approval, a stream refresh, and a new snapshot before replication begins.
• Connector support levels vary. Airbyte-maintained connectors generally receive stronger testing and support than community or marketplace connectors.
• Operating Airbyte Core or Self-Managed Enterprise requires Kubernetes infrastructure, upgrades, monitoring, scaling, and connector maintenance.
• Teams must monitor transaction-log retention, PostgreSQL replication slots, sync failures, and stored CDC offsets to prevent log growth or required resyncs.

9. Skyvia

Best for: Teams that want no-code, managed replication across databases, SaaS applications, data warehouses, and files

CDC method: Log-based ingestion for SQL Server; timestamp or auto-increment-based incremental replication for other supported databases | Latency: Schedule-dependent | Deployment: Fully managed SaaS

Skyvia is a fully managed, no-code data integration platform supporting more than 200 databases, cloud applications, data warehouses, and file sources. It provides replication, ETL, synchronization, and other integration capabilities through a visual interface.

Skyvia is particularly useful for small and mid-sized teams that want to move and synchronize data without building or maintaining pipeline infrastructure.

The CDC distinction

Skyvia supports three database replication ingestion modes:

• New: Replicates newly added records using a datetime or auto-incrementing column.
• New and modified: Replicates records inserted or updated since the previous run.
• Log-Based: Uses database change-tracking and logging capabilities to identify inserted, updated, and deleted records.

As of July 2026, Skyvia’s Log-Based ingestion mode is available for SQL Server. For other supported database sources, incremental replication may use datetime or auto-incrementing columns to identify changed records.

Where Skyvia fits

Skyvia is a good fit when:

• You want no-code replication with minimal infrastructure and engineering overhead.
• You need to integrate databases, SaaS applications, data warehouses, and files through one managed platform.
• You are replicating SQL Server data and want a log-based ingestion option.
• Scheduled data freshness is sufficient for analytics, reporting, or operational synchronization.
• Ease of setup and managed operation are more important than controlling the underlying CDC infrastructure.

Honest limitations

• Log-Based ingestion is currently limited to SQL Server. Other supported database replication paths may depend on datetime or auto-incrementing fields.
• The New and New and modified ingestion modes do not detect deleted database records.
• Source schema changes are not detected automatically. Users must refresh the source metadata and edit the replication when source objects or fields change.
• Replication latency depends on the configured schedule, making Skyvia less suitable for sub-second streaming or workloads requiring continuously emitted change events.
• Teams requiring broad log-based CDC coverage across several database engines, advanced stream processing, or detailed control over delivery behavior may need a more specialized CDC platform.

Full comparison: 9 CDC tools side by side

How to choose the right CDC tool for your stack

The comparison table above tells you what each tool does. This section tells you which one to pick based on your actual situation.

Step 1: Determine whether you need true log-based CDC

Ask your DBA whether your source database exposes its transaction log to external tools. For Postgres, this means logical replication must be enabled (wal_level = logical). For MySQL, binary logging must be on (log_bin = ON). For Oracle, you need Supplemental Logging enabled and either LogMiner access or XStream configured.

If log access is available and your use case requires low latency, delete capture, or high-volume replication, log-based CDC is usually the preferred option. If it is not available and cannot be enabled (common in managed database services with restricted configurations or in legacy environments), then incremental sync tools or trigger-based approaches are your fallback options.

Step 2: Decide on managed versus self-hosted

Self-hosted CDC (Debezium) gives you full control and no ongoing licensing costs, but requires engineering bandwidth to operate. Managed CDC (Estuary, Fivetran, AWS DMS, Skyvia) trades control for operational simplicity. The right answer depends on your team's capacity, not on which approach is theoretically better.

A practical heuristic: if your team does not already run Kafka, starting with a managed CDC platform is almost always the right call. The operational complexity of running Kafka for the first time while simultaneously building CDC pipelines is a significant distraction from actually solving the business problem.

Step 3: Match the tool to your latency requirement

Be specific about what "real-time" means for your use case. Sub-second latency is necessary for fraud detection, live inventory systems, and operational analytics dashboards that business users refresh continuously. Seconds-range latency is fine for most analytics pipelines feeding overnight reporting. Minutes-range is acceptable for data warehouse syncs where dbt runs on an hourly schedule anyway.

Over-engineering on latency is expensive. Do not pay for sub-second CDC infrastructure if your downstream consumers check for new data every five minutes.

Quick decision guide

Getting CDC right: the configuration details that matter

These are the things that trip up most teams in their first production CDC deployment, regardless of which tool they use.

Postgres: wal_level and replication slots

Set  wal_level = logical  in postgresql.conf before enabling CDC. On managed Postgres services (RDS, Cloud SQL, Aurora), this is a parameter group setting that usually requires an instance restart.

Every CDC tool that connects to Postgres creates a replication slot. Monitor  pg_replication_slots  and  pg_stat_replication  regularly. An inactive slot will hold WAL files indefinitely. If your CDC consumer goes offline for an extended period and you do not clean up the slot, you risk filling the disk on your Postgres primary.

MySQL: binary logging and row format

Ensure  log_bin = ON  and  binlog_format = ROW  in your MySQL configuration. Statement-based and mixed-format binary logs do not support CDC reliably because they do not record the actual row values for all statement types.

Set  binlog_row_image = FULL  so that both the before and after image of every changed row is included in the binary log. Without this, you will only get the changed columns, which makes it difficult to maintain the correct state at the destination.

Schema evolution: plan for it, do not react to it

Schema changes are the most common cause of silent CDC pipeline failures. Adding a nullable column is usually fine. Renaming a column, changing a data type, or dropping a column can break downstream consumers that do not handle schema evolution gracefully.

Before choosing a CDC tool, test your specific schema evolution scenarios against it. Specifically: add a column to a source table with CDC running and verify that the destination handles it correctly without manual intervention. Most managed tools handle this; many self-managed setups require explicit handling.

Delivery guarantees and destination idempotency

Log-based CDC tools deliver at-least-once by default, meaning duplicate events are possible during failure recovery and restarts. If your destination is a data warehouse loading via MERGE/UPSERT, duplicates are handled. If your destination is a queue or a system that processes events with side effects, you need to implement idempotency at the consumer.

Exactly-once delivery (end-to-end) is technically harder and most tools either do not offer it or offer it only for specific source-destination combinations. Understand what your chosen tool guarantees before assuming duplicates cannot happen.

CDC troubleshooting: common problems and fixes

Conclusion

Choosing among change data capture tools comes down to three variables: whether you need true log-based capture, how much operational complexity your team can absorb, and which sources and destinations you need to connect.

For teams that want to move quickly without managing streaming infrastructure, Estuary covers common CDC use cases, including log-based capture from major databases into cloud warehouses and data lakes. Its free tier also makes it practical to validate a pipeline before committing to production.

For teams already running Kafka and wanting full control over their infrastructure, Debezium remains a strong open-source choice. Organizations with large Oracle estates may prefer Oracle GoldenGate, while teams needing broad enterprise and SAP-oriented replication support may find Qlik Replicate a better fit.

Whatever you choose, test failure and recovery scenarios before going to production. The tool that looks simplest in a demo is not always the one that remains reliable at 3 a.m., when a connector loses its position, a destination falls behind, or an inactive PostgreSQL replication slot causes WAL to accumulate.

Try Estuary for free

Build a real-time CDC pipeline from your database to Snowflake, BigQuery, Redshift, and other destinations in minutes, without managing Kafka or streaming infrastructure.

Start free

Related reading

• Why you should reconsider Debezium: challenges and alternatives
• Log-based CDC vs traditional ETL: a practical comparison
• The complete CDC guide for PostgreSQL
• Change Data Capture landscape and architecture patterns
• 13 data ingestion tools in 2026 compared