Melhores plataformas de CDC (Change Data Capture) para integração de bancos de dados em tempo real

A melhor ferramenta de CDC em 2026 depende da rapidez com que seus dados precisam chegar. Estuary e Debezium transmitem as mudanças em milissegundos. Erathos, Fivetran, Airbyte e Weld carregam as mudanças completas em intervalos programados, a cada 1 a 15 minutos, o que é suficiente para dashboards e relatórios.

Esta comparação cobre nove ferramentas, com preços conferidos nas páginas de cada fornecedor em setembro de 2026. Ela também traz um exemplo de custo calculado para uma carga de trabalho e um teste no Postgres que mostra quanto disco um slot de CDC não lido pode ocupar.

O que é uma ferramenta de CDC e como ela captura as mudanças?

Uma ferramenta de CDC (change data capture, ou captura de dados alterados) copia apenas as linhas que mudaram em um banco de dados, incluindo inserts, updates e deletes, para outro sistema, como um data warehouse. A maioria das ferramentas encontra essas mudanças de uma de duas formas: consultando as tabelas em intervalos programados ou lendo o log de mudanças que o banco já mantém.

A sincronização baseada em consultas, também chamada de sincronização por cursor, é o caminho mais simples. A ferramenta guarda o valor mais recente que viu em uma coluna como updated_at e, na execução seguinte, pede ao banco todas as linhas com um valor mais novo. É barata e fácil de configurar, mas tem três pontos cegos:

• Tabelas sem uma boa coluna de timestamp. Se nada marca de forma confiável quando uma linha mudou, a única opção segura é recarregar a tabela inteira a cada execução. Isso consome processamento do warehouse e pode não terminar a tempo em tabelas grandes.
• Deletes. Uma linha apagada não deixa timestamp para ser encontrado. Ela continua no warehouse até alguém comparar as tabelas completas, então uma contagem de clientes ativos pode ainda incluir contas removidas há meses.
• Mudanças entre execuções. Se um pedido passa de "novo" para "pago" e depois para "reembolsado" entre duas execuções, a ferramenta só vê "reembolsado". Isso funciona para uma tabela de estado atual, mas quebra qualquer relatório que precise do histórico completo.

O CDC baseado em log lê o log que cada banco grava para sua própria recuperação após falhas. Todo insert, update e delete é uma entrada nesse log, então um delete aparece como qualquer outra mudança. Cada engine chama seu log de um jeito:

• PostgreSQL grava um write-ahead log (WAL). As ferramentas de CDC o leem por meio de um slot de replicação lógica, que registra até onde o leitor já chegou.
• MySQL grava um binary log (binlog). Ele precisa de log baseado em linhas, para que cada entrada traga a linha alterada e não apenas o comando SQL.
• SQL Server tem change data capture nativo, que você ativa por banco e por tabela.
• MongoDB oferece change streams, para que as aplicações acompanhem as mudanças sem ler o oplog interno diretamente.

A engine open source Debezium mostra como isso funciona na prática: depois de uma primeira cópia completa, seu conector de Postgres emite um evento para cada insert, update e delete no nível da linha. Para um banco que alimenta relatórios usados em decisões, o CDC baseado em log é o método que mantém o warehouse igual à origem, incluindo as linhas apagadas.

Você precisa de streaming em tempo real ou de mudanças completas a cada poucos minutos?

Dashboards e relatórios precisam de todas as mudanças, mas uma entrega a cada poucos minutos basta para eles. Entrega em menos de um segundo importa quando um software reage a cada mudança, como uma checagem de fraude. As duas necessidades são diferentes porque uma ferramenta de CDC faz duas escolhas separadas. A primeira é como ela captura as mudanças (pelo log ou por consultas). A segunda é com que frequência ela grava essas mudanças no destino.

Uma ferramenta baseada em log pode capturar mudanças o tempo todo e ainda assim carregá-las em lotes. O slot de replicação no Postgres mantém o WAL até o leitor confirmar a leitura, então uma mudança feita às 2:01 ainda está esperando quando o próximo lote roda às 2:05. Nada se perde entre as cargas. Capturar todas as mudanças é uma questão de completude dos dados, não de velocidade de entrega, e quem consome os dados é quem deve decidir a velocidade de entrega.

Veja com que frequência as principais ferramentas conseguem entregar os dados, segundo as páginas de planos de cada fornecedor:

Streaming em menos de um segundo tem um custo real de operação. O Debezium, por exemplo, roda no Kafka Connect ou como Debezium Server, então alguém do time precisa operar e monitorar esse sistema. Serviços de streaming gerenciados reduzem esse trabalho, mas cobram por volume ou por hora.

Um teste simples ajuda aqui. Se ninguém age sobre um número nos cinco minutos seguintes à mudança dele, um lote de mudanças completas a cada poucos minutos entrega o mesmo resultado que o streaming, por um custo menor.

Como as melhores ferramentas de CDC se comparam em 2026?

As ferramentas de CDC que valem uma análise em 2026 se dividem em três grupos: plataformas gerenciadas (Erathos, Fivetran, Airbyte Cloud, Estuary, Weld), serviços de nuvem ligados a um único provedor (AWS DMS, Google Datastream) e engines open source que você mesmo opera (Debezium, dlt). Elas diferem principalmente em quais bancos leem, com que frequência entregam e pelo que cobram.

Todos os números abaixo vêm das páginas de preços ou da documentação de cada fornecedor, conferidas em setembro de 2026:

Para PostgreSQL e MySQL, a maioria das ferramentas da tabela lê o log. A escolha para esses dois bancos se resume a velocidade de entrega, forma de cobrança e quem opera o sistema. Para Oracle ou Db2, a lista fica bem menor.

Qual ferramenta de CDC você deve escolher?

A ferramenta de CDC certa depende de três coisas: qual banco você lê, quão atualizados os dados precisam estar e se você quer operar servidores. Veja para quem cada ferramenta serve e onde ela deixa a desejar:

• Erathos serve para times em PostgreSQL ou MySQL que querem CDC baseado em log a cada 5 minutos, com preço mensal fixo. O plano Pro custa US$ 250/mês para até 5M de linhas e carrega em BigQuery, Redshift, Databricks, ClickHouse, PostgreSQL, SQL Server, Supabase ou S3 com Iceberg. Não faz streaming em menos de um segundo e, hoje, o CDC lê apenas Postgres e MySQL.
• Fivetran serve para empresas que querem um único fornecedor para muitas fontes e podem pagar por syncs de 1 minuto no Enterprise. O conector de Postgres consegue ler a replicação lógica de uma réplica de leitura no PostgreSQL 16 ou superior, o que tira carga do banco principal. O custo cresce com as monthly active rows, então uma tabela movimentada que muda o dia todo fica cara.
• Airbyte serve para times que querem a opção de self-hosting. Seus conectores de banco usam o Debezium para CDC. O Airbyte Plus sincroniza no máximo a cada 15 minutos, e na versão autogerenciada seu time cuida das atualizações.
• Estuary serve para times que precisam das mudanças em milissegundos sem operar Kafka. O plano gratuito cobre 10 GB por mês e 2 conectores. A taxa de US$ 100 por conector pesa quando você tem muitas fontes e destinos.
• Weld serve para times que já estão no plano Business e querem CDC também para SQL Server ou MongoDB. Só o CDC custa US$ 479/mês, além do plano de US$ 959/mês.
• AWS DMS e Google Datastream servem para times que mantêm tudo dentro de uma única nuvem. O Datastream não cobra pelos primeiros 500 GiB de backfill de cada mês nem por um stream parado. Os dois atendem principalmente os warehouses da própria nuvem.
• Debezium serve para times de engenharia que já operam Kafka e querem controle total sem custo de licença. A versão 3.6 é a última versão estável. Seu time é dono dos servidores, do monitoramento e da recuperação quando um slot fica para trás.
• dlt serve para times de Python que querem CDC dentro do próprio código. A biblioteca é gratuita. A plataforma gerenciada dltHub começa em US$ 12.000/mês, com contrato mínimo de 12 meses.
• Kondado serve para empresas brasileiras que querem preço em reais e atualizações a cada 5 minutos. Ele conta registros de até 500 bytes cada e pausa as integrações quando você atinge o limite do plano.

Como os modelos de preço de CDC se comparam?

As ferramentas de CDC cobram de uma de quatro formas: por linhas, por volume de dados, por um plano fixo com limite de linhas ou pelos servidores que você opera. A unidade de cobrança importa mais que o preço de vitrine, porque a mesma carga pode parecer barata em um modelo e cara em outro.

Veja o que cada modelo conta:

• Linhas alteradas. A Fivetran cobra por monthly active rows (MAR), medidas por milhão a cada mês do calendário. A Weld também conta linhas. Uma tabela em que as mesmas linhas mudam o dia todo custa mais do que uma que só recebe linhas novas.
• Volume de dados. A Estuary cobra US$ 0,50 por GB, o Airbyte usa créditos atrelados a GB de dados de banco e o Google Datastream cobra por GiB de mudanças. Linhas largas, com colunas grandes de texto ou JSON, custam mais nesse modelo.
• Plano fixo com limite de linhas. O Erathos Pro custa US$ 250/mês para até 5M de linhas, seja qual for o tamanho da linha. A fatura é a mesma todo mês até você passar do limite.
• Servidores que você opera. O Debezium é gratuito, e o AWS DMS cobra por hora pelo servidor de replicação. Você paga por processamento e armazenamento, haja ou não dados em movimento.

Pense em um banco PostgreSQL que envia 5 milhões de linhas alteradas por mês para um warehouse. Se cada linha tem em média 1 KB, são cerca de 5 GB. Usando o preço de tabela de cada fornecedor, esta é a fatura mensal:

Nesse tamanho, o plano gratuito da Estuary e o Datastream são as opções mais baratas no papel. O cenário muda conforme o volume cresce. Com 50 GB por mês, a Estuary passa para o plano pago: 50 x US$ 0,50 + 2 x US$ 100 = US$ 225. O Erathos Pro vai até 5M de linhas, e volumes maiores passam para o plano Enterprise, que cobre até 1,5 bilhão de linhas.

O plano fixo é o mais fácil de orçar. O preço por volume é o mais barato para tabelas pequenas e estreitas. O preço por linha é o mais difícil de prever para tabelas que mudam com frequência.

O que configurar no seu banco antes de ativar o CDC?

Antes que qualquer ferramenta de CDC baseado em log consiga se conectar, o banco precisa gravar um log detalhado e mantê-lo por tempo suficiente para a ferramenta ler. A configuração leva poucos ajustes em cada engine, e um desses ajustes no Postgres protege o seu disco.

No PostgreSQL, estas são as configurações que o guia de Postgres da Erathos pede:

1. Defina wal_level como logical, para que o WAL registre mudanças de linha que uma ferramenta consiga decodificar.
2. Aumente max_replication_slots e max_wal_senders para abrir espaço para a conexão de CDC. Essas três configurações exigem reiniciar o banco.
3. Defina a replica identity de cada tabela como full. Sem isso, o Postgres deixa de fora do log o estado completo de antes e depois da linha em updates e deletes.
4. Defina max_slot_wal_keep_size, que limita quanto WAL um único slot pode reter. Essa vale sem reiniciar.

O último passo importa porque um slot impede o Postgres de remover o WAL até o leitor confirmar a leitura, mesmo quando nada está conectado. Testamos isso em um banco PostgreSQL 18.6. Criamos um slot, deixamos sem leitura, depois inserimos 200.000 linhas e atualizamos todas elas. Este é o SQL da criação da tabela, do limite de tamanho e da checagem:

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;

Este foi o resultado da checagem:

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

Esse único lote de mudanças deixou 77 MB de WAL no disco que o Postgres não podia limpar. Um banco de produção movimentado grava muito mais, então um slot sem leitura durante um fim de semana pode encher o disco. Por padrão, o limite é -1, o que deixa um slot reter WAL sem limite. Com um limite definido, o Postgres descarta o WAL antigo quando o slot passa dele, e a conexão de CDC precisa copiar as tabelas de novo. Isso custa tempo, mas mantém o banco no ar.

No MySQL, o binlog precisa de log baseado em linhas com imagens completas das linhas. O guia de MySQL da Erathos lista estas configurações para o arquivo de configuração:

• binlog_format = ROW, para que cada entrada traga a linha alterada.
• binlog_row_image = FULL, para que cada entrada traga todas as colunas.
• binlog_expire_logs_seconds, que define por quanto tempo o MySQL guarda os arquivos de binlog. O padrão do MySQL é 30 dias. Se o MySQL apagar um arquivo antes de a ferramenta de CDC lê-lo, a ferramenta precisa copiar as tabelas de novo.

No SQL Server, você ativa o CDC com duas procedures nativas, sys.sp_cdc_enable_db e depois sys.sp_cdc_enable_table para cada tabela. No MongoDB, os change streams devolvem um resume token a cada mudança, para que o leitor retome de onde parou.

Perguntas frequentes sobre ferramentas de CDC

Qual a diferença entre CDC e ETL?
ETL (extract, transform, load) é o trabalho completo de levar dados para um warehouse. CDC é uma forma de fazer a etapa de extração: ele pega apenas as linhas que mudaram desde a última execução, em vez de ler as tabelas inteiras de novo.

O CDC captura linhas apagadas?
O CDC baseado em log captura deletes, porque um delete é uma entrada no log do banco. A sincronização por consultas não enxerga uma linha que não existe mais, então as linhas apagadas continuam no warehouse até alguém recarregar a tabela.

O CDC deixa o banco de produção mais lento?
O CDC baseado em log lê o log em vez de rodar consultas nas suas tabelas. O risco maior é o espaço em disco. No nosso teste, um slot do Postgres sem leitura reteve 77 MB de WAL depois de 200.000 inserts e updates, então defina max_slot_wal_keep_size e acompanhe o tamanho do slot. A Fivetran também pode ler de uma réplica de leitura do Postgres 16+ para tirar carga do servidor principal.

O Debezium é gratuito?
O Debezium é gratuito e open source, sob a licença Apache 2.0. Você ainda paga pelos servidores em que ele roda, normalmente um cluster de Kafka Connect, e pelas pessoas que o mantêm funcionando.

Preciso de Kafka para usar CDC?
Não. Ferramentas gerenciadas como Erathos, Fivetran, Airbyte Cloud e Estuary fazem a captura por você. O Debezium Server também envia mudanças para outros destinos sem o Kafka Connect.

Com que frequência uma ferramenta de CDC entrega os dados?
Vai de milissegundos (Estuary, Debezium) a cada minuto (Fivetran Enterprise), a cada 5 minutos (Erathos Pro, Weld com add-on) e a cada 15 minutos (Fivetran Standard, Airbyte Plus). Entregas mais rápidas costumam estar nos planos mais caros, então a velocidade mais lenta que quem consome os dados aceita é a escolha mais barata.

Qual é a ferramenta de CDC mais barata?
Para volumes pequenos, o plano gratuito da Estuary cobre 10 GB por mês com 2 conectores, e o plano gratuito da Fivetran cobre 500.000 monthly active rows. O Debezium não tem taxa de licença, mas precisa de servidores e engenheiros. Para uma fatura fixa, o Erathos Pro custa US$ 250/mês para até 5M de linhas, com CDC a cada 5 minutos.

A Erathos tem CDC?
Sim. A Erathos lê o WAL do PostgreSQL e o binlog do MySQL nos planos Pro e Enterprise e entrega as mudanças a cada 5 minutos no Pro. Ela pode começar com uma cópia completa das suas tabelas ou transmitir apenas as mudanças novas.

Teste a Erathos grátis por 14 dias

A Erathos entrega CDC baseado em log do PostgreSQL e do MySQL para o seu warehouse a cada 5 minutos, com preço mensal fixo e sem servidores para operar. Comece seu teste grátis de 14 dias da Erathos e conecte seu primeiro banco hoje.