GoldenGate vs Debezium: CDC, Custos e Limitações

Uma atualização em uma tabela Oracle pode precisar chegar a outro banco, alimentar um Data Lakehouse ou ser consumida por dezenas de serviços. Consultar a origem a cada minuto ou executar cargas completas resolve parte do problema, mas adiciona atraso, leituras e dificuldades para detectar exclusões. É nesse contexto que entra o Change Data Capture (CDC).

Oracle GoldenGate e Debezium capturam mudanças, mas não oferecem exatamente a mesma solução. Compará-los somente pelo preço ou pela velocidade da captura leva a decisões equivocadas. O que importa é o fluxo completo: captura, transporte, entrega, aplicação, recuperação e sustentação.

O que é CDC e quais problemas ele resolve?

CDC identifica alterações realizadas nos dados e permite propagá-las incrementalmente. No modelo baseado em logs, os registros transacionais do banco são utilizados para identificar operações como INSERT, UPDATE e DELETE, reduzindo a necessidade de varrer tabelas repetidamente.

Isso ajuda a diminuir o intervalo entre a transação na origem e sua disponibilidade em outros sistemas. Mas CDC não é sinônimo de replicação pronta, nem substitui carga inicial, observabilidade ou tratamento de falhas. Uma arquitetura pode capturar corretamente todas as mudanças e ainda assim falhar ao aplicá-las no destino.

Oracle GoldenGate: da captura à replicação transacional

O Oracle GoldenGate é uma plataforma de integração e replicação de dados. Na arquitetura clássica, o Extract captura alterações, os Trail Files persistem os registros intermediários e o Replicat aplica as operações no destino. Um Data Pump Extract pode transportar trails entre ambientes. Na arquitetura Microservices, serviços de distribuição, recepção e administração alteram o modo de operação, sem eliminar a lógica de captura, transporte e aplicação.

Seu diferencial não é simplesmente ler redo logs, mas oferecer uma cadeia de replicação com checkpoints, mecanismos de recuperação e opções de aplicação transacional, conforme produto e topologia.

Vantagens: aderência a migrações com baixa indisponibilidade, replicação Oracle–Oracle, integração heterogênea suportada e operação empresarial de fluxos transacionais.

Limitações e custos: licenciamento comercial, complexidade de topologias, necessidade de conhecimento especializado e cuidados com DDL, chaves, transformações e conflitos em arquiteturas bidirecionais. Não basta ativar o Extract para garantir consistência em qualquer destino.

O que é Debezium e como funciona com Oracle?

O Debezium é uma plataforma open source baseada em conectores CDC. Seu cenário mais difundido utiliza Kafka Connect para publicar eventos em tópicos Kafka, permitindo que diversos consumidores processem as mesmas alterações. Também há modelos como Debezium Server e Embedded Engine: Kafka não é uma dependência universal da ferramenta.

No Oracle, o conector pode utilizar LogMiner, XStream ou OpenLogReplicator. O LogMiner é a opção padrão; exige preparação da origem, incluindo ARCHIVELOG, supplemental logging e privilégios adequados. Snapshots ajudam a obter o estado inicial, enquanto offsets e histórico de schema permitem continuar a captura e interpretar alterações.

Arquitetura típica:

Oracle (redo/archive logs) → Debezium / Kafka Connect → Kafka → consumidores

Imagine a execução:

UPDATE CLIENTES SET STATUS = 'ATIVO' WHERE ID = 100;
COMMIT;

Um evento simplificado, ilustrativo e não um payload integral, poderia ter a seguinte estrutura:

{
  "op": "u",
  "before": {"ID": 100, "STATUS": "PENDENTE"},
  "after":  {"ID": 100, "STATUS": "ATIVO"},
  "source": {"db": "ORCL", "table": "CLIENTES"}
}

O campo op: "u" indica atualização; os estados before e after dependem das informações disponíveis e da configuração de logging. O evento real também pode conter SCN, identificadores de transação e timestamps, entre outros metadados.

Vantagens: integração natural com streaming, múltiplos consumidores, arquitetura desacoplada e código aberto.

Limitações: o Debezium não aplica sozinho transações em outro Oracle. Para materializar dados no destino, são necessários sinks ou consumidores, com tratamento de falhas, duplicidade, ordem, schema e idempotência. Essa responsabilidade não desaparece porque a captura foi bem-sucedida.

Comparativo técnico

Critério	GoldenGate	Debezium
Foco	Replicação e integração transacional	Captura e publicação de eventos
Captura Oracle	Componentes de captura GoldenGate	LogMiner, XStream ou OpenLogReplicator
Aplicação Oracle–Oracle	Replicat nativo	Exige consumidor ou sink adicional
Carga inicial	Estratégias de initial load/sincronização	Snapshots configuráveis
Integração Kafka	Possível via componentes/adaptadores	Caso de uso central com Kafka Connect
Recuperação	Checkpoints e trails	Offsets, histórico de schema e logs disponíveis
Licença	Comercial, com oferta Free limitada	Open source; XStream pode exigir licença Oracle
Maior atenção	Topologia, lag, aplicação e conflitos	Mineração, buffers, eventos e consumidores

Como avaliar latência, consistência e recuperação no CDC?

Não há base para afirmar que uma tecnologia é sempre mais rápida. A latência precisa ser separada em captura, transporte e aplicação/consumo. Um evento chegar ao Kafka não significa que já foi processado no sistema de destino. Do mesmo modo, lag baixo no Extract não comprova que o Replicat terminou de aplicar as alterações.

Na retomada após falhas, pode haver reentrega. Em configurações com semântica at-least-once, um mesmo evento pode ser entregue mais de uma vez, por exemplo, quando ocorre falha entre o processamento e a confirmação do offset. Consumidores idempotentes, controle de offsets e tratamento de transações são necessários para evitar efeitos duplicados. Algumas configurações e componentes oferecem garantias mais fortes, inclusive exactly-once em escopos específicos, mas essas garantias não se estendem automaticamente ao pipeline de ponta a ponta. É preciso validar separadamente captura, transporte, processamento e aplicação no destino.

Também é necessário preservar ordem quando ela importa. Kafka mantém ordem dentro de uma partição, não entre todas as partições de um tópico; a escolha de chaves de particionamento e a estratégia de consumo fazem parte do projeto.

Debezium com Oracle: detalhes que mudam a operação

No LogMiner padrão, alterações de transações ainda não confirmadas precisam ser mantidas em buffer até COMMIT ou ROLLBACK. Transações extensas e concorrência elevada podem pressionar a memória do conector. Há um modo alternativo de processamento de mudanças confirmadas que reduz esse buffer no conector, mas transfere trabalho e consumo de PGA para o Oracle. Não é uma otimização gratuita.

O histórico de schema também importa. A estratégia online_catalog utiliza o dicionário atual do banco e tem limitações quando DDL e DML se sobrepõem. A estratégia hybrid busca melhorar a reconstrução de alterações, mas não pode ser utilizada com lob.enabled=true. Portanto, se o requisito inclui captura de valores LOB, como CLOB, NCLOB e BLOB, é necessário avaliar uma estratégia compatível, como online_catalog ou redo_log_catalog, considerando as restrições de cada versão. A estratégia redo_log_catalog aumenta o volume de redo e está marcada como deprecated na documentação atual. A escolha precisa ser validada também para outros tipos complexos e para o comportamento de DDL.

Outro risco é a retenção de archive logs: se a captura parar e os logs necessários forem removidos, offsets preservados não são suficientes para retomar o processamento. Pode ser necessário um novo snapshot ou procedimento de recuperação. Isso exige alinhar FRA, política de backup, retenção e janelas de indisponibilidade.

O adaptador XStream usa tecnologia Oracle sujeita a direitos de licenciamento específicos. Já o OpenLogReplicator introduz um componente externo de leitura de redo, que precisa ser instalado, monitorado e mantido. A escolha deve considerar suporte, compatibilidade e impacto operacional, não apenas o desempenho potencial.

Debezium é gratuito? Quanto custa o GoldenGate?

O GoldenGate comercial tem licenciamento condicionado à edição, à métrica e aos componentes contratados. Recursos, conectores e direitos de uso precisam ser verificados nos documentos de licenciamento e no contrato da organização.

O GoldenGate Free não é uma versão comercial sem custo e sem restrições: é limitado a bancos Oracle de até 20 GB (em CDB, considerando o total das PDBs), possui suporte comunitário, não oferece direitos de ADG/XStream ou downstream capture e não pode ser integrado livremente com instâncias GoldenGate licenciadas ou ferramentas terceiras.

O Debezium é open source, mas não equivale a custo operacional zero. Kafka Connect, brokers quando usados, retenção de eventos, observabilidade, upgrades, segurança, disponibilidade e suporte precisam entrar na conta. Se a opção de captura for XStream, também há implicações de licença Oracle.

A comparação correta é de TCO (custo total de propriedade): licença, infraestrutura, competências, operação, recuperação e risco de indisponibilidade.

Quando escolher GoldenGate ou Debezium?

Cenário A — Migração Oracle com baixa indisponibilidade

Uma instituição financeira precisa migrar sua base Oracle para outra infraestrutura mantendo alterações sincronizadas até o cutover. Aqui, o desafio é garantir consistência, aplicar transações, monitorar defasagem e estabelecer um ponto de corte controlado.

GoldenGate tende a ser a escolha mais direta, pois já oferece componentes de captura e aplicação de replicação. Ainda assim, é preciso planejar carga inicial, reconciliação, compatibilidade de versões, tratamento de DDL e estratégia de rollback.

Cenário B — Oracle alimentando microsserviços e analytics

A mesma instituição deseja disponibilizar alterações cadastrais a serviços independentes, mecanismos antifraude e pipelines analíticos. O requisito agora é distribuir eventos a consumidores com ciclos de evolução distintos.

Debezium pode ser especialmente adequado, sobretudo se Kafka e Kafka Connect já fazem parte da plataforma. A equipe deve projetar contratos de eventos, particionamento, DLQ/reprocessamento quando aplicável, controle de acesso e idempotência nos consumidores.

É possível combinar as tecnologias: GoldenGate para replicação transacional e Debezium para eventos. Isso, porém, aumenta a necessidade de governança para evitar captura redundante e fluxos divergentes.

Critérios de escolha para produção

Antes de decidir, responda:

O objetivo é replicar dados entre bancos ou distribuir eventos para aplicações?
Quais são os requisitos de latência, RPO, recuperação e consistência?
Há DDL frequente, LOBs, transações longas ou necessidade de preservar ordem?
Quem sustentará logs, checkpoints/offsets, schemas, monitoramento e reprocessamento?
Qual é o TCO, incluindo licenças, infraestrutura e suporte?

Conclusão

GoldenGate e Debezium não são concorrentes perfeitos. Ambos podem fazer CDC, mas o GoldenGate entrega uma plataforma orientada à replicação e à aplicação transacional, enquanto o Debezium se destaca na disponibilização de mudanças como eventos.

Se a prioridade é sincronizar bancos com mecanismos especializados de aplicação, GoldenGate tende a ser a alternativa natural. Se o objetivo é desacoplar sistemas e distribuir alterações para diversos consumidores, Debezium merece uma avaliação séria. A decisão correta nasce dos requisitos de negócio, da arquitetura de destino e da capacidade de sustentar o fluxo em produção — não apenas do preço da licença.

Referências oficiais

Nota: funcionalidades, suporte, versões e condições de licenciamento podem mudar. Consulte a documentação e os contratos específicos antes de implementar.

Oracle GoldenGate vs Debezium