Salesforce Change Data Capture vs Heroku Connect: per què el CDC tot sol no n'hi ha prou per a la sincronització operativa en temps real

Salesforce CDC és un flux d'esdeveniments gairebé en temps real sobre la Pub/Sub API. Heroku Connect és sincronització bidireccional basada en polling amb un interval mínim de 10 minuts. Resolen problemes diferents: el CDC emet esdeveniments amb latència per sota del segon, Heroku Connect manté estat i escriptures en tots dos sentits. La majoria d'equips en producció necessita totes dues coses — CDC més replay, resolució de conflictes i escriptura de tornada. Aquesta és la comparació honesta.

La pregunta va passar de teòrica a urgent el 6 de febrer del 2026, quan Salesforce va posar Heroku en sustaining engineering mode i els equips d'enginyeria van començar a reavaluar si continuaven pagant Heroku Connect o construïen ells mateixos sobre CDC. Per a l'enquadrament de la urgència de la migració, mira el nostre article complementari sobre el final de vida d'Heroku Connect. Per a una mirada de prop a les rutes amb destí warehouse que se salten Heroku del tot, mira sincronització en temps real de Salesforce a Snowflake sense Heroku Connect.

Què és realment Salesforce CDC

Salesforce Change Data Capture és la primitiva de streaming d'esdeveniments de la plataforma Salesforce. Quan un registre de qualsevol objecte subscrit es crea, s'actualitza, s'esborra o es restaura, Salesforce publica un esdeveniment de canvi. Els consumidors reben aquests esdeveniments a través de la Pub/Sub API, un endpoint de streaming gRPC que va substituir l'antic streaming basat en CometD. La referència canònica és la documentació de CDC de Salesforce Developers.

Uns quants detalls importen per a la comparació:

• Els esdeveniments CDC porten els camps modificats i un replay ID. Els consumidors poden reprendre el flux des d'un replay ID concret dins d'una finestra de retenció de 72 hores.
• El lliurament és at-least-once. Els consumidors han de desduplicar per l'ID de l'esdeveniment de canvi.
• Els esdeveniments CDC són unidireccionals: Salesforce → consumidor. No hi ha primitiva d'escriptura de tornada.
• La Pub/Sub API es basa en gRPC, suporta payloads binaris Avro i és més eficient que l'antic streaming CometD. És el client recomanat.
• Salesforce fa passar els esdeveniments CDC per infraestructura interna, de manera que la latència sol estar per sota del segon de punta a punta, des que es desa un registre fins que el consumidor rep l'esdeveniment.

El CDC és un dels tres canals d'esdeveniments de Salesforce. Els altres dos són els Platform Events (esdeveniments personalitzats que publiques des d'Apex o APIs) i el Generic Streaming (heretat). Per a casos d'ús de sincronització, el CDC és el canal correcte: porta la semàntica real de canvi de registre que els equips necessiten.

Què fa realment Heroku Connect

Heroku Connect és una sincronització bidireccional gestionada entre Salesforce i Heroku Postgres. L'arquitectura és radicalment diferent de la del CDC. Segons la documentació de rendiment del Heroku Dev Center, Heroku Connect funciona amb un model de polling amb un interval mínim de 10 minuts. Consulta Salesforce segons un calendari, recupera els registres modificats i els escriu en un esquema de Postgres equivalent.

Tres coses destaquen:

1. Heroku Connect manté estat — el teu esquema de Postgres és una rèplica consultable dels objectes de Salesforce. El CDC, tot sol, no produeix una rèplica; produeix un flux.
2. Heroku Connect és bidireccional. Quan canvia una fila de Postgres, Heroku Connect escriu el canvi de tornada a Salesforce en el mateix cicle de polling. El CDC no té ruta d'escriptura integrada.
3. El polling d'Heroku Connect consumeix la quota d'API de Salesforce. Segons el centre d'ajuda d'Heroku, Heroku Connect contribueix al límit de la streaming API de la teva org — cosa que significa que un desplegament actiu pot estrangular altres integracions de Salesforce.

Heroku Connect és la resposta heretada a "vull dades de Salesforce en una base de dades relacional, amb escriptures en tots dos sentits, sense escriure el meu propi pipeline". Funciona, però és un producte de l'era del polling, i les seves contrapartides (latència, dependència d'Heroku Postgres, risc estratègic del sustaining mode) ja s'entenen bé.

Comparativa costat a costat

La taula mapeja tots dos sobre les set dimensions que importen en sincronització de producció. Fixa't en la columna de la dreta, que recull el que els equips realment necessiten: amb quina freqüència ni el CDC sol ni Heroku Connect sol ho cobreixen.

Llegeix cada fila d'esquerra a dreta. On la columna de "necessiten de debò" coincideix amb el CDC, pots fer servir només CDC. On coincideix amb Heroku Connect, pots fer servir només Heroku Connect. La majoria de files no coincideix amb cap dels dos. Aquesta és la realitat arquitectònica.

Què pots construir només amb Salesforce CDC

El CDC tot sol resol bé una classe concreta de problemes.

Fluxos unidireccionals cap a un processador de streams. Si ja operes Kafka, Kinesis o AWS EventBridge, el CDC encaixa netament. El client de la Pub/Sub API emet esdeveniments al teu processador de streams i els consumidors aigües avall fan el que necessitin. És el patró que Salesforce recomana oficialment per a aplicacions orientades a esdeveniments.

Vistes materialitzades en un warehouse. Molts equips porten esdeveniments CDC a un esquema d'aterratge a Snowflake / BigQuery / Databricks i transformen des d'allà amb dbt. La latència és de menys d'un minut de punta a punta, els costos són baixos (pagues ingesta de Snowflake més consum de Pub/Sub API) i l'arquitectura és directa.

Memòries cau operatives de només lectura. Si necessites una memòria cau a Postgres o Redis de dades de Salesforce per a aplicacions amb molta lectura, CDC més un consumidor lleuger que la mantingui funciona. El detall: cal tractar els esborrats amb cura (el CDC els reporta, però els consumidors els han de processar, no saltar-se'ls).

On s'acaba el CDC. El CDC tot sol no pot:

• Escriure de tornada a Salesforce (no hi ha primitiva d'escriptura)
• Reproduir esdeveniments de més de 72 hores
• Fer una càrrega inicial massiva (el CDC és incremental; el backfill necessita Bulk API 2.0)
• Detectar deriva d'esquema al teu destí
• Resoldre conflictes entre Salesforce i un destí escrivible

Què no pots construir només amb CDC — i què resolia Heroku Connect

La proposta de valor original d'Heroku Connect era: no construeixis un pipeline de sincronització; nosaltres mantenim una rèplica a Postgres amb escriptures en tots dos sentits. Per replicar aquest resultat amb CDC cal construir cinc capes addicionals.

Escriptura bidireccional de tornada. La REST API de Salesforce o la Bulk API 2.0 gestionen les escriptures cap a Salesforce. Necessites claus d'idempotència per evitar escriptures dobles en els reintents, lògica de desduplicació per evitar bucles entre els esdeveniments CDC i les teves pròpies escriptures, i gestió de rate limits perquè la REST API té límits a nivell d'org.

Càrrega inicial massiva. El CDC és incremental. Per poblar un destí des de zero, recuperes les dades existents amb Bulk API 2.0 i després comences a consumir CDC des d'un replay ID que se solapi amb el timestamp de la càrrega. Mal fet, acabes amb files duplicades o files perdudes. La majoria d'equips subestima quanta enginyeria demana això.

Esborrats definitius. El CDC reporta els esborrats, però Salesforce esborra definitivament en passar la finestra de la paperera. Si el teu consumidor de CDC està caigut durant l'esdeveniment d'esborrat definitiu, perds l'oportunitat d'aplicar-lo. Heroku Connect ho resol com a part del seu cicle normal de polling.

Replay més enllà de 72 hores. Si el teu consumidor està caigut 73 hores (una incidència llarga, un desplegament que surt malament, un debug de diversos dies), el CDC no t'ajuda a posar-te al dia. Necessites o bé un topic de Kafka davant del consumidor amb retenció més llarga, o bé una tasca periòdica de reconciliació completa que compari el teu destí contra una instantània de Bulk API.

Detecció de deriva d'esquema. Els administradors de Salesforce afegeixen camps. Apareixen camps personalitzats. L'esdeveniment CDC porta el camp nou; el teu destí no té columna per a ell; el canvi desapareix en silenci. Necessites una capa que detecti canvis d'esquema als esdeveniments CDC i que faci evolucionar l'esquema del destí o alerti.

Aquestes cinc capes són les que converteixen un flux de CDC en un sistema de sincronització preparat per a producció. O les construeixes, o adoptes una plataforma gestionada que les porti incloses. Cobrim l'anàlisi de build vs buy en detall a l'article complementari sobre build vs buy: substituir Heroku Connect amb Debezium, Airbyte o una plataforma de sincronització gestionada.

L'arquitectura cap a la qual convergeixen els equips (post-Heroku-Connect)

Un stack modern de sincronització de Salesforce el 2026 sol tenir aquestes capes, tant si construeixes com si compres:

Salesforce
   │ (esdeveniments CDC via Pub/Sub API; Bulk API 2.0 per a la càrrega inicial)
   ▼
Consumidor de stream (topic de Kafka, plataforma CDC gestionada o client gRPC propi)
   │
   ├──► Rèplica a Postgres (lectures operatives)
   ├──► Snowflake / BigQuery (analítica)
   └──► Ruta inversa: escriptura de tornada via REST o Bulk API 2.0
        amb idempotència + desduplicació + resolució de conflictes

Que les caixes d'aquest diagrama siguin una plataforma gestionada (Stacksync, Whalesync, Bracket) o un stack autoallotjat (consumidor estil Debezium + Kafka + escriptura de tornada pròpia) és la pregunta de build vs buy. La forma de l'arquitectura és la mateixa.

Aquest és el patró en el qual Heroku Connect no es va poder convertir. El seu model de polling és, en el fons, d'un sol nivell. No hi ha flux d'esdeveniments, ni log reproduïble, ni ruta d'escriptura independent del cicle de polling. Per arribar a la forma moderna cal sortir d'Heroku Connect: no existeix cap actualització in situ. Per a més detall sobre els seus límits arquitectònics concrets, mira l'anàlisi a fons dels límits d'arquitectura d'Heroku Connect de Stacksync.

Quan n'hi ha prou amb el CDC

Alguns equips genuïnament no necessiten l'stack complet. El CDC sol encaixa quan:

• El destí és de només lectura. Warehouses analítics, índexs de cerca, memòries cau.
• El replay de 72 hores és suficient. El teu consumidor té alta disponibilitat i finestres de caiguda curtes.
• No necessites càrrega inicial massiva. El sistema és nou; pot arrencar a l'estat actual.
• El volum de dades és moderat. El throughput de la Pub/Sub API és suficient; no necessites Kafka al davant.
• Ja operes una plataforma de streaming en producció (Kafka, Kinesis, EventBridge).

Si marques les cinc caselles, porta el CDC directament a la teva plataforma de streaming i salta't la pregunta de la sincronització gestionada.

Quan necessites més que el CDC

La majoria d'equips en producció necessita més. Els dos indicadors forts:

Tens un cas d'ús operatiu. Aplicacions de cara al client que llegeixen dades derivades de Salesforce, eines de suport que escriuen de tornada a Salesforce, automatització de RevOps que actualitza registres a partir de models del warehouse. Operatiu vol dir escriptures en tots dos sentits, la resolució de conflictes importa i la caiguda fa mal.

Tens un desplegament de Salesforce multi-org o multi-tenant. Cada org té el seu propi flux CDC, els seus propis límits d'API, el seu propi esquema. Agregar entre orgs exigeix encaminament per tenant, resolució de conflictes conscient del tenant i observabilitat que et deixi veure la salut per tenant. Construir això des de les primitives del CDC és enginyeria de diversos trimestres. Les plataformes gestionades solen incloure-ho.

Si se t'aplica qualsevol dels dos, no construeixis un sistema de sincronització només amb CDC. O adoptes una plataforma gestionada o et compromets a un desenvolupament de 3 a 6 mesos. No hi ha camí intermedi que funcioni en producció.

Preguntes freqüents

Salesforce CDC és un substitut d'Heroku Connect?
No, no tot sol. Salesforce CDC aporta la font d'esdeveniments de canvi, però no inclou sincronització bidireccional, mapatge d'esquema, resolució de conflictes, replay més enllà de 72 hores ni càrrega inicial massiva. Per replicar el resultat d'Heroku Connect necessites CDC més un consumidor, més Bulk API 2.0 per a la càrrega inicial, més una ruta d'escriptura de tornada, més detecció de deriva d'esquema. O construeixes aquest stack o fas servir una plataforma gestionada que el porti inclòs.

Puc fer servir Salesforce CDC per a sincronització bidireccional?
No. El CDC és un flux d'esdeveniments unidireccional de Salesforce cap als consumidors. Per escriure de tornada a Salesforce fas servir la REST API o la Bulk API 2.0 i gestiones tu la idempotència, la desduplicació i la resolució de conflictes. La sincronització bidireccional és la capa que va a sobre del CDC, no part del CDC.

Quina és la latència de Salesforce CDC?
La latència de punta a punta des que es desa un registre a Salesforce fins que un consumidor de la Pub/Sub API rep l'esdeveniment sol estar per sota del segon. La xifra exacta depèn de la profunditat de la cua interna de Salesforce, de la ubicació del teu consumidor respecte a la regió de Salesforce i de la salut de la connexió gRPC. Planifica per a menys d'1 segon en condicions normals; espera pics ocasionals de 2 a 5 segons sota càrrega.

Quant temps reté els esdeveniments Salesforce CDC?
La finestra de retenció del CDC és de 72 hores. Els consumidors poden reprendre un flux amb un replay ID desat fins a aquest horitzó. Els esdeveniments de més de 72 hores no estan disponibles; recuperar-los exigeix una reconciliació amb una instantània de Bulk API 2.0. Per a necessitats de retenció més llarga, encamina els esdeveniments CDC cap a un topic de Kafka amb un període de retenció configurable.

Salesforce CDC consumeix quota d'API?
Sí, però a un ritme molt menor que el polling. L'ús de la Pub/Sub API compta contra els límits de publicació d'esdeveniments de la streaming API, no contra els límits de crides síncrones de la REST API. Un desplegament d'Heroku Connect que fa polling cada 10 minuts sol consumir més pressupost d'API que un consumidor de CDC equivalent sobre Pub/Sub API, segons la documentació d'Heroku Help sobre els límits de la streaming API.

Quina diferència hi ha entre Salesforce CDC i els Platform Events?
Salesforce CDC publica esdeveniments de canvi de registre automàticament quan els objectes es creen, s'actualitzen, s'esborren o es restauren. Els Platform Events són esdeveniments personalitzats que el teu codi publica des d'Apex o APIs. El CDC és per a casos de sincronització (canvis d'estat de registre); els Platform Events són per a esdeveniments a nivell d'aplicació (un flux de treball propi que es dispara). Tots dos corren sobre la Pub/Sub API.

Puc escriure a Salesforce des d'una base de dades Postgres fent servir CDC?
No directament. El CDC va en la direcció equivocada: és Salesforce → consumidor, no consumidor → Salesforce. Per escriure des de Postgres cap a Salesforce necessites una ruta a part: normalment replicació lògica de Postgres o triggers que alimentin un consumidor que cridi la REST API o la Bulk API 2.0. Les plataformes gestionades de sincronització bidireccional (Stacksync inclosa) porten les dues direccions; construir des de primitives exigeix els dos pipelines.

Per què Heroku Connect no fa servir Salesforce CDC per sota?
Heroku Connect és anterior a la Pub/Sub API i a la forma actual del CDC. Salesforce no ha modernitzat Heroku Connect per fer servir CDC, i aquesta és una de les raons principals que el seu terra de latència sigui de 10 minuts: l'arquitectura de polling és estructural, no un paràmetre ajustable. Amb Heroku en sustaining mode, aquesta modernització és improbable.

Tancament — Propers passos per a equips que substitueixen Heroku Connect per un stack basat en CDC

Tres passos concrets:

1. Decideix si necessites bidireccional o unidireccional. Si amb unidireccional n'hi ha prou, un consumidor de CDC que aterri al teu warehouse és el camí més simple.
2. Si necessites bidireccional, decideix build vs buy. Resposta honesta: per sota de 100M d'esdeveniments al dia i amb menys de 5 enginyers de backend sèniors, compra. Per sobre d'això, o amb requisits de propietat estratègica, construeix. Ho desenvolupem a build vs buy: substituir Heroku Connect amb Debezium, Airbyte o una plataforma de sincronització gestionada.
3. Concreta les teves necessitats de latència i replay. "Temps real" significa coses diferents segons el volum. Si el teu SLA operatiu és "els canvis de Salesforce apareixen a Postgres en 5 segons", el disseny és un; si és "en 100 ms per a fluxos crítics d'ingressos", canvia bastant.

La pàgina de producte de Stacksync explica com es veu de punta a punta la sincronització bidireccional en temps real que escala en la ruta de comprar.

Sobre l'autor

Bruno Galo — Fundador, Atypical Tech

Bruno Galo és el fundador d'Atypical Tech, una consultora de NetSuite que treballa amb clients del mercat mitjà a tota la Península Ibèrica. Està especialitzat a connectar sistemes CRM i ERP per aconseguir fluxos d'order-to-cash sense friccions, construint pipelines automatitzats de gestió de comandes que eliminen l'entrada manual de dades entre els equips de vendes i finances. Com a partner oficial d'implementació de Stacksync, en Bruno dissenya i desplega agents d'IA sobre plataformes d'integració per gestionar l'encaminament d'excepcions, el processament de documents i la conciliació — convertint fluxos de comandes fragmentats en sistemes fiables que es monitoren a si mateixos.

LinkedIn

Fonts

• 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