Salesforce Change Data Capture vs Heroku Connect: por que só o CDC não basta para sincronização operacional em tempo real

O Salesforce CDC é um fluxo de eventos quase em tempo real sobre a Pub/Sub API. O Heroku Connect é sincronização bidirecional baseada em polling, com intervalo mínimo de 10 minutos. Eles resolvem problemas diferentes: o CDC entrega eventos com latência abaixo de um segundo, o Heroku Connect mantém estado e escritas nos dois sentidos. A maioria dos times em produção precisa dos dois — CDC mais replay, resolução de conflitos e escrita de volta. Esta é a comparação honesta.

A pergunta saiu do campo teórico e virou urgente em 6 de fevereiro de 2026, quando a Salesforce colocou a Heroku em sustaining engineering mode e os times de engenharia começaram a reavaliar se continuavam pagando pelo Heroku Connect ou construíam eles mesmos sobre o CDC. Para o enquadramento da urgência da migração, veja nosso artigo complementar sobre o fim de vida do Heroku Connect. Para um olhar de perto nas rotas com destino warehouse que pulam a Heroku por completo, veja sincronização em tempo real de Salesforce para Snowflake sem Heroku Connect.

O que é realmente o Salesforce CDC

O Salesforce Change Data Capture é a primitiva de streaming de eventos da plataforma Salesforce. Quando um registro de qualquer objeto assinado é criado, atualizado, excluído ou restaurado, a Salesforce publica um evento de mudança. Os consumidores recebem esses eventos pela Pub/Sub API, um endpoint de streaming gRPC que substituiu o antigo streaming baseado em CometD. A referência canônica é a documentação de CDC do Salesforce Developers.

Alguns detalhes importam para a comparação:

• Os eventos de CDC carregam os campos alterados e um replay ID. Os consumidores podem retomar o fluxo a partir de um replay ID específico dentro de uma janela de retenção de 72 horas.
• A entrega é at-least-once. Os consumidores precisam deduplicar pelo ID do evento de mudança.
• Os eventos de CDC são unidirecionais: Salesforce → consumidor. Não existe primitiva de escrita de volta.
• A Pub/Sub API é baseada em gRPC, suporta payloads binários Avro e é mais eficiente que o streaming CometD antigo. É o cliente recomendado.
• A Salesforce passa os eventos de CDC por infraestrutura interna, então a latência costuma ficar abaixo de um segundo de ponta a ponta, do salvamento do registro até o consumidor receber o evento.

O CDC é um dos três canais de eventos da Salesforce. Os outros dois são os Platform Events (eventos personalizados que você publica de Apex ou APIs) e o Generic Streaming (legado). Para casos de sincronização, o CDC é o canal certo — ele carrega a semântica real de mudança de registro de que os times precisam.

O que o Heroku Connect realmente faz

O Heroku Connect é uma sincronização bidirecional gerenciada entre o Salesforce e o Heroku Postgres. A arquitetura é fundamentalmente diferente da do CDC. Segundo a documentação de performance do Heroku Dev Center, o Heroku Connect roda num modelo de polling com intervalo mínimo de 10 minutos. Ele consulta o Salesforce em uma agenda, busca os registros alterados e os escreve num schema correspondente no Postgres.

Três pontos se destacam:

1. O Heroku Connect mantém estado — seu schema no Postgres é uma réplica consultável dos objetos do Salesforce. O CDC, sozinho, não produz réplica; produz um fluxo.
2. O Heroku Connect é bidirecional. Quando uma linha do Postgres muda, ele escreve a mudança de volta no Salesforce no mesmo ciclo de polling. O CDC não tem caminho de escrita embutido.
3. O polling do Heroku Connect consome a cota de API do Salesforce. Conforme a central de ajuda da Heroku, o Heroku Connect contribui para o limite da streaming API da sua org — ou seja, um deployment movimentado pode estrangular outras integrações do Salesforce.

O Heroku Connect é a resposta legada para "quero dados do Salesforce num banco relacional, com escritas nos dois sentidos, sem escrever meu próprio pipeline". Funciona, mas é um produto da era do polling, e as contrapartidas (latência, amarração ao Heroku Postgres, risco estratégico do sustaining mode) já são amplamente compreendidas.

Comparação lado a lado

A tabela mapeia os dois nas sete dimensões que importam para sincronização em produção. Repare na coluna da direita, que captura o que os times realmente precisam — e com que frequência nem só o CDC nem só o Heroku Connect dão conta.

Leia cada linha da esquerda para a direita. Onde a coluna "realmente precisam" bate com o CDC, você pode usar só o CDC. Onde bate com o Heroku Connect, pode usar só o Heroku Connect. A maioria das linhas não bate com nenhum dos dois. Essa é a realidade arquitetural.

O que dá para construir só com o Salesforce CDC

O CDC sozinho resolve bem uma classe específica de problemas.

Fluxos unidirecionais para um processador de streams. Se você já opera Kafka, Kinesis ou AWS EventBridge, o CDC encaixa direitinho. O cliente da Pub/Sub API emite eventos para o seu processador de streams e os consumidores a jusante fazem o que precisarem. É o padrão que a Salesforce recomenda oficialmente para aplicações orientadas a eventos.

Views materializadas num warehouse. Muitos times levam eventos de CDC para um schema de pouso no Snowflake / BigQuery / Databricks e transformam a partir dali com dbt. A latência fica abaixo de um minuto de ponta a ponta, os custos são baixos (você paga ingestão do Snowflake mais consumo da Pub/Sub API) e a arquitetura é direta.

Caches operacionais somente leitura. Se você precisa de um cache em Postgres ou Redis dos dados do Salesforce para aplicações com muita leitura, CDC mais um consumidor enxuto que mantém o cache funciona. O detalhe: é preciso tratar as exclusões com cuidado (o CDC reporta exclusões, mas os consumidores precisam processá-las, não ignorá-las).

Onde o CDC termina. O CDC sozinho não consegue:

• Escrever de volta no Salesforce (não há primitiva de escrita)
• Reproduzir eventos com mais de 72 horas
• Fazer uma carga inicial em massa (o CDC é incremental; o backfill precisa da Bulk API 2.0)
• Detectar desvio de schema no seu destino
• Resolver conflitos entre o Salesforce e um destino gravável

O que não dá para construir só com CDC — e o que o Heroku Connect resolvia

A proposta de valor original do Heroku Connect era: não construa um pipeline de sincronização; nós mantemos uma réplica no Postgres com escritas nos dois sentidos. Para replicar esse resultado com CDC, é preciso construir cinco camadas adicionais.

Escrita bidirecional de volta. A REST API do Salesforce ou a Bulk API 2.0 tratam as escritas de volta para o Salesforce. Você precisa de chaves de idempotência para evitar escritas duplicadas nas retentativas, lógica de deduplicação para evitar laços entre os eventos de CDC e as suas próprias escritas, e tratamento de rate limit porque a REST API tem limites no nível da org.

Carga inicial em massa. O CDC é incremental. Para popular um destino do zero, você busca os dados existentes pela Bulk API 2.0 e depois começa a consumir CDC a partir de um replay ID que se sobreponha ao timestamp da carga. Feito errado, você tem linhas duplicadas ou linhas faltando. A maioria dos times subestima quanta engenharia isso exige.

Exclusões definitivas. O CDC reporta exclusões, mas o Salesforce exclui em definitivo depois da janela da lixeira. Se o seu consumidor de CDC estiver fora do ar durante o evento de exclusão definitiva, você perde a chance de aplicá-la. O Heroku Connect resolve isso como parte do ciclo normal de polling.

Replay além de 72 horas. Se o seu consumidor ficar fora do ar por 73 horas (um incidente longo, um deploy que deu errado, um debug de vários dias), o CDC não ajuda você a se recuperar. Você precisa ou de um topic do Kafka na frente do consumidor com retenção maior, ou de um job periódico de reconciliação completa que compare o destino com um snapshot da Bulk API.

Detecção de desvio de schema. Administradores do Salesforce adicionam campos. Campos personalizados aparecem. O evento de CDC traz o campo novo; o seu destino não tem coluna para ele; a mudança some em silêncio. Você precisa de uma camada que detecte mudanças de schema nos eventos de CDC e que evolua o schema do destino ou alerte.

Essas cinco camadas são o que transforma um fluxo de CDC num sistema de sincronização pronto para produção. Ou você as constrói, ou adota uma plataforma gerenciada que já as traga. Cobrimos o trade-off de build vs buy em detalhe no artigo complementar sobre build vs buy: substituir o Heroku Connect com Debezium, Airbyte ou uma plataforma de sincronização gerenciada.

A arquitetura para a qual os times estão convergindo (pós-Heroku-Connect)

Um stack moderno de sincronização do Salesforce em 2026 costuma ter estas camadas, independentemente de você construir ou comprar:

Salesforce
   │ (eventos CDC via Pub/Sub API; Bulk API 2.0 para a carga inicial)
   ▼
Consumidor de stream (topic do Kafka, plataforma CDC gerenciada ou cliente gRPC próprio)
   │
   ├──► Réplica no Postgres (leituras operacionais)
   ├──► Snowflake / BigQuery (analítica)
   └──► Caminho reverso: escrita de volta via REST ou Bulk API 2.0
        com idempotência + deduplicação + resolução de conflitos

Se as caixas desse diagrama são uma plataforma gerenciada (Stacksync, Whalesync, Bracket) ou um stack auto-hospedado (consumidor estilo Debezium + Kafka + escrita de volta própria) é a pergunta de build vs buy. O formato da arquitetura é o mesmo.

Esse é o padrão no qual o Heroku Connect não conseguiu se transformar. O modelo de polling dele é, no fundo, de um único nível. Não há fluxo de eventos, nem log reproduzível, nem caminho de escrita independente do ciclo de polling. Para chegar ao formato moderno é preciso sair do Heroku Connect — não existe upgrade no lugar. Para mais sobre seus limites arquiteturais específicos, veja o mergulho nos limites de arquitetura do Heroku Connect da Stacksync.

Quando só o CDC basta

Alguns times genuinamente não precisam do stack completo. O CDC sozinho encaixa quando:

• O destino é somente leitura. Warehouses analíticos, índices de busca, caches.
• O replay de 72 horas é suficiente. Seu consumidor tem alta disponibilidade e janelas curtas de indisponibilidade.
• Você não precisa de carga inicial em massa. O sistema é novo; pode começar no estado atual.
• O volume de dados é moderado. A vazão da Pub/Sub API dá conta; você não precisa de Kafka na frente.
• Você já opera uma plataforma de streaming em produção (Kafka, Kinesis, EventBridge).

Se marcar as cinco caixas, jogue o CDC direto na sua plataforma de streaming e pule a pergunta da sincronização gerenciada.

Quando você precisa de mais do que CDC

A maioria dos times em produção precisa de mais. Os dois indicadores fortes:

Você tem um caso de uso operacional. Aplicações voltadas ao cliente lendo dados derivados do Salesforce, ferramentas de suporte que escrevem de volta no Salesforce, automação de RevOps que atualiza registros a partir de modelos do warehouse. Operacional significa escritas nos dois sentidos, a resolução de conflitos importa e a indisponibilidade dói.

Você tem um deployment do Salesforce multi-org ou multi-tenant. Cada org tem seu próprio fluxo de CDC, seus próprios limites de API, seu próprio schema. Agregar entre orgs exige roteamento por tenant, resolução de conflitos ciente do tenant e observabilidade que deixe ver a saúde por tenant. Construir isso a partir das primitivas do CDC é engenharia de vários trimestres. As plataformas gerenciadas normalmente já incluem.

Se qualquer um dos dois se aplica, não construa um sistema de sincronização só com CDC. Ou adote uma plataforma gerenciada ou se comprometa com um desenvolvimento de 3 a 6 meses. Não existe caminho do meio que funcione em produção.

Perguntas frequentes

O Salesforce CDC é um substituto do Heroku Connect?
Não, não sozinho. O Salesforce CDC fornece a fonte dos eventos de mudança, mas não inclui sincronização bidirecional, mapeamento de schema, resolução de conflitos, replay além de 72 horas nem carga inicial em massa. Para replicar o resultado do Heroku Connect você precisa de CDC mais um consumidor, mais a Bulk API 2.0 para a carga inicial, mais um caminho de escrita de volta, mais detecção de desvio de schema. Ou você constrói esse stack ou usa uma plataforma gerenciada que já o traga.

Dá para usar o Salesforce CDC para sincronização bidirecional?
Não. O CDC é um fluxo de eventos unidirecional do Salesforce para os consumidores. Para escrever de volta no Salesforce você usa a REST API ou a Bulk API 2.0 e trata idempotência, deduplicação e resolução de conflitos por conta própria. A sincronização bidirecional é a camada que vai em cima do CDC, não parte do CDC.

Qual é a latência do Salesforce CDC?
A latência de ponta a ponta, do salvamento de um registro no Salesforce até um consumidor da Pub/Sub API receber o evento, costuma ficar abaixo de um segundo. O número exato depende da profundidade da fila interna do Salesforce, da localização do seu consumidor em relação à região do Salesforce e da saúde da conexão gRPC. Planeje para menos de 1 segundo em condições normais; espere picos ocasionais de 2 a 5 segundos sob carga.

Por quanto tempo o Salesforce CDC retém os eventos?
A janela de retenção do CDC é de 72 horas. Os consumidores podem retomar um fluxo usando um replay ID guardado até esse horizonte. Eventos com mais de 72 horas ficam indisponíveis; recuperá-los exige uma reconciliação com snapshot da Bulk API 2.0. Para necessidades de retenção maior, encaminhe os eventos de CDC para um topic do Kafka com período de retenção configurável.

O Salesforce CDC consome cota de API?
Sim, mas a uma taxa bem menor que o polling. O uso da Pub/Sub API conta contra os limites de publicação de eventos da streaming API, não contra os limites de chamadas síncronas da REST API. Um deployment de Heroku Connect fazendo polling a cada 10 minutos costuma consumir mais orçamento de API do que um consumidor de CDC equivalente na Pub/Sub API, conforme a documentação do Heroku Help sobre limites da streaming API.

Qual é a diferença entre o Salesforce CDC e os Platform Events?
O Salesforce CDC publica eventos de mudança de registro automaticamente quando objetos são criados, atualizados, excluídos ou restaurados. Os Platform Events são eventos personalizados que o seu código publica de Apex ou APIs. O CDC é para casos de sincronização (mudanças de estado de registro); os Platform Events são para eventos no nível da aplicação (um fluxo de trabalho próprio disparando). Ambos rodam sobre a Pub/Sub API.

Dá para escrever no Salesforce a partir de um banco Postgres usando CDC?
Não diretamente. O CDC vai na direção errada — é Salesforce → consumidor, não consumidor → Salesforce. Para escrever do Postgres de volta no Salesforce você precisa de um caminho separado: normalmente replicação lógica do Postgres ou triggers alimentando um consumidor que chama a REST API ou a Bulk API 2.0. Plataformas gerenciadas de sincronização bidirecional (incluindo a Stacksync) trazem as duas direções; construir a partir das primitivas exige os dois pipelines.

Por que o Heroku Connect não usa o Salesforce CDC por baixo?
O Heroku Connect é anterior à Pub/Sub API e ao formato atual do CDC. A Salesforce não modernizou o Heroku Connect para usar CDC, e essa é uma das principais razões de o piso de latência dele ser de 10 minutos — a arquitetura de polling é estrutural, não um parâmetro ajustável. Com a Heroku em sustaining mode, essa modernização é improvável.

Fechamento — Próximos passos para times que substituem o Heroku Connect por um stack baseado em CDC

Três passos concretos:

1. Decida se você precisa de bidirecional ou unidirecional. Se unidirecional basta, um consumidor de CDC pousando no seu warehouse é o caminho mais simples.
2. Se precisar de bidirecional, decida build vs buy. Resposta honesta: abaixo de 100M de eventos por dia e com menos de 5 engenheiros de backend sêniores, compre. Acima disso, ou com exigência de propriedade estratégica, construa. Detalhamos em build vs buy: substituir o Heroku Connect com Debezium, Airbyte ou uma plataforma de sincronização gerenciada.
3. Seja específico sobre latência e replay. "Tempo real" significa coisas diferentes em volumes diferentes. Se o seu SLA operacional é "as mudanças do Salesforce aparecem no Postgres em 5 segundos", o desenho é um; se é "em 100 ms para fluxos críticos de receita", muda bastante.

A página de produto da Stacksync mostra como é de ponta a ponta a sincronização bidirecional em tempo real que escala no caminho de comprar.

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 Developers — Change Data Capture: https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm
• Salesforce Developers — Pub/Sub API Overview: https://developer.salesforce.com/docs/platform/pub-sub-api/overview
• Salesforce Developers — Platform Events: https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm
• Salesforce Developers — Bulk API 2.0: https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm
• Heroku Dev Center — Diagnosing Heroku Connect Performance Issues: https://devcenter.heroku.com/articles/diagnosing-heroku-connect-performance-issues
• Heroku Dev Center — Optimizing Heroku Connect Performance: https://devcenter.heroku.com/articles/optimizing-heroku-connect-performance
• Heroku Help — Streaming API rate limit and Heroku Connect: https://help.heroku.com/F6F6FTGZ/why-is-my-heroku-connect-usage-contributing-to-my-salesforce-org-s-streaming-api-rate-limit