Toda empresa tem um banco de dados que “sabe a verdade”: o sistema de pedidos, o cadastro de clientes, o ERP, o core bancário. O problema é que essa verdade precisa chegar a muitos outros lugares: ao data warehouse, ao lakehouse, ao cache da aplicação, ao índice de busca, ao modelo de Machine Learning e, cada vez mais, aos Agentes de IA que tomam decisões em tempo real.

Durante décadas, a resposta foi o job noturno. Uma rotina de ETL lê tabelas inteiras, compara com a cópia anterior e carrega o resultado no destino. Funciona, mas cobra caro: o banco de produção sofre com queries pesadas, o dado chega com horas de atraso e as exclusões simplesmente desaparecem sem deixar rastro. De fato, isso ainda existe por aí. Pelo menos onde não se conhece o CDC.

Change Data Capture, ou CDC, resolve esse problema pela raiz. Em vez de perguntar periodicamente “o que mudou?”, o CDC observa o banco de dados e captura cada inserção, atualização e exclusão no momento em que acontece, entregando essas mudanças como um fluxo contínuo de eventos para quem precisar consumi-las.

Neste post você vai entender o que é CDC, como as diferentes abordagens funcionam, quais ferramentas dominam o mercado em 2026 e onde a técnica se encaixa nas arquiteturas modernas de dados e IA. CDC é estudado na prática aqui na DSA na Formação Engenheiro de Dados 4.0, Formação Engenheiro DataOps 4.0 e Formação Database Engineer 4.0.

O Que é Change Data Capture?

CDC é um conjunto de padrões de projeto para identificar, capturar e entregar as mudanças feitas nos dados de um sistema de origem. O resultado não é uma cópia da tabela, mas o registro do que mudou, quando mudou e, na maioria das implementações, qual era o valor anterior.

A ideia não é nova. O conceito nasceu no mundo dos data warehouses, onde preservar o estado dos dados ao longo do tempo sempre foi função essencial. O que mudou na última década foi a combinação do CDC com plataformas de streaming como o Apache Kafka, que transformou uma técnica de carga incremental em uma infraestrutura de eventos em tempo real.

Pense no CDC como o “feed de notícias” do seu banco de dados. Quando um cliente altera o endereço ou um novo pedido é criado, esse evento específico é capturado e enviado adiante, sem que ninguém precise varrer a tabela inteira para descobrir o que aconteceu.

> CDC captura três tipos de operação (INSERT, UPDATE e DELETE) e as entrega como eventos. A capacidade de capturar exclusões é uma das grandes vantagens sobre abordagens tradicionais, que simplesmente não conseguem “ver” um registro que deixou de existir.

As Três Abordagens de CDC

Existem três formas principais de implementar CDC. Elas diferem em impacto no banco de origem, completude da captura e complexidade operacional.

1. CDC baseado em log de transações (log-based)

Todo banco de dados relacional mantém um log de transações para garantir durabilidade e recuperação em caso de falha: o WAL (Write-Ahead Log) no PostgreSQL, o binlog no MySQL, o redo log no Oracle, o transaction log no SQL Server. No MongoDB, o equivalente é o oplog.

O CDC baseado em log lê esse arquivo diretamente. Como o log já registra tudo que foi confirmado (commit), na ordem exata em que aconteceu, a captura é completa, ordenada e praticamente invisível para a carga de trabalho de produção: nenhuma query adicional é executada nas tabelas.

É a abordagem recomendada para praticamente qualquer cenário de produção e a base de ferramentas como o Debezium.

2. CDC baseado em triggers

Aqui, gatilhos são criados nas tabelas de interesse. A cada INSERT, UPDATE ou DELETE, o trigger grava uma cópia da mudança em uma tabela auxiliar de auditoria, que depois é lida pelo pipeline.

Funciona em qualquer banco que suporte triggers e não exige acesso ao log de transações, o que pode ser útil em ambientes com restrições de permissão. O custo é que cada escrita na tabela original passa a executar lógica adicional dentro da mesma transação, adicionando latência e carga ao banco de produção. Em tabelas de alto volume, isso costuma se tornar um problema.

3. CDC baseado em consulta (query-based)

A abordagem mais simples: uma coluna como `updated_at` ou um contador de versão é usada para consultar periodicamente “todos os registros alterados desde a última execução”.

É fácil de implementar e atende bem cargas incrementais agendadas, mas tem limitações: Não captura DELETEs (o registro apagado não aparece na consulta), depende de a aplicação manter a coluna de timestamp sempre atualizada e pode perder atualizações intermediárias entre duas execuções.

Anatomia de Um Evento de Mudança

Um pipeline CDC produz eventos com uma estrutura bem definida. O formato abaixo segue o padrão do Debezium, que se tornou referência de fato no mercado. O evento representa a atualização de um pedido que passou de “PENDENTE” para “PAGO”:

Os campos mais importantes:

– before / after: o estado da linha antes e depois da mudança. Em um INSERT, before é nulo. Em um DELETE, after é nulo.
– op: o tipo de operação. c (create), u (update), d (delete) e r (read, usado durante o snapshot inicial).
– source: metadados de origem, incluindo a posição no log (LSN no PostgreSQL, GTID ou posição de binlog no MySQL). É essa posição que permite retomar a captura exatamente de onde parou após uma falha.
– ts_ms: quando a mudança ocorreu no banco e quando o conector a processou, o que permite medir a latência do pipeline.

Com essa estrutura, qualquer consumidor consegue reconstruir o estado atual de uma tabela, manter um histórico completo de mudanças ou reagir a transições específicas (por exemplo, disparar uma ação apenas quando um pedido muda para “PAGO”).

A Arquitetura Típica de Um Pipeline CDC

Uma arquitetura CDC moderna costuma ter quatro camadas:

1. Fonte: o banco transacional (PostgreSQL, MySQL, Oracle, SQL Server, MongoDB, entre outros) configurado para expor seu log de transações.
2. Conector de captura: o componente que lê o log e transforma cada mudança em evento. O Debezium é o exemplo mais conhecido.
3. Camada de transporte: em geral um broker de eventos como Apache Kafka, Redpanda, Amazon Kinesis ou Google Pub/Sub, que armazena os eventos de forma durável e permite múltiplos consumidores.
4. Consumidores: data warehouse, lakehouse, cache, índice de busca, banco vetorial, microsserviços ou qualquer aplicação que precise reagir às mudanças.

O Debezium é distribuído principalmente como um conjunto de conectores para o Kafka Connect, mas também pode rodar de forma independente. O Debezium Server entrega eventos diretamente para destinos como Kinesis, Pub/Sub ou Apache Pulsar, sem Kafka no meio, e o Debezium Engine permite embutir a captura dentro de uma aplicação Java.

Um exemplo de configuração de conector Debezium para PostgreSQL, registrada via API REST do Kafka Connect:

Com essa configuração, o conector faz um snapshot inicial das tabelas pedidos e clientes, cria um tópico Kafka por tabela (loja.public.pedidos e loja.public.clientes) e, a partir daí, passa a transmitir cada mudança em tempo real usando a replicação lógica nativa do PostgreSQL.

Principais Casos de Uso

Replicação para analytics

O uso clássico. Em vez de sobrecarregar o banco transacional com queries analíticas ou esperar a carga noturna, o CDC mantém o data warehouse ou lakehouse sincronizado continuamente, com latência de segundos.

Migração de banco de dados sem downtime

Ao migrar de um banco para outro (de Oracle para PostgreSQL, ou de um data center para a nuvem), o CDC permite manter os dois sistemas sincronizados durante a transição. A aplicação continua operando no banco antigo enquanto o novo recebe todas as mudanças, e a virada acontece quando as duas cópias estão idênticas.

Microsserviços e o padrão Outbox

Em arquiteturas de microsserviços, um serviço frequentemente precisa atualizar seu banco e publicar um evento para outros serviços. Fazer as duas coisas de forma atômica é difícil. O padrão Outbox resolve isso: o serviço grava o evento em uma tabela “outbox” dentro da mesma transação, e o CDC captura essa tabela e publica os eventos no broker. O Debezium oferece suporte nativo a esse padrão.

Invalidação de cache e índices de busca

Quando um produto muda de preço no banco, o cache Redis e o índice Elasticsearch precisam refletir a mudança. O CDC alimenta esses sistemas com exatamente os registros alterados, sem reindexações completas.

Auditoria e histórico

Como cada evento carrega o estado anterior e o novo, o fluxo CDC é uma trilha de auditoria natural. Armazenado em um lakehouse, permite responder perguntas como “qual era o status deste pedido às 14h de ontem?”.

Machine Learning e IA

Modelos e Agentes de IA são tão bons quanto os dados que consomem. O CDC mantém feature stores atualizadas com os valores mais recentes e, em sistemas RAG, permite regenerar embeddings apenas dos documentos que mudaram, mantendo o banco vetorial sincronizado com a fonte. O termo “Agentic CDC” começou a circular em 2026 justamente para descrever pipelines que reduzem a distância entre a mudança no sistema operacional e o momento em que um agente consegue agir sobre ela.

O Ecossistema de Ferramentas em 2026

Debezium: o padrão de fato

O Debezium é um projeto open source criado em 2015, originalmente patrocinado pela Red Hat, e desde o final de 2024 mantido sob a Commonhaus Foundation. Oferece conectores para PostgreSQL, MySQL, MariaDB, MongoDB, Oracle, SQL Server, Db2, Cassandra, Vitess, Spanner e outros. Você aprende a trabalhar com o Debezium na Formação Engenheiro de Dados 4.0 e Formação Engenheiro DataOps 4.0

O projeto mantém um ritmo intenso de lançamentos. A versão 3.3, de outubro de 2025, introduziu semântica exactly-once para todos os conectores principais. A versão 3.6, lançada em meados de 2026, simplificou consideravelmente a configuração do log mining no Oracle, historicamente o conector mais difícil de operar. E a série 3.7, já em fase alpha, traz um novo conector para Ingres e suporte a timestamps de alta precisão.

A pesquisa da comunidade Debezium publicada em abril de 2026 dá uma boa medida da maturidade da ferramenta: 91% dos respondentes já usam o Debezium em produção, cerca de 61% trabalham em organizações com mais de 500 funcionários e 65% deram nota máxima ao recomendar a ferramenta. Os respondentes vieram de mais de 30 setores, de fintechs e saúde a logística, varejo e governo.

Uma novidade importante é a Debezium Platform, uma camada de gestão com interface gráfica, conexões reutilizáveis e observabilidade integrada, criada em resposta à principal dor apontada pela comunidade: a complexidade operacional de rodar CDC em escala.

Serviços gerenciados

Para quem prefere não operar Kafka e Kafka Connect, o mercado oferece diversas alternativas:

  • Airbyte: usa o Debezium por baixo dos panos, com um catálogo amplo de conectores e opção de self-hosting ou nuvem.
  • Fivetran: CDC gerenciado com zero manutenção, ao custo de uma licença comercial.
  • Estuary Flow: plataforma de CDC em tempo real com entrega direta para lakehouses.
  • AWS DMS: opção de baixo custo dentro do ecossistema AWS, tanto para migração quanto para replicação contínua.
  • Google Datastream e Microsoft Fabric (Mirroring): equivalentes nativos nas nuvens do Google e da Microsoft.
  • Qlik Replicate, Striim e Oracle GoldenGate: soluções enterprise consolidadas, comuns em ambientes com Oracle e mainframe.

Recursos nativos dos bancos

Muitos bancos oferecem CDC ou mecanismos equivalentes de fábrica. O SQL Server tem um recurso chamado literalmente Change Data Capture, que grava as mudanças em tabelas relacionais de captura. O PostgreSQL oferece replicação lógica com o plugin pgoutput. O MongoDB tem Change Streams. Até plataformas SaaS como o Salesforce expõem um fluxo CDC próprio. Ferramentas como o Debezium se apoiam nesses recursos nativos e adicionam padronização, snapshot inicial e integração com streaming.

Bancos de streaming

Uma tendência recente é a integração do CDC diretamente em engines de processamento de streaming. O Flink CDC e o RisingWave permitem declarar uma fonte CDC, transformar os dados com SQL e escrever em destinos como Apache Iceberg em um único sistema, reduzindo o número de componentes a operar.

CDC, Lakehouse e a Nova Camada de Dados Para IA

A combinação de CDC com formatos de tabela abertos como o Apache Iceberg é uma das arquiteturas que mais cresceu nos últimos dois anos. O Iceberg oferece transações ACID, evolução de schema e time travel sobre armazenamento de objetos, e o CDC fornece o fluxo de mudanças que mantém essas tabelas sincronizadas com o mundo operacional por meio de upserts e deletes transacionais.

Os grandes provedores já incorporaram esse padrão. O BigQuery, por exemplo, suporta ingestão CDC diretamente em tabelas Iceberg gerenciadas e a AWS documenta arquiteturas de referência que combinam Debezium, MSK e Glue Streaming para gravar mudanças em Iceberg no S3.

Para aplicações de IA, o efeito prático é a redução do “gap de realidade”. Um agente que consulta um lakehouse atualizado por CDC enxerga o estoque, o pedido ou o cliente como eles estão agora, e não como estavam na carga da madrugada.

Desafios e Boas Práticas

CDC baseado em log é poderoso, mas exige cuidado operacional. Os pontos de atenção mais comuns:

  • Snapshot inicial: antes de transmitir mudanças, o conector precisa capturar o estado atual das tabelas. Em bases grandes, isso pode levar horas e precisa ser planejado. Snapshots incrementais, que rodam em paralelo com o streaming, resolvem boa parte do problema.
  • Retenção do log: se o consumidor parar, o banco precisa reter o log até que ele volte. No PostgreSQL, um replication slot inativo faz o WAL crescer sem limite e pode esgotar o disco do servidor. Monitorar slots e alertar sobre lag é obrigatório.
  • Evolução de schema: colunas adicionadas, removidas ou renomeadas precisam se propagar pelo pipeline. Um schema registry e conectores que tratam DDL reduzem as quebras.
  • Ordenação e duplicatas: eventos da mesma chave devem ser processados em ordem. Particionar tópicos pela chave primária garante isso. Consumidores devem ser idempotentes, mesmo com garantias exactly-once no produtor.
  • Tratamento de DELETE: o destino precisa saber como aplicar exclusões. Em warehouses, a prática comum é o soft delete (marcar o registro) ou o merge com tombstones.
  • Dados sensíveis: o log de transações contém tudo, inclusive PII. Mascaramento ou exclusão de colunas no conector, criptografia em trânsito e controle de acesso aos tópicos são parte do projeto desde o início.

Quando o CDC é Exagero?

Uma observação recorrente entre profissionais experientes é que muitas equipes adotam CDC em streaming antes de realmente precisar. Um pipeline Debezium + Kafka + Schema Registry + consumidores é uma infraestrutura considerável para operar.

Se o negócio funciona bem com dados atualizados a cada hora, uma carga incremental baseada em updated_at pode ser a escolha correta. O CDC se justifica quando a latência importa de fato, quando os DELETEs precisam ser capturados com precisão, quando o banco de origem não suporta queries adicionais ou quando vários consumidores precisam do mesmo fluxo de mudanças. Nesses cenários, poucas técnicas entregam tanto valor.

Conclusão

Change Data Capture deixou de ser uma técnica de nicho para virar a espinha dorsal das arquiteturas de dados em tempo real. Ele conecta o banco transacional ao warehouse, ao lakehouse, ao cache, ao índice de busca e, agora, aos sistemas de IA, sem sobrecarregar a origem e sem perder informação.

Para o Engenheiro de Dados, dominar CDC significa entender logs de transação, streaming, formatos de tabela abertos e as garantias de consistência que unem tudo isso. Para o arquiteto, significa saber escolher entre o Debezium open source, um serviço gerenciado ou um recurso nativo da nuvem, e reconhecer quando a simplicidade de um batch bem feito é a melhor resposta.

Se você quer dominar arquiteturas de dados em tempo real, streaming e lakehouse com a profundidade que o mercado exige, conheça as Formações da Data Science Academy.

Equipe DSA

Referências:

Formação Engenheiro de Dados 4.0

Formação Engenheiro DataOps 4.0 

Formação Database Engineer 4.0.

Change data capture (Lakehouse / Apache Iceberg managed tables)

SQL Server Change Data Capture (CDC): How It Works, Limitations & Best Practices