A head-to-head of the six CDC platforms teams actually evaluate — deployment, method, delivery semantics, latency, and cost — with the honest framing vendor marketing skips.
Order-of-magnitude guidance, not benchmarks — latency, cost, and feature support vary with data volume, region, and configuration. Verify against current vendor docs.
| Dimension | Debezium + Kafka Connect | AWS DMS | Fivetran | Airbyte | Oracle GoldenGate | Qlik Replicate (Attunity) |
|---|---|---|---|---|---|---|
| Deployment | Self-hosted (or managed Kafka/Connect) | AWS managed service (or DMS Serverless) | SaaS (zero infrastructure) | Self-hosted (OSS) or Airbyte Cloud | Self-hosted or OCI GoldenGate | Self-hosted (agent/server) |
| License / model | Open source (Apache-2.0) | Usage-based (AWS) | Usage-based (Monthly Active Rows) | Open source (ELv2) + managed cloud | Commercial (five-figures-per-processor list) | Commercial |
| CDC method | Log-based (WAL / binlog / redo) | Log-based (full-load + CDC) | Log-based connectors | Log-based CDC (Debezium-embedded) + connectors | Log-based (Extract → trail files → Replicat) | Log-based |
| Delivery semantics | At-least-once; dedupe on a PK-keyed sink (Kafka log compaction + idempotent consumer) | At-least-once; restarts can re-emit — upsert on PK ordered by log position at the sink | At-least-once into a landing table; the destination MERGE dedupes on PK | At-least-once; the sync writes to a landing table deduped on PK | At-least-once delivery with checkpoint-based, effectively-once apply — not end-to-end exactly-once | At-least-once; sinks apply idempotently (upsert on PK) |
| Typical latency | Sub-second | Seconds | ~1–5 min (plan-dependent) | Minutes (scheduled syncs) | Sub-minute | Seconds |
| Targets / sinks | Anything downstream of Kafka | AWS targets: S3, Redshift, Kinesis, RDS, others | Cloud warehouses: Snowflake, BigQuery, Redshift, Databricks | Warehouses, lakes, and many destinations | Heterogeneous DBs (Oracle, MySQL, PostgreSQL, SQL Server, …) | Broad source/target matrix incl. mainframe and warehouses |
| Schema evolution | Schema Registry + compatibility modes; DDL surfaced as events | Limited transforms; some DDL handled, verify per engine | Automatic schema-drift handling into the destination | Schema propagation with configurable change handling | DDL replication + transformation/mapping | DDL handling + transformation in a GUI |
| Ops burden | High — you run Kafka, Connect, and monitoring | Low–medium — managed, but tasks and monitoring are yours | Near-zero — fully hands-off | Medium self-hosted; low on Cloud | High — DBA expertise, dedicated infrastructure | Medium — GUI-driven, less hand-coding |
| Cost model | No license; infra + engineering time | Per replication-instance hour + transfer | MAR-based; grows with changed rows | Free OSS (self-run) or credit-based Cloud | Commercial licensing (verify current Oracle price list) | Commercial licensing |
Best for: Event-driven systems and streaming pipelines that want full control.
Best for: AWS-native stacks moving RDS/Aurora changes into AWS analytics targets.
Best for: Teams that want warehouse ELT with the least operational effort.
Best for: Broad-coverage ELT where connector breadth matters more than sub-second latency.
Best for: Enterprise Oracle shops needing heterogeneous or active-active replication.
Best for: Enterprises wanting broad connectivity with a low-code, GUI-first workflow.
Start from the constraint that actually binds you:
Whatever you pick, design the sink to be idempotent. The platform choice changes ops, cost, and latency — it does not remove the need to dedupe on the primary key by log position.
Track journey completion, monitor recent activity, and export your session logs.
