Best CDC Tools: 9 Platforms Compared on Price

The best CDC tool in 2026 depends on how fast your data must arrive. Estuary and Debezium stream changes in milliseconds. Erathos, Fivetran, Airbyte and Weld load complete changes on a schedule, every 1 to 15 minutes, which is enough for dashboards and reports.

This comparison covers nine tools with prices checked against each vendor's own pages in September 2026. It also includes a worked cost example for one workload and a Postgres test that shows how much disk an unread CDC slot can hold.

What is a CDC tool, and how does it capture changes?

A CDC (change data capture) tool copies only the rows that changed in a database, including inserts, updates and deletes, into another system such as a data warehouse. Most tools find those changes in one of two ways: they query the tables on a schedule, or they read the change log the database already keeps.

Query-based sync, also called cursor-based sync, is the simpler way. The tool remembers the newest value it saw in a column like updated_at, then asks the database for every row with a newer value on the next run. It is cheap and easy to set up, but it has three blind spots:

• Tables without a good timestamp column. If nothing reliably marks when a row changed, the only safe option is a full reload of the table on every run. That costs warehouse compute and may not finish in time on large tables.
• Deletes. A deleted row has no timestamp left to find. It stays in the warehouse until someone compares the full tables, so a count of active customers can still include accounts removed months ago.
• Changes between runs. If an order goes from "new" to "paid" to "refunded" between two runs, the tool only sees "refunded". That is fine for a current-state table, but it breaks any report that needs the full history.

Log-based CDC reads the log each database writes for its own crash recovery. Every insert, update and delete is an entry in that log, so a delete shows up like any other change. Each engine calls its log something different:

• PostgreSQL writes a write-ahead log (WAL). CDC tools read it through a logical replication slot, which tracks how far the reader has got.
• MySQL writes a binary log (binlog). It needs row-based logging so each entry carries the changed row, not only the SQL statement.
• SQL Server has built-in change data capture that you turn on per database and per table.
• MongoDB offers change streams, so apps can follow changes without reading the internal oplog themselves.

The open-source engine Debezium shows what this looks like in practice: after a first full copy, its Postgres connector emits an event for every row-level insert, update and delete. For a database that feeds reports people act on, log-based CDC is the method that keeps the warehouse matching the source, deleted rows included.

Do you need real-time streaming, or complete changes every few minutes?

Dashboards and reports need every change, but a delivery every few minutes is enough for them. Sub-second delivery matters when software reacts to each change, like a fraud check. The two needs differ because a CDC tool makes two separate choices. The first is how it captures changes (from the log, or with queries). The second is how often it writes them into the destination.

A log-based tool can capture changes all the time and still load them in batches. The replication slot in Postgres keeps the WAL until the reader confirms it, so a change made at 2:01 is still waiting when the next batch runs at 2:05. Nothing is lost between loads. Capturing every change is a question of data completeness, not delivery speed, and the people who read the data should decide the delivery speed.

Here is how often the main tools can land data, based on each vendor's own plan pages:

Streaming under a second has a real running cost. Debezium, for example, runs on Kafka Connect or as Debezium Server, so someone on the team has to run and watch that system. Managed streaming services cut that work, but they bill by volume or by the hour.

A simple test helps here. If nobody acts on a number within five minutes of it changing, a batch of complete changes every few minutes gives the same result as streaming at a lower cost.

How do the best CDC tools compare in 2026?

The CDC tools worth a look in 2026 split into three groups: managed platforms (Erathos, Fivetran, Airbyte Cloud, Estuary, Weld), cloud services tied to one provider (AWS DMS, Google Datastream), and open-source engines you run yourself (Debezium, dlt). They differ most on which databases they read, how often they deliver and what they charge for.

All figures below come from each vendor's own pricing or docs pages, checked in September 2026:

For PostgreSQL and MySQL, most tools in the table read the log. The choice for those two databases comes down to delivery speed, how you pay and who runs the system. For Oracle or Db2, the list gets much shorter.

Which CDC tool should you pick?

The right CDC tool depends on three things: which database you read, how fresh the data must be, and whether you want to run servers. Here is who each tool fits and where it falls short:

• Erathos fits teams on PostgreSQL or MySQL that want log-based CDC every 5 minutes at a fixed monthly price. The Pro plan costs $250/month for up to 5M rows and loads into BigQuery, Redshift, Databricks, ClickHouse, PostgreSQL, SQL Server, Supabase or S3 with Iceberg. It does not stream in under a second, and today its CDC reads only Postgres and MySQL.
• Fivetran fits companies that want one vendor for many sources and can pay for 1-minute syncs on Enterprise. Its Postgres connector can read logical replication from a read replica on PostgreSQL 16 and later, which keeps load off the main database. Costs grow with monthly active rows, so a busy table that changes all day gets expensive.
• Airbyte fits teams that want the option to self-host. Its database connectors use Debezium for CDC. Airbyte Plus syncs every 15 minutes at the fastest, and the self-managed version means your team runs the upgrades.
• Estuary fits teams that need changes in milliseconds without running Kafka. The free tier covers 10 GB a month and 2 connectors. The $100 per connector fee adds up when you have many sources and destinations.
• Weld fits teams already on its Business plan that want CDC for SQL Server or MongoDB too. CDC alone costs $479/month on top of a $959/month plan.
• AWS DMS and Google Datastream fit teams that keep everything inside one cloud. Datastream skips the charge for the first 500 GiB of backfill each month and charges nothing for an idle stream. Both mainly serve their own cloud's warehouses.
• Debezium fits engineering teams that already run Kafka and want full control for free. Version 3.6 is the latest stable release. Your team owns the servers, the monitoring and the recovery when a slot falls behind.
• dlt fits Python teams that want CDC inside their own code. The library is free. The managed dltHub platform starts at $12,000/month with a 12-month minimum.
• Kondado fits Brazilian companies that want pricing in reais and updates as often as every 5 minutes. It counts records of up to 500 bytes each and pauses integrations when you hit the plan limit.

How do CDC pricing models compare?

CDC tools charge in one of four ways: by rows, by data volume, by a flat plan with a row limit, or by the servers you run. The unit matters more than the headline price, because the same workload can look cheap on one model and expensive on another.

Here is what each model counts:

• Rows changed. Fivetran bills by monthly active rows (MAR), measured per million each calendar month. Weld also counts rows. A table where the same rows change all day costs more than one that only gets new rows.
• Data volume. Estuary charges $0.50 per GB, Airbyte uses credits tied to GB of database data, and Google Datastream charges per GiB of changes. Wide rows with big text or JSON columns cost more here.
• Flat plan with a row limit. Erathos Pro is $250/month for up to 5M rows, whatever the row size. The bill stays the same each month until you pass the limit.
• Servers you run. Debezium is free, and AWS DMS bills by the hour for the replication server. You pay for compute and storage whether data moves or not.

Take one PostgreSQL database that sends 5 million changed rows a month to one warehouse. If each row averages 1 KB, that is about 5 GB. Using each vendor's list prices, here is the monthly bill:

At this size, Estuary's free tier and Datastream are the cheapest options on paper. The picture changes as volume grows. At 50 GB a month, Estuary moves to its paid plan at 50 x $0.50 + 2 x $100 = $225. Erathos Pro stops at 5M rows, and bigger volumes move to the Enterprise plan, which covers up to 1.5 billion rows.

The flat plan is easiest to budget for. Volume pricing is cheapest for small, narrow tables. Row pricing is hardest to predict for tables that change often.

What should you set up on your database before turning on CDC?

Before any log-based CDC tool can connect, the database has to write a detailed log and keep it long enough for the tool to read it. The setup takes a few settings on each engine, and one setting on Postgres protects your disk.

On PostgreSQL, these are the settings that Erathos's Postgres guide asks for:

1. Set wal_level to logical, so the WAL records row changes a tool can decode.
2. Raise max_replication_slots and max_wal_senders so there is room for the CDC connection. These three settings need a database restart.
3. Set each table's replica identity to full. Without it, Postgres leaves the complete before and after state of a row out of the log for updates and deletes.
4. Set max_slot_wal_keep_size, which limits how much WAL one slot can hold. This one applies without a restart.

The last step matters because a slot stops Postgres from removing WAL until its reader confirms it, even when nothing is connected. We tested this on a PostgreSQL 18.6 database. We created a slot, left it unread, then inserted 200,000 rows and updated all of them. Here is the SQL for the table setup, the size limit and the check:

CREATE TABLE orders (id bigint PRIMARY KEY, status text, amount numeric(10, 2));
ALTER TABLE orders REPLICA IDENTITY FULL;

ALTER SYSTEM SET max_slot_wal_keep_size = '5GB';
SELECT pg_reload_conf();

SELECT
slot_name,
active,
wal_status,
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal
FROM pg_replication_slots;

This is what the check returned:

slot_name | active | wal_status | retained_wal
------------------+--------+------------+--------------
erathos_cdc_demo | f | reserved | 77 MB

That one batch of changes left 77 MB of WAL on disk that Postgres could not clean up. A busy production database writes far more, so a slot left unread over a weekend can fill the disk. By default the limit is -1, which lets a slot keep unlimited WAL. With a limit set, Postgres drops old WAL once a slot passes it, and the CDC connection has to copy the tables again. That costs time, but it keeps the database running.

On MySQL, the binlog needs row-based logging with full row images. The Erathos MySQL guide lists these settings for the config file:

• binlog_format = ROW, so each entry carries the changed row.
• binlog_row_image = FULL, so each entry carries every column.
• binlog_expire_logs_seconds, which sets how long MySQL keeps binlog files. MySQL keeps them for 30 days by default. If MySQL deletes a file before the CDC tool reads it, the tool has to copy the tables again.

On SQL Server, you turn on CDC with two built-in procedures, sys.sp_cdc_enable_db and then sys.sp_cdc_enable_table for each table. On MongoDB, change streams return a resume token with each change, so a reader can pick up where it stopped.

Frequently asked questions about CDC tools

What is the difference between CDC and ETL?
ETL (extract, transform, load) is the whole job of moving data into a warehouse. CDC is one way to do the extract step: it picks up only the rows that changed since the last run, instead of reading whole tables again.

Can CDC capture deleted rows?
Log-based CDC captures deletes, because a delete is an entry in the database log. Query-based sync cannot see a row that no longer exists, so deleted rows stay in the warehouse until someone reloads the table.

Does CDC slow down the production database?
Log-based CDC reads the log instead of running queries against your tables. The bigger risk is disk space. An unread Postgres slot kept 77 MB of WAL after 200,000 inserts and updates in our test, so set max_slot_wal_keep_size and watch slot size. Fivetran can also read from a Postgres 16+ read replica to keep load off the main server.

Is Debezium free?
Debezium is free and open source under the Apache 2.0 license. You still pay for the servers it runs on, usually a Kafka Connect cluster, and for the people who keep it running.

Do I need Kafka to use CDC?
No. Managed tools like Erathos, Fivetran, Airbyte Cloud and Estuary run the capture for you. Debezium Server also sends changes to other destinations without Kafka Connect.

How often does a CDC tool deliver data?
It ranges from milliseconds (Estuary, Debezium) to every minute (Fivetran Enterprise), every 5 minutes (Erathos Pro, Weld with an add-on) and every 15 minutes (Fivetran Standard, Airbyte Plus). Faster delivery usually sits on pricier plans, so the slowest speed your data's readers accept is the cheapest choice.

What is the cheapest CDC tool?
For small volumes, Estuary's free tier covers 10 GB a month with 2 connectors, and Fivetran's free plan covers 500,000 monthly active rows. Debezium has no license fee but needs servers and engineers. For a fixed bill, Erathos Pro costs $250/month for up to 5M rows with CDC every 5 minutes.

Does Erathos support CDC?
Yes. Erathos reads the PostgreSQL WAL and the MySQL binlog on the Pro and Enterprise plans, and delivers changes every 5 minutes on Pro. It can start with a full copy of your tables or only stream new changes.

Try Erathos free for 14 days

Erathos gives you log-based CDC from PostgreSQL and MySQL into your warehouse every 5 minutes, with a fixed monthly price and no servers to run. Start your 14-day free trial of Erathos and connect your first database today.