CDC gerido vs Debezium self-hosted

Resposta curta. O CDC gerido costuma ganhar quando ninguém na equipa opera Kafka em produção hoje, quando há apenas um punhado de pipelines, ou quando existe um prazo. O self-hosting ganha quando já se opera bem o Kafka, quando restrições de rede ou de residência dos dados excluem um fornecedor, ou quando o volume é alto e estável o suficiente para que o preço por utilização cresça mais depressa do que o tempo de um engenheiro de plataforma. Pelo meio existe um caminho intermédio: Kafka gerido com os seus próprios conectores Debezium, ou Debezium Server sem Kafka. Se o que realmente precisa é de sincronização operacional bidirecional entre um CRM e uma base de dados, nenhum dos lados desta decisão é a resposta completa.

A licença é a linha mais pequena. O Debezium self-hosted é software gratuito que corre em infraestrutura e com pessoas que paga. O CDC gerido é uma fatura que substitui parte desse tempo das pessoas. Este artigo dá-lhe um modelo de custos que pode preencher com os seus próprios números, os modos de falha que costumam decidir a questão e uma resposta curta para cada perfil de equipa. Escrevemo-lo como engenheiros que operam as duas opções: somos parceiros da Stacksync para sincronização operacional gerida e construímos pipelines de CDC à medida quando essa é a melhor opção.

O que significam «CDC gerido» e «CDC self-hosted» em 2026

O change data capture (CDC) lê alterações ao nível da linha a partir do log de uma base de dados e envia-as para outro destino. A escolha não é entre duas caixas, gerido ou não. É um espetro, e o ponto em que se situa decide o que opera.

São exemplos, não uma classificação. Confirme cada afirmação sobre um produto na documentação do próprio fornecedor antes de decidir, porque os planos e os conectores mudam.

Dois factos tornam o extremo self-hosted menos pesado do que era. O Kafka 4.x corre sem ZooKeeper. E o Debezium 3.7, lançado a 29 de setembro de 2026, trouxe o primeiro CLI oficial do Debezium e permitiu que o Debezium Platform fizesse deploy em hosts por SSH, e não apenas em Kubernetes. É menos trabalho operacional do que antes. Continua a ser seu.

No extremo gerido, o PostgreSQL CDC Source V2 da Confluent Cloud é um conector baseado em Debezium faturado por hora de tarefa do conector mais transferência de dados. A página de preços indica alguns conectores premium como «contacte-nos», pelo que não citamos aqui nenhum valor.

O modelo de custos: todas as linhas, não apenas a licença

A maioria das folhas de cálculo compara a licença e a fatura da cloud. As linhas que decidem a resposta são aquelas em que ninguém lança nada.

Depois, ponha as linhas numa única fórmula:

TCO anual = infraestrutura + licenças + (horas de engenheiro por mês × custo horário total × 12) + provisão para incidentes

Use o seu próprio custo total por hora e a sua própria fatura de cloud. Deliberadamente, não damos valores em euros: qualquer preço que pudéssemos publicar seria inventado ou estaria desatualizado, e o número interessante é o seu. O mesmo vale para o ponto de cruzamento. O self-hosting fica mais barato com o crescimento do volume apenas se o tempo das pessoas se mantiver constante, por isso calcule com os seus próprios dados o ponto em que o preço por utilização ultrapassa o tempo dos seus engenheiros, e desconfie de qualquer limiar fixo que leia online, incluindo em blogues de fornecedores. Se quiser a versão específica para Salesforce deste argumento, leia a análise de comprar vs desenvolver para substituir o Heroku Connect.

Preenchemos este modelo consigo: marque uma chamada de 30 minutos e traga a sua fatura de cloud e a sua escala de on-call.

O que falha em produção (e quem resolve)

A comparação honesta está nos modos de falha. Em cada um, a pergunta é o que o fornecedor trata e o que continua a recair sobre si.

Replication slots do PostgreSQL a reter WAL

Se o conector deixar de consumir, o replication slot retém segmentos de WAL e o disco do primário enche. As mitigações são definir max_slot_wal_keep_size (PostgreSQL 13 e posteriores), alertar sobre o lag do slot e usar um heartbeat em bases de dados com pouca atividade. Self-hosted: faz tudo isso. Gerido: o fornecedor opera o conector, mas o slot vive na sua base de dados, pelo que o risco e os alertas continuam a ser seus. A própria documentação da Airbyte refere que um slot invalidado depois de excedido max_slot_wal_keep_size tem de ser recriado e exige uma sincronização completa.

Alterações de esquema

O DDL na tabela de origem muda o que o conector emite. As regras de compatibilidade do schema registry decidem se os consumidores a jusante deixam de funcionar. Self-hosted: desenha e impõe a política de compatibilidade. Gerido: a plataforma pode incluir um registry, mas as suas equipas continuam a ser donas dos contratos com cada consumidor.

Snapshots e re-snapshots

Um snapshot inicial lê as tabelas de origem e sobrecarrega a base de dados de origem. Os snapshots incrementais reduzem esse custo, e uma paragem longa pode obrigá-lo a voltar a um snapshot completo. Durante um snapshot longo o slot não avança, pelo que, numa tabela grande, o WAL acumula-se. Self-hosted: é você quem o agenda e vigia. Gerido: o fornecedor executa o snapshot, mas é você quem decide quando a carga na sua base de dados é aceitável.

Semântica de entrega

Planeie para entrega at-least-once. Os consumidores têm de ser idempotentes, e não prometeríamos exactly-once de ponta a ponta para nenhuma das opções. Self-hosted: desenha a idempotência. Gerido: o mesmo, porque ela vive nos seus consumidores.

Falhas e reinícios de tarefas do conector

As tarefas falham, reiniciam e por vezes deparam com uma poison message. As dead-letter queues e os runbooks claros importam mais do que a plataforma. Self-hosted: o pager é seu. Gerido: o fornecedor reinicia os workers, mas é você quem faz a triagem dos dados errados.

Atualizações

O Debezium lança com frequência versões 3.x, o Kafka tem versões major, e uma atualização major do seu PostgreSQL gerido exige planeamento em torno dos logical replication slots. Self-hosted: o trabalho de atualização é trabalho de sprint. Gerido: o fornecedor atualiza a plataforma, e você planeia o lado da base de dados.

Quando o self-hosting é a decisão certa

O self-hosting é a decisão certa nestas situações:

• Já existe uma equipa de plataforma Kafka, pelo que o custo marginal de mais um conector é pequeno.
• Um requisito estrito de VPC, on-premises ou de residência dos dados que nenhum fornecedor consegue cumprir.
• Volume alto e estável, em que o preço por utilização ultrapassa o custo das pessoas. Calcule o ponto de cruzamento com os seus próprios números.
• Precisa de single message transforms ou de conectores personalizados que o catálogo gerido não oferece.
• Ser dono do pipeline é estratégico, por exemplo porque faz parte do seu produto.

Quando o gerido ganha

O gerido ganha nestas situações:

• Não tem Kafka em produção hoje.
• Uma só pessoa é a única que percebe o cluster Connect. Não há um tamanho de equipa mágico: o teste é saber se essa pessoa pode ir de férias.
• A migração é ditada por um prazo, por exemplo a saída do Heroku Connect.
• Tem muitos pipelines pequenos, cada um demasiado pequeno para justificar cuidados próprios.
• O trabalho de auditoria ou de compliance prefere evidências SOC 2 ou ISO do fornecedor.

O ângulo europeu: residência dos dados e RGPD

Um stream de CDC copia dados pessoais, por isso o pipeline está no âmbito do seu registo das atividades de tratamento do RGPD. Verifique as regiões do fornecedor, se existe uma região da UE para o conector de que precisa, a lista de subcontratantes e o acordo de tratamento de dados. A maioria dos grandes fornecedores geridos oferece regiões da UE, mas confirme por fornecedor e por produto. O self-hosting na sua própria região de cloud da UE é a história de residência mais simples. Isto não é aconselhamento jurídico.

Migrar de Kafka self-hosted para gerido (ou o inverso)

As equipas que procuram o melhor serviço de Kafka gerido para uma migração costumam estar a perguntar como migrar sem um re-snapshot, e não que fornecedor escolher. Não classificamos fornecedores. A sequência importa mais do que o logótipo:

1. Inventarie tópicos, conectores, configurações e offsets confirmados.
2. Escolha a via de espelhamento, por exemplo o MirrorMaker 2 ou uma opção ao estilo cluster linking de um fornecedor, e teste-a num tópico não crítico.
3. Mantenha a continuidade do replication slot, para que o conector retome onde parou e não volte a cair num snapshot das suas tabelas de produção.
4. Planeie a transição e o rollback: quem muda os consumidores, por que ordem, e qual é o ponto a partir do qual já não se pode recuar.
5. Corra os dois em paralelo o tempo suficiente para comparar lag e contagens antes de desativar o que quer que seja.

A migração inversa, de gerido para self-hosted, segue os mesmos passos. O custo de saída é baixo para o Debezium open source e mais alto para uma plataforma gerida, o que é mais uma linha de custo a registar.

E a sincronização bidirecional (CRM e base de dados)?

O CDC é um fluxo de alterações num só sentido. Escrever de volta, por exemplo entre o Salesforce e o PostgreSQL, exige tratamento de conflitos, idempotência e prevenção de loops. Essas camadas são a parte difícil e estão explicadas na análise de comprar vs desenvolver. Se é o seu caso, consulte a nossa página de integração Salesforce–PostgreSQL e a página de parceiro da Stacksync.

Lista de verificação para decidir

Responda sim ou não. O que conta é o padrão, não a contagem.

1. Opera Kafka em produção hoje? (Sim aponta para self-hosted ou caminho intermédio, não aponta para gerido.)
2. Há mais do que uma pessoa capaz de reparar o cluster Connect às 3 da manhã?
3. Terá mais do que um punhado de pipelines nos próximos 12 meses?
4. Existe uma restrição de residência ou de rede que um fornecedor não consiga cumprir?
5. As suas bases de dados de origem são todas suportadas pela opção gerida?
6. Precisa de transformações ou conectores personalizados?
7. Precisa de sincronização bidirecional? (Sim: nenhuma das opções sozinha, veja a secção anterior.)
8. O lag aceitável mede-se em segundos, ou minutos chegam?
9. Quem gere o orçamento prefere uma subscrição operacional ou tempo de engenheiro?
10. Há um prazo firme dentro do próximo trimestre?

Maioritariamente «não» nas três primeiras e «sim» na última: gerido. Maioritariamente «sim» nas três primeiras e na 4 ou na 6: self-hosted. Uma mistura: o caminho intermédio de Kafka gerido com os seus próprios conectores, ou Debezium Server sem Kafka.

Perguntas frequentes

Compensa pagar por CDC gerido em vez de operar o seu próprio Kafka Connect?

Normalmente sim, se ninguém na equipa operar já Kafka em produção, ou se uma só pessoa concentrar todo o conhecimento. O self-hosting compensa quando já se opera bem o Kafka, existem restrições de residência dos dados, ou o volume é alto e estável e o preço por utilização ultrapassa o tempo dos engenheiros.

Quanto custa realmente o Debezium self-hosted?

O software é gratuito sob a Apache 2.0. O custo é a infraestrutura (brokers Kafka, workers do Connect, armazenamento, rede) mais o tempo de engenharia para monitorização, atualizações, on-call e recuperação de incidentes. Modele cada linha com os seus próprios números.

Que plataforma de CDC tem o menor custo total de propriedade?

Depende do volume, da equipa e da infraestrutura existente. Nenhuma plataforma é a mais barata para todos. Compare todas as linhas de custo, não a licença.

Preciso de Kafka para usar o Debezium?

Não. O Debezium Server e o Debezium Engine embebido enviam as alterações para outros destinos sem Kafka. O Kafka Connect continua a ser a implementação mais comum.

O CDC gerido elimina o risco do replication slot no PostgreSQL?

Não. O slot vive na sua base de dados. Se o conector deixar de consumir, o WAL acumula-se. Defina max_slot_wal_keep_size e alerte sobre o lag do slot em qualquer dos casos.

Debezium vs Airbyte para CDC?

O Debezium é um motor de CDC que faz streaming das alterações de linhas. A Airbyte é uma plataforma de ELT que pode usar CDC em algumas origens, e o seu CDC de Postgres assenta no Debezium. Escolha pela latência de que precisa e pelo que quer operar. O artigo de comprar vs desenvolver compara-os para o caso do Salesforce.

O CDC gerido pode correr numa região da UE por causa do RGPD?

A maioria dos grandes fornecedores oferece regiões da UE. Verifique a região, os subcontratantes e o acordo de tratamento de dados por fornecedor. O self-hosting na sua própria região de cloud da UE é a história de residência mais simples.

O CDC chega para sincronização bidirecional entre o Salesforce e o PostgreSQL?

Não. O CDC é num só sentido. A sincronização bidirecional exige escrita de volta, regras de conflito e prevenção de loops. Veja a nossa página Salesforce–PostgreSQL.

Conclusão: não sabe de que lado da linha está?

Comece por listar os seus pipelines, quem está de on-call em cada um e quanto custa um dia de lag. Essa lista costuma resolver a questão mais depressa do que uma comparação de fornecedores. Se quiser uma segunda opinião de quem opera as duas opções, marque uma chamada de 30 minutos. Para o conjunto mais vasto, leia o guia de migração para o fim de vida do Heroku Connect, o guia introdutório de CDC no Salesforce e no Heroku Connect e iPaaS vs ponto a ponto vs middleware.

Sobre o autor

Bruno Galo é o fundador da Atypical Tech, uma consultora de NetSuite que serve clientes de média dimensão em toda a Ibéria. Especializa-se em ligar sistemas de CRM e ERP para fluxos order-to-cash sem fricção, construindo pipelines automatizados de gestão de encomendas que eliminam a introdução manual de dados entre as equipas de vendas e de finanças. Como parceiro oficial de implementação da Stacksync, o Bruno desenha e implementa agentes de IA em plataformas de integração para tratar o encaminhamento de exceções, o processamento de documentos e a reconciliação, transformando fluxos de encomendas fragmentados em sistemas fiáveis e autovigiados.

LinkedIn: https://www.linkedin.com/in/brunogd

Fontes

• Debezium, «Debezium 3.7.0.Final released», 29 de setembro de 2026 — https://debezium.io/blog/2026/09/29/debezium-3-7-final-released/
• Versões do Debezium — https://debezium.io/releases/
• Confluent, conector PostgreSQL CDC Source V2 (Debezium) para o Confluent Cloud — https://docs.confluent.io/cloud/current/connectors/cc-postgresql-cdc-source-v2-debezium/cc-postgresql-cdc-source-v2-debezium.html
• Confluent Cloud, preços dos conectores totalmente geridos (dimensões de faturação consultadas a 5 de outubro de 2026) — https://www.confluent.io/confluent-cloud/connect-pricing/
• Airbyte, documentação da origem Postgres (CDC e replication slots) — https://docs.airbyte.com/integrations/sources/postgres
• Experiência da Atypical Tech em projetos de CDC e de pipelines de sincronização operacional