Build vs buy: substituir o Heroku Connect com Debezium, Airbyte ou uma plataforma de sincronização gerenciada

Com a Heroku em sustaining mode após o anúncio de 6 de fevereiro de 2026, os times estão pesando se auto-hospedam o CDC do Salesforce sobre Debezium, Airbyte ou Kafka — ou compram uma plataforma gerenciada como a Stacksync. O caminho de construir é viável, mas subestima 5 custos ocultos que facilmente somam US$ 300 mil a 600 mil no primeiro ano. Aqui está o trade-off e uma comparação de 90 dias contra 14.

Por que essa pergunta ficou urgente de repente

Duas mudanças colidiram. A decisão de sustaining mode da Salesforce (coberta por Salesforce Ben e outra imprensa do setor) fez todo cliente de Heroku Connect se perguntar se continuava pagando. E o ferramental de CDC open source — Debezium, Airbyte, Apache Kafka — amadureceu ao ponto em que um time de backend sênior consegue considerar com credibilidade auto-hospedar o substituto.

A conversa que hoje acontece em todo time de engenharia com Salesforce é alguma versão de: "O Heroku Connect nos custa US$ 25 mil por mês. Será que a gente não constrói?". A resposta é às vezes sim, muitas vezes não, e a linha divisória raramente está onde os times esperam.

Para o enquadramento da urgência da migração, veja nosso artigo complementar sobre o fim de vida do Heroku Connect. Para a base arquitetural do que é de fato um stack de sincronização baseado em CDC, veja Salesforce CDC vs Heroku Connect.

O que o caminho de construir realmente envolve

Uma sincronização bidirecional completa entre Salesforce e Postgres, construída a partir de primitivas, tem oito camadas. O Heroku Connect agrupa as oito; os caminhos de construção as reproduzem peça por peça.

1. Fonte de mudanças. CDC do Salesforce entregue pela Pub/Sub API. Latência abaixo de um segundo, janela de replay de 72 horas. Essa é a camada "fácil".
2. Consumidor do stream. Um cliente gRPC assinado na Pub/Sub API, persistindo eventos em Kafka, Kinesis ou direto no Postgres. Quem já tem Kafka tem quase tudo isso; projetos do zero precisam desenhar.
3. Carga inicial em massa. Bulk API 2.0 do Salesforce para preencher os dados existentes. Precisa se coordenar com o fluxo de CDC para não aplicar duas vezes nem perder registros durante a virada.
4. Caminho de escrita de volta. REST API do Salesforce + chaves de idempotência + lógica de retentativa + deduplicação para evitar laços entre as suas escritas e os eventos de CDC que chegam. Só essa camada são de 6 a 8 semanas de engenharia sênior.
5. Detecção de desvio de schema. Administradores do Salesforce adicionam campos personalizados. O CDC traz o campo novo. O seu schema de destino não tem. A sincronização o descarta em silêncio, a menos que você construa detecção, alerta e auto-evolução.
6. Resolução de conflitos. Quando o mesmo registro muda no Salesforce e no Postgres na mesma janela, quem ganha? Last-write-wins é a resposta fácil; regras configuráveis por objeto é o que os times em produção precisam.
7. Armazenamento de replay além de 72 horas. A janela do CDC é de 72 horas. Se o seu consumidor ficar fora do ar por 73 horas, você precisa de um topic do Kafka na frente com retenção maior ou de um job periódico de reconciliação completa com snapshots da Bulk API 2.0.
8. Observabilidade e alertas. Atraso de sincronização, eventos perdidos, desvio de schema, contagem de conflitos, falhas de escrita de volta. Nada disso vem de graça; tudo é obrigatório para operar em produção.

O Heroku Connect fazia as oito, mal em alguns pontos (polling de 10 minutos em vez de streaming CDC), mas fazia. Substituí-lo a partir das primitivas significa reconstruir as oito.

Os três stacks open source / híbridos mais considerados

Debezium + Kafka

O Debezium é o framework canônico de CDC no mundo Postgres / MySQL. Em 2026, o Debezium não traz um conector de origem estável para Salesforce — o trabalho específico do Salesforce historicamente vive em projetos adjacentes, não no Debezium upstream. Times que constroem sobre o Debezium normalmente o combinam com um cliente da Pub/Sub API do Salesforce (Java ou Python) que emite registros para o Kafka, e depois usam o sink de Postgres do Debezium.

Pontos fortes: testado em escala, ferramental operacional maduro, comunidade grande. Pontos fracos: sem conector de Salesforce de primeira classe, exige Kafka em produção, e o seu time é dono do cliente gRPC do lado do Salesforce.

Airbyte (open source)

O conector de origem Salesforce do Airbyte é bem mantido e ativamente usado. O modo padrão é sincronização incremental agendada (tipicamente 5 minutos ou mais). O Airbyte não roda nativamente num modelo de streaming abaixo de um segundo; ele está mais para "Fivetran moderno" do que para "CDC em tempo real".

Pontos fortes: fácil de implantar, biblioteca ampla de conectores, razoável para sincronização de estilo analítico. Pontos fracos: não é tempo real no sentido do Heroku Connect, sem escrita bidirecional de volta embutida, agendado em vez de streaming.

Conector Salesforce CDC Source da Confluent

O conector gerenciado Salesforce CDC Source da Confluent é o caminho "Salesforce → Kafka" pronto para uso mais próximo. Baseado em streaming, suporta CDC e Platform Events. Pronto para produção. Combina naturalmente com o sink de Postgres do Debezium.

Pontos fortes: gerenciado, streaming, grau de produção. Pontos fracos: exige Confluent Cloud ou um cluster Kafka Connect auto-hospedado, os custos de licença não são triviais em escala, e ainda exige que você construa o caminho de escrita de volta.

Os 5 custos ocultos de construir

São os custos que surpreendem os times seis semanas depois do início. Cada um é tempo real de engenharia, não opcional.

1. Pipelines de reconciliação. A entrega de CDC é at-least-once com janela de replay de 72 horas. Times em produção descobrem que de 0,1% a 1% dos eventos precisa de reconciliação contra um snapshot da Bulk API 2.0 — normalmente por indisponibilidade do consumidor, exclusões definitivas ou lacunas de desvio de schema. Construir a infraestrutura de reconciliação: de 4 a 6 semanas de engenharia sênior.
2. Escrita bidirecional de volta. REST API do Salesforce + idempotência + deduplicação + resolução de conflitos para a direção Postgres → Salesforce. Inclui tratar os rate limits da API, as falhas de regras de validação e a lógica de retentativa. De 6 a 8 semanas.
3. Detecção de desvio de schema. Campo personalizado adicionado no Salesforce → o CDC traz → o seu destino não tem coluna → perda silenciosa. Construir a detecção que compara os payloads de CDC que chegam com o schema de destino e ou o evolui automaticamente ou alerta: de 2 a 4 semanas no começo, mais manutenção contínua.
4. Suporte multi-org / multi-tenant. Se você sincroniza mais de uma org do Salesforce ou roda um SaaS onde cada cliente tem a sua, precisa de roteamento por tenant, isolamento e observabilidade. De 6 a 12 semanas.
5. Carga de plantão. Uma vez em produção: de 2 a 4 horas por engenheiro por semana em regime estável, com picos periódicos por incidentes. Distribuído pelo time, no longo prazo isso equivale tipicamente a um engenheiro em tempo integral.

Some o tempo de engenharia: cerca de 18 a 34 semanas de trabalho de backend sênior antes de o sistema ter grau de produção. A custo carregado (~US$ 300 mil a 500 mil por ano de backend sênior), o TCO do primeiro ano de construir cai em US$ 300 mil a 600 mil, com custo operacional contínuo equivalente a ~1 FTE.

Comparação lado a lado

A economia raramente favorece construir até você cruzar 100M de eventos por dia, onde o preço gerenciado se inverte e um stack Kafka auto-hospedado fica mais barato por unidade. Abaixo desse volume, o custo total da plataforma gerenciada (licença + zero engenharia contínua) costuma ser de 30% a 60% do custo carregado do caminho de construir.

Quando o caminho de construir realmente ganha

Existem quatro razões genuinamente boas para construir.

Propriedade estratégica do pipeline de dados. Algumas empresas tratam o stack de integração como competência central — fintechs que sincronizam dados de clientes entre muitos sistemas, ou grandes plataformas SaaS cujo produto é fundamentalmente sobre mover dados. Para esses times, ser dono do pipeline de ponta a ponta é a decisão certa independentemente do TCO.

Dados do Salesforce multi-tenant com isolamento estrito. Plataformas SaaS que rodam sobre orgs do Salesforce por cliente às vezes precisam de isolamento de rede no nível da org que as plataformas gerenciadas não oferecem nas faixas padrão. Auto-hospedar na sua própria VPC resolve — ao custo de construir todo o resto.

Restrições de compliance que exigem CDC on-premise / em VPC. Setores regulados que não podem enviar dados para uma plataforma SaaS de terceiros. A régua de compliance manda na arquitetura; o custo é secundário.

Custo em escala muito grande. Acima de ~100M de eventos de CDC do Salesforce por dia, o preço das plataformas gerenciadas costuma se inverter e o Kafka auto-hospedado fica mais barato por unidade. A maioria dos clientes de Heroku Connect não está nesse volume; para os que estão, construir é uma decisão econômica defensável.

Quando o caminho de construir perde

Três sinais que dizem comprar.

Time abaixo de 5 engenheiros de backend. O caminho de construir exige de 2 a 3 engenheiros sêniores sustentados por 3 a 6 meses, mais a propriedade operacional contínua. Times menores não conseguem bancar o custo de oportunidade.

Sincronização bidirecional exigida desde o dia um. Só a camada de escrita de volta são de 6 a 8 semanas. Times que precisam de bidirecional em produção rápido quase sempre perdem construindo.

Nenhuma plataforma de streaming já em produção. Se você não roda Kafka ou equivalente hoje, o caminho de construir inclui subir o Kafka — somando de 4 a 8 semanas de trabalho operacional mais engenharia de plataforma contínua. Compre.

Para uma visão mais profunda de por que a arquitetura do Heroku Connect trava em polling de 10 minutos e de como é uma arquitetura de substituição moderna, veja o mergulho nos limites do Heroku Connect da Stacksync.

Cronograma de referência de 90 dias se você construir

O cronograma realista para um time sênior de 2 a 3 engenheiros de backend construindo um substituto do Heroku Connect com grau de produção sobre arquitetura estilo Debezium.

1. Semanas 1–2: spike de arquitetura. Suba um consumidor gRPC da Pub/Sub API na linguagem que preferir (Java, Python, Go). Assine um canal de CDC. Comprove latência abaixo de um segundo de ponta a ponta. Decida Kafka versus pouso direto no Postgres.
2. Semanas 3–4: carga inicial com Bulk API 2.0. Construa o job de backfill. Coordene-o com o fluxo de CDC para que a virada de "carga em massa" para "CDC incremental" seja exata (sem duplicatas, sem lacunas).
3. Semanas 5–8: escrita bidirecional de volta. Cliente da REST API do Salesforce. Chaves de idempotência. Retentativa com backoff exponencial. Lógica de deduplicação para evitar laços entre as suas escritas e os eventos de CDC que chegam. Regras de resolução de conflitos por objeto.
4. Semanas 9–10: detecção de desvio de schema e auto-evolução. Compare os payloads de CDC que chegam com o schema de destino. Ou adicione colunas automaticamente ou alerte. Integre o alerta ao seu plantão existente.
5. Semanas 11–12: observabilidade e armazenamento de replay. Dashboards de atraso de sincronização, contagem de conflitos, eventos perdidos. Topic do Kafka de retenção longa (ou equivalente) para replay além de 72 horas.
6. Semana 13: execução em shadow. Rode o novo stack contra o deployment existente de Heroku Connect por 14 dias. Reconcilie a integridade dos dados de hora em hora. Marque e resolva cada divergência antes da virada.

13 semanas de trabalho de engenharia, mais uma janela shadow de 14 dias. Total: cerca de 90 dias do início até a virada em produção, com 2 ou 3 engenheiros de backend sêniores dedicados em tempo integral.

Cronograma de referência de 14 dias se você comprar (com a Stacksync como exemplo)

Para comparar, o cronograma típico de uma migração para plataforma gerenciada:

• Dias 1–3: conecte o Salesforce e o banco de destino. Mapeie o primeiro conjunto de objetos. Valide a autenticação e a sincronização básica.
• Dias 4–7: valide a direção da sincronização, os ajustes de resolução de conflitos e os dashboards de observabilidade. Configure alertas.
• Dias 8–10: janela shadow contra o deployment existente de Heroku Connect. Reconcilie contagens de linhas e hashes.
• Dias 11–14: vire o tráfego de escrita. Mantenha leitura dupla por 7 dias para reverter na hora. Desative o Heroku Connect.

Total: 14 dias de ponta a ponta com 1 ou 2 engenheiros em tempo parcial. É assim que se parece na prática a sincronização gerenciada em tempo real que escala.

Perguntas frequentes

O Debezium consegue sincronizar Salesforce com Postgres?
Não diretamente com o Debezium de fábrica. O Debezium não traz um conector de origem Salesforce de primeira classe em 2026. Times que constroem sobre o Debezium o combinam com um cliente gRPC próprio da Pub/Sub API (ou com o conector Salesforce CDC Source da Confluent) que emite registros para o Kafka, e depois usam o sink de Postgres do Debezium no destino. O stack completo é viável, mas não é um deployment de Debezium chave na mão.

O Airbyte é tempo real?
Não, não no sentido do Heroku Connect. O conector de origem Salesforce do Airbyte roda com sincronizações incrementais agendadas — tipicamente de 5 minutos ou mais. Ele está mais para "Fivetran moderno" do que para "CDC em tempo real". Para latência abaixo de um segundo você precisa de um cliente da Pub/Sub API (o conector da Confluent ou um gRPC próprio), não do Airbyte.

Qual é a alternativa open source mais barata ao Heroku Connect?
Não existe substituto direto perfeito. O padrão mais próximo é conector Salesforce CDC Source da Confluent → Kafka → sink de Postgres do Debezium, mais um serviço próprio de escrita de volta. Os custos de licença são mínimos em escala pequena (a Confluent tem faixa gratuita; Kafka e Debezium são open source). O custo de engenharia diminui o de licença — normalmente mais de US$ 300 mil no primeiro ano em tempo de construção com FTE incluído.

Quanto tempo leva para construir um substituto do Heroku Connect?
De três a seis meses para uma construção com grau de produção com 2 ou 3 engenheiros de backend sêniores. Os maiores consumidores de tempo são a camada de escrita bidirecional (6–8 semanas), os pipelines de reconciliação (4–6 semanas) e a integração de todas as camadas sob uma única superfície de observabilidade. Times que estimam "duas semanas para montar um consumidor de CDC" estão estimando a camada 1 de 8.

O Salesforce CDC suporta sincronização bidirecional?
Não. O CDC é um fluxo de eventos unidirecional do Salesforce para o consumidor, sem primitiva de escrita embutida. A sincronização bidirecional exige um caminho de escrita de volta separado com a REST API ou a Bulk API 2.0, com chaves de idempotência, lógica de deduplicação e resolução de conflitos. Cobrimos o detalhe arquitetural em Salesforce CDC vs Heroku Connect.

Quanto custa substituir o Heroku Connect?
Para a maioria dos times, uma plataforma de sincronização gerenciada fica na faixa de US$ 20 mil a 120 mil por ano — normalmente de 50% a 80% abaixo do gasto equivalente com Heroku Connect Enterprise. Auto-hospedar sobre Debezium/Airbyte/Kafka costuma sair por US$ 300 mil a 600 mil no primeiro ano (tempo de engenharia com FTE incluído) mais custo operacional contínuo equivalente a cerca de um engenheiro em tempo integral. A economia só se inverte em escala muito alta.

Qual é um cronograma realista para migrar para fora do Heroku Connect?
Comprando uma plataforma gerenciada: 14 dias de ponta a ponta com 1 ou 2 engenheiros em tempo parcial (3 dias de conexão, 4 de validação, 4 de shadow, 3 de virada). Construindo a partir das primitivas: de 3 a 6 meses com 2 ou 3 engenheiros de backend sêniores em tempo integral. Deployments grandes de Heroku Connect (mais de 50 fluxos, mais de 100M de linhas) esticam qualquer um dos cronogramas em 2 a 4 semanas por conta do trabalho de reconciliação.

O conector Salesforce CDC da Confluent está pronto para produção?
Sim. O conector Salesforce CDC Source da Confluent é um conector gerenciado com grau de produção que assina os eventos de CDC do Salesforce pela Pub/Sub API. É o caminho pronto para uso mais confiável de Salesforce para Kafka. Ele não fornece sincronização bidirecional; essa camada continua sendo sua.

Quando comprar é sempre melhor que construir a sincronização do Salesforce?
Três condições: time abaixo de 5 engenheiros de backend, sincronização bidirecional exigida desde o dia um, ou nenhum equivalente ao Kafka já em produção. Se qualquer uma for verdadeira, o custo de engenharia de construir quase sempre supera o custo plurianual de licença da plataforma gerenciada. Acima de 100M de eventos de CDC por dia com um time sênior, a conta pode virar.

Como as plataformas de sincronização gerenciada cobram — por registro, por conexão ou valor fixo?
Cada plataforma cobra de um jeito. A Stacksync usa um modelo de assinatura transparente baseado em número de conexões e faixa. A Whalesync usa um modelo por registro / volume de sincronização. Algumas plataformas iPaaS legadas cobram por registro processado, o que escala mal em volume alto. Modele sempre o seu volume esperado contra cada modelo de preço antes de assinar.

Fechamento — Recomendação de decisão

Percorra primeiro os três sinais de "comprar". Se qualquer um for verdadeiro, compre. Se os três forem falsos (você tem 5 ou mais engenheiros de backend sêniores, não precisa de bidirecional desde o dia 1 e já opera Kafka), o caminho de construir passa a valer um modelo — mas compare o TCO do ano 1 e do ano 3 com honestidade.

Se você está migrando para fora do Heroku Connect especificamente e o volume está abaixo de 100M de eventos de CDC por dia, a sincronização gerenciada em tempo real que escala da Stacksync é o caminho que a maioria escolhe. Temos visto viradas em 14 dias de forma consistente em migrações de middle market.

Sobre o autor

Bruno Galo — Fundador, Atypical Tech

Bruno Galo é o fundador da Atypical Tech, uma consultoria de NetSuite que atende clientes do middle market em toda a Ibéria. Ele é especialista em conectar sistemas de CRM e ERP para fluxos de order-to-cash sem fricção, construindo pipelines automatizados de gestão de pedidos que eliminam a entrada manual de dados entre os times de vendas e finanças. Como parceiro oficial de implementação da Stacksync, Bruno projeta e implanta agentes de IA sobre plataformas de integração para tratar roteamento de exceções, processamento de documentos e conciliação — transformando fluxos de pedidos fragmentados em sistemas confiáveis que se monitoram sozinhos.

LinkedIn

Fontes

• Salesforce Ben — Salesforce Shuts Down Heroku Enterprise Sales: https://www.salesforceben.com/salesforce-shuts-down-heroku-enterprise-sales-for-new-customers/
• Salesforce Developers — Pub/Sub API Overview: https://developer.salesforce.com/docs/platform/pub-sub-api/overview
• Salesforce Developers — Bulk API 2.0: https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm
• Salesforce Developers — Change Data Capture: https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm
• Debezium — Project home: https://debezium.io/
• Airbyte — Salesforce source connector: https://docs.airbyte.com/integrations/sources/salesforce
• Confluent — Salesforce CDC Source Connector: https://docs.confluent.io/kafka-connectors/salesforce-cdc-source/current/overview.html
• Apache Kafka — Documentation: https://kafka.apache.org/documentation/