Sincronização em tempo real de Salesforce para Snowflake sem Heroku Connect: o caminho direto para times de RevOps e analytics

O Heroku Connect só suporta o Heroku Postgres — ele não consegue escrever direto no Snowflake. Times de RevOps e analytics que precisam de dados do Salesforce no Snowflake com latência abaixo de um minuto têm três opções: o zero-copy share do Salesforce Data Cloud, ELT em lote (Fivetran, Airbyte) com cadência de 5 minutos a 1 hora, ou CDC em tempo real com 30 segundos a 2 minutos. A maioria escolhe a terceira.

Por que isso virou pergunta agora

O padrão legado era: Salesforce → Heroku Connect → Heroku Postgres → Fivetran → Snowflake. Dois saltos, latência em cada camada, dois relacionamentos com fornecedores. Funciona, mas é superdimensionado para analytics — e trava em cerca de 15 minutos de latência de ponta a ponta.

Duas coisas mudaram.

Primeira, o Heroku Connect não consegue escrever no Snowflake nativamente. Ele só escreve no Heroku Postgres, conforme a documentação padrão. Times que queriam Snowflake precisavam colocar o Heroku Postgres no meio como relé, pagando os dois produtos e somando latência.

Segunda, a decisão de sustaining mode da Salesforce no início de 2026 mudou a conta sobre manter esse relé rodando. A cobertura da Salesforce Ben confirmou que as novas vendas Enterprise estão pausadas e o desenvolvimento congelado. Para times de analytics no padrão legado de dois saltos, a pergunta agora é: continuar pagando o Heroku Postgres como relé, ou ir direto para o Snowflake? Para o contexto completo do cronograma, veja nosso artigo complementar sobre o fim de vida do Heroku Connect.

Latência abaixo de um minuto em dados de warehouse é o mínimo para analytics de receita. O piso de 10 minutos do Heroku Connect mais a cadência de 5 minutos a 1 hora do Fivetran não entregam isso. A arquitetura precisa mudar.

Os três caminhos de Salesforce para Snowflake

Caminho 1 — Zero-copy share do Salesforce Data Cloud

O Salesforce Data Cloud suporta um zero-copy data share com o Snowflake — o Snowflake consulta dados do Salesforce sem copiá-los para uma tabela própria. A latência é quase em tempo real no momento da consulta; os dados vivem no Salesforce e o Snowflake os materializa sob demanda.

Pontos fortes: sem duplicação de dados, sem pipeline de ELT para manter, governança e linhagem tratadas no Data Cloud. Pontos fracos: exige licença do Salesforce Data Cloud (um SKU separado), é somente leitura do lado do Snowflake, e os padrões de acesso são de tempo de consulta, não de streaming. Ideal para times de analytics que já estão no Data Cloud.

Caminho 2 — ELT em lote (Fivetran, Airbyte, Stitch)

O padrão analítico convencional. Fivetran ou Airbyte roda numa agenda (de 5 minutos a 1 hora) extraindo do Salesforce via Bulk API 2.0 ou REST e carregando no Snowflake. Preço normalmente por linha; confiável em escala.

Pontos fortes: ferramental maduro, biblioteca forte de conectores, modelo operacional simples. Pontos fracos: piso de latência de lote (cadência de 5 minutos a 1 hora), o preço por linha escala com o volume, sem caminho bidirecional. Ideal quando a tolerância de latência é de 15 minutos ou mais e o caso é analytics unidirecional.

Caminho 3 — Plataformas de CDC em tempo real (Stacksync, Hightouch, Whalesync)

Uma plataforma de CDC gerenciada assina os eventos de CDC do Salesforce pela Pub/Sub API e os aplica num schema de pouso no Snowflake quase em tempo real. A latência costuma ficar abaixo de um minuto de ponta a ponta — a maioria das plataformas fica em 30 segundos a 2 minutos entre a mudança de um registro no Salesforce e a atualização da linha no Snowflake. Algumas plataformas (Stacksync) suportam também reverse-ETL — escrever scores ou dados enriquecidos de volta no Salesforce — sem uma ferramenta separada.

Pontos fortes: latência abaixo de um minuto, uma plataforma só para os caminhos de ida e volta, preço de assinatura transparente. Pontos fracos: categoria mais nova que o ELT em lote, seleção de fornecedores mais estreita. Ideal para analytics em tempo real, necessidades multi-destino e casos de reverse-ETL.

Comparação lado a lado

A decisão normalmente se reduz a uma pergunta: latência abaixo de um minuto é requisito duro?

Quando o zero-copy share ganha

Três sinais.

Você já está no Data Cloud. A licença é custo afundado. O padrão de zero-copy share vem incluído ou custa pouco. Você não constrói pipeline de ELT nenhum.

Sua analytics é somente leitura. Sem reverse-ETL. Sem scores de modelos escritos de volta no Salesforce. Cargas puramente de consulta no Snowflake contra dados do Salesforce. O padrão zero-copy encaixa perfeitamente.

Requisitos fortes de governança e linhagem. O Data Cloud trata controles de acesso no nível de linha e linhagem de um jeito que os pipelines de ELT precisam replicar na mão. Setores regulados ganham isso de graça.

Quando o ELT em lote ganha

Tolerância de latência de 15 minutos ou mais. A maioria dos dashboards de BI não precisa de frescor abaixo de um minuto. Se o seu time de analytics está bem com dados do Salesforce de 15 minutos atrás, Fivetran ou Airbyte são maduros e previsíveis.

Destino único, unidirecional. Sem reverse-ETL planejado. Sem um segundo destino (Snowflake mais Postgres, mais um terceiro). Analytics unidirecional simples.

Custo é a restrição principal. Em volume baixo e médio, Fivetran e Airbyte são competitivos em preço. Acima de 5M de registros do Salesforce por dia, o preço por linha costuma se inverter e o CDC gerenciado fica mais barato.

Quando o CDC em tempo real ganha

Latência abaixo de um minuto em dashboards de receita. Relatórios de RevOps que precisam bater com o Salesforce em 60 segundos. Atribuição por estágio de pipeline que quebra com 15 minutos de atraso. Dashboards de Customer 360 sustentando ferramentas operacionais.

Múltiplos destinos. Snowflake para analytics + um Postgres operacional para leituras da aplicação + Redis para caches de baixa latência. Uma plataforma de CDC em tempo real distribui um único stream para vários destinos de forma barata.

Necessidades bidirecionais. Reverse-ETL de scores de modelos (lead score, risco de churn, saúde do cliente) de volta para o Salesforce. A maioria das ferramentas de ELT em lote exige um produto de reverse-ETL separado (Hightouch, Census). Algumas plataformas de CDC em tempo real trazem as duas direções, incluindo a alternativa ao Heroku Connect da Stacksync.

A descontinuação do Heroku Connect força a re-arquitetura de qualquer jeito. A migração vai acontecer. Consolide numa única plataforma de tempo real em vez de reconstruir o padrão legado de dois saltos com um fornecedor novo.

Uma arquitetura de referência para Salesforce → Snowflake em tempo real

O padrão de 2026 para o qual os times convergem:

1. Fonte: CDC do Salesforce. Assine os eventos de CDC pela Pub/Sub API do Salesforce. Entrega de eventos abaixo de um segundo, janela de replay de 72 horas. Para a base arquitetural do CDC, veja nosso artigo complementar sobre Salesforce CDC vs Heroku Connect.
2. Carga inicial em massa. A Bulk API 2.0 do Salesforce preenche os registros históricos no schema de pouso do Snowflake. Coordene com o fluxo de CDC para que a virada seja exata.
3. Motor de sincronização. Uma plataforma de CDC gerenciada (por exemplo, a Stacksync) cuida do replay, do desvio de schema, da resolução de conflitos e da reconciliação. A alternativa auto-hospedada é o conector Salesforce CDC Source da Confluent mais um carregador próprio do Snowflake; cobrimos o trade-off em build vs buy: substituir o Heroku Connect com Debezium, Airbyte ou uma plataforma de sincronização gerenciada.
4. Destino: schema de pouso no Snowflake (camada raw). O schema espelha a estrutura dos objetos do Salesforce. Atualizado segundos após as mudanças na origem. Marcado como camada "raw" ou "bronze".
5. Transformação: dbt / SQL. Modelos construídos em cima da camada raw. Padrão clássico de analytics engineering. Os modelos incrementais do dbt funcionam bem porque a camada raw carrega metadados de CDC (timestamp do evento, tipo de mudança).
6. (Opcional) Reverse-ETL. Escreva os scores enriquecidos do Snowflake de volta no Salesforce. Ou pela mesma plataforma de CDC gerenciada (se suportar bidirecional) ou por uma ferramenta de reverse-ETL separada.

O resultado: latência de ponta a ponta de Salesforce para Snowflake na faixa de 30 segundos a 2 minutos, dependendo da plataforma e da cadência de execução do dbt. Abaixo de um minuto é alcançável.

E o Heroku Postgres no meio?

O padrão legado era Salesforce → Heroku Connect → Heroku Postgres → Fivetran → Snowflake. Dois saltos, dois produtos, dois relacionamentos com fornecedores, latência empilhando em cada camada.

Por que os times usavam: quando o Heroku Connect foi lançado em 2014, CDC em tempo real para um warehouse não era comercialmente viável. O Fivetran era a resposta certa para o ELT do lado do warehouse e o Heroku Connect era a resposta certa para o salto Salesforce–banco. Empilhá-los era razoável.

Por que os times estão removendo a camada de Heroku Postgres em 2026: o padrão moderno (CDC → Snowflake direto) entrega latência abaixo de um minuto num salto só, com um fornecedor e uma fatura. O relé do Heroku Postgres adiciona 10 minutos de latência de polling e custos de licença sem resolver nenhum problema novo. Com a Heroku em sustaining mode, o argumento operacional para manter o relé desaba por completo.

A sequência de migração que a maioria dos times segue: migrar primeiro a analytics (Salesforce → Snowflake direto), depois as leituras operacionais (Salesforce → Postgres moderno direto) e então desativar o Heroku Connect e o Heroku Postgres. A analytics costuma ter menos risco e ser mais rápida de validar que a sincronização operacional, então vai na frente.

Casos de uso concretos de RevOps

Onde o padrão Salesforce–Snowflake abaixo de um minuto importa na prática.

Atribuição de estágio de pipeline em tempo real. Dashboards de receita mostrando a movimentação do pipeline em menos de 60 segundos após uma mudança de estágio no Salesforce. Crítico para os ciclos semanais de forecast de sales-ops.

Dashboards de Customer 360. Ferramentas operacionais que mostram o estado do cliente batendo com o Salesforce abaixo de um minuto. Fluxos de suporte, sucesso do cliente e gestão de contas dependem disso.

Reverse-ETL de scores de modelos. Lead score, risco de churn, saúde do cliente, propensão de compra — calculados no Snowflake ou numa plataforma de ML separada, escritos de volta no Salesforce como campos do objeto Account ou Contact. Os vendedores veem o score na visão do Salesforce; o time de analytics é dono do modelo.

Rollups analíticos multi-org / multi-tenant. Empresas SaaS com orgs do Salesforce por cliente consolidando-as num único schema do Snowflake para analytics entre tenants. Os streams de CDC de cada org pousam em tabelas isoladas por tenant; os modelos do dbt agregam por cima.

Razões comuns para ficar no padrão legado

Duas reais.

Cargas existentes no Heroku Postgres. Se há aplicações lendo do Heroku Postgres em produção, você não pode desativá-lo só porque a analytics migrou. A sequência vira: analytics primeiro (Salesforce → Snowflake direto, com o Heroku Postgres ainda rodando para leituras operacionais), depois as leituras operacionais (Salesforce → Postgres moderno direto) e então desligar o Heroku Connect.

Aplicações operacionais com pouca tolerância a latência. Algumas aplicações não toleram nem janelas breves de migração. O padrão shadow-and-cutover resolve: rode a nova sincronização em paralelo por 14 dias, valide, vire o tráfego de escrita e depois o de leitura. Está coberto em detalhe no nosso guia de migração pelo fim de vida do Heroku Connect e no manual da Stacksync sobre substituir o Heroku Connect com sincronização em tempo real.

Perguntas frequentes

O Heroku Connect consegue sincronizar com o Snowflake?
Não. O Heroku Connect só escreve no Heroku Postgres. Para levar dados do Salesforce ao Snowflake usando o Heroku Connect você precisa adicionar um segundo salto: Heroku Postgres → Fivetran (ou ELT similar) → Snowflake. O padrão de dois saltos funciona, mas adiciona latência e um segundo fornecedor. Times modernos pulam o relé por completo.

Qual é a forma de menor latência de levar dados do Salesforce ao Snowflake?
As plataformas de CDC em tempo real (Stacksync, Hightouch, Whalesync) entregam latência abaixo de um minuto assinando os eventos de CDC do Salesforce pela Pub/Sub API e escrevendo em schemas de pouso do Snowflake. De ponta a ponta, da mudança de um registro à atualização da linha: normalmente de 30 segundos a 2 minutos.

O Salesforce Data Cloud é a mesma coisa que o Snowflake?
Não. O Salesforce Data Cloud é a camada de plataforma de dados de cliente da Salesforce. Ele suporta um zero-copy share com o Snowflake, o que significa que o Snowflake pode consultar dados do Data Cloud sem copiá-los. São produtos distintos que se integram; o Data Cloud não substitui o Snowflake nem o Snowflake substitui o Data Cloud.

O Fivetran suporta sincronização do Salesforce em tempo real?
Não no sentido de abaixo de um minuto. A cadência típica de sincronização do Salesforce no Fivetran vai de 5 minutos a 1 hora, dependendo da faixa e da configuração do conector. Para latência abaixo de um minuto, o formato certo são as plataformas de CDC em tempo real que assinam a Pub/Sub API, não o Fivetran.

Dá para fazer reverse-ETL do Snowflake de volta para o Salesforce?
Sim, com o ferramental certo. Produtos de reverse-ETL independentes (Hightouch, Census) cobrem isso. Algumas plataformas de CDC em tempo real (Stacksync) trazem sincronização bidirecional embutida, eliminando a necessidade de uma ferramenta separada. O reverse-ETL é o padrão para escrever scores de modelos, campos enriquecidos ou métricas agregadas do Snowflake de volta nos registros do Salesforce.

Como a Stacksync se compara ao Hightouch para sincronização com warehouse?
O Hightouch é reverse-ETL primeiro (Snowflake → Salesforce) com recursos fortes de ativação. A Stacksync é sincronização bidirecional primeiro (Salesforce ↔ Snowflake ou Postgres), com as duas direções numa plataforma. A escolha depende de qual direção é o caso de uso principal: se você precisa sobretudo de ativação de warehouse para SaaS, o Hightouch encaixa. Se precisa de bidirecional em tempo real, a Stacksync encaixa.

Qual é a forma mais barata de substituir o Heroku Connect para analytics?
Duas opções normalmente ganham no custo. (1) Uma plataforma de CDC em tempo real escrevendo direto no Snowflake, que elimina o relé do Heroku Postgres por completo. (2) ELT em lote (Fivetran, Airbyte) se 15 minutos de latência forem aceitáveis. As duas costumam ficar abaixo do custo do stack legado de dois saltos.

Dá para rodar CDC em tempo real ao lado de um pipeline existente de Heroku Connect durante a migração?
Sim, e é o padrão recomendado. Rode a nova plataforma de CDC escrevendo num schema ou banco do Snowflake separado por 14 dias enquanto o Heroku Connect continua escrevendo no Heroku Postgres. Reconcilie a integridade dos dados. Vire o tráfego de analytics para o novo pipeline. Migre as leituras operacionais depois. Desative o Heroku Connect por último.

Fechamento — Sequência de migração

Três passos para um time de analytics migrar para fora do padrão Heroku Connect → Heroku Postgres → Fivetran:

1. Escolha o caminho. Latência abaixo de um minuto exigida → plataforma de CDC em tempo real. Tolerância de 15 minutos → ELT em lote. Já no Data Cloud → zero-copy share.
2. Suba o novo pipeline em paralelo. Schema de pouso no Snowflake, mapeado para os seus objetos do Salesforce. Rode em modo shadow por 14 dias. Reconcilie contra o schema do Snowflake existente (o que você usa hoje pela rota legada).
3. Vire primeiro a analytics, depois as operações. Analytics primeiro: menor risco, mais fácil de validar. Quando estiver estável, planeje a migração das leituras operacionais e desative o Heroku Connect.

A alternativa ao Heroku Connect da Stacksync explica como é o caminho de plataforma gerenciada tanto para analytics quanto para casos operacionais.

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 — Snowflake as a Salesforce Data Cloud partner: https://www.salesforce.com/data/partners/snowflake/
• 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 — Bulk API 2.0: https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm
• Snowflake — Data Loading Overview: https://docs.snowflake.com/en/user-guide/data-load-overview
• Heroku Dev Center — Heroku Connect documentation: https://devcenter.heroku.com/articles/heroku-connect
• Fivetran — Salesforce connector: https://www.fivetran.com/connectors/salesforce