Salesforce Change Data Capture vs Heroku Connect: por qué CDC por sí solo no basta para la sincronización operativa en tiempo real

Salesforce CDC es un flujo de eventos casi en tiempo real sobre la Pub/Sub API. Heroku Connect es sincronización bidireccional basada en polling con un intervalo mínimo de 10 minutos. Resuelven problemas distintos: CDC emite eventos con latencia por debajo del segundo, Heroku Connect mantiene estado y escrituras en ambos sentidos. La mayoría de equipos en producción necesita las dos cosas — CDC más replay, resolución de conflictos y escritura de vuelta. Esta es la comparación honesta.

La pregunta pasó de teórica a urgente el 6 de febrero de 2026, cuando Salesforce puso Heroku en sustaining engineering mode y los equipos de ingeniería empezaron a reevaluar si seguir pagando Heroku Connect o construir ellos mismos sobre CDC. Para el encuadre de urgencia de la migración, mira nuestro artículo complementario sobre el fin de vida de Heroku Connect. Para un análisis de las rutas con destino warehouse que se saltan Heroku por completo, mira sincronización en tiempo real de Salesforce a Snowflake sin Heroku Connect.

Qué es realmente Salesforce CDC

Salesforce Change Data Capture es la primitiva de streaming de eventos de la plataforma Salesforce. Cuando un registro de cualquier objeto suscrito se crea, actualiza, borra o restaura, Salesforce publica un evento de cambio. Los consumidores reciben esos eventos a través de la Pub/Sub API, un endpoint de streaming gRPC que sustituyó al antiguo streaming basado en CometD. La referencia canónica es la documentación de CDC de Salesforce Developers.

Unos cuantos detalles importan para la comparación:

• Los eventos CDC llevan los campos modificados y un replay ID. Los consumidores pueden retomar el flujo desde un replay ID concreto dentro de una ventana de retención de 72 horas.
• La entrega es at-least-once. Los consumidores tienen que deduplicar por el ID del evento de cambio.
• Los eventos CDC son unidireccionales: Salesforce → consumidor. No hay primitiva de escritura de vuelta.
• La Pub/Sub API se basa en gRPC, soporta payloads binarios Avro y es más eficiente que el antiguo streaming CometD. Es el cliente recomendado.
• Salesforce hace pasar los eventos CDC por infraestructura interna, así que la latencia suele estar por debajo del segundo de punta a punta, desde que se guarda un registro hasta que el consumidor recibe el evento.

CDC es uno de los tres canales de eventos de Salesforce. Los otros dos son los Platform Events (eventos personalizados que publicas desde Apex o APIs) y el Generic Streaming (heredado). Para casos de uso de sincronización, CDC es el canal correcto: lleva la semántica real de cambio de registro que los equipos necesitan.

Qué hace realmente Heroku Connect

Heroku Connect es una sincronización bidireccional gestionada entre Salesforce y Heroku Postgres. La arquitectura es radicalmente distinta a la de CDC. Según la documentación de rendimiento del Heroku Dev Center, Heroku Connect funciona con un modelo de polling con un intervalo mínimo de 10 minutos. Consulta Salesforce según un calendario, recupera los registros modificados y los escribe en un esquema de Postgres equivalente.

Tres cosas destacan:

1. Heroku Connect mantiene estado — tu esquema de Postgres es una réplica consultable de los objetos de Salesforce. CDC, por sí solo, no produce una réplica; produce un flujo.
2. Heroku Connect es bidireccional. Cuando cambia una fila de Postgres, Heroku Connect escribe el cambio de vuelta en Salesforce en el mismo ciclo de polling. CDC no tiene ruta de escritura integrada.
3. El polling de Heroku Connect consume la cuota de API de Salesforce. Según el centro de ayuda de Heroku, Heroku Connect contribuye al límite de la streaming API de tu org — lo que significa que un despliegue ocupado puede estrangular otras integraciones de Salesforce.

Heroku Connect es la respuesta heredada a "quiero datos de Salesforce en una base de datos relacional, con escrituras en ambos sentidos, sin escribir mi propio pipeline". Funciona, pero es un producto de la era del polling, y sus contrapartidas (latencia, dependencia de Heroku Postgres, riesgo estratégico del sustaining mode) ya se entienden bien.

Comparativa lado a lado

La tabla mapea los dos sobre las siete dimensiones que importan en sincronización de producción. Fíjate en la columna de la derecha, que recoge lo que los equipos realmente necesitan: con qué frecuencia ni CDC solo ni Heroku Connect solo lo cubren.

Lee cada fila de izquierda a derecha. Donde la columna de "necesitan de verdad" coincide con CDC, puedes usar CDC solo. Donde coincide con Heroku Connect, puedes usar Heroku Connect solo. La mayoría de las filas no coincide con ninguno. Esa es la realidad arquitectónica.

Qué puedes construir solo con Salesforce CDC

CDC por sí solo resuelve bien una clase concreta de problemas.

Flujos unidireccionales hacia un procesador de streams. Si ya operas Kafka, Kinesis o AWS EventBridge, CDC encaja limpiamente. El cliente de la Pub/Sub API emite eventos a tu procesador de streams y los consumidores de aguas abajo hacen lo que necesiten. Es el patrón que Salesforce recomienda oficialmente para aplicaciones event-driven.

Vistas materializadas en un warehouse. Muchos equipos llevan eventos CDC a un esquema de aterrizaje en Snowflake / BigQuery / Databricks y transforman desde ahí con dbt. La latencia es de menos de un minuto de punta a punta, los costes son bajos (pagas ingesta de Snowflake más consumo de Pub/Sub API) y la arquitectura es directa.

Cachés operativas de solo lectura. Si necesitas una caché en Postgres o Redis de datos de Salesforce para aplicaciones con mucha lectura, CDC más un consumidor ligero que mantenga la caché funciona. El detalle: hay que tratar los borrados con cuidado (CDC los reporta, pero los consumidores tienen que procesarlos, no saltárselos).

Dónde se acaba CDC. CDC por sí solo no puede:

• Escribir de vuelta en Salesforce (no hay primitiva de escritura)
• Reproducir eventos de más de 72 horas
• Hacer una carga inicial masiva (CDC es incremental; el backfill necesita Bulk API 2.0)
• Detectar deriva de esquema en tu destino
• Resolver conflictos entre Salesforce y un destino escribible

Qué no puedes construir solo con CDC — y qué resolvía Heroku Connect

La propuesta de valor original de Heroku Connect era: no construyas un pipeline de sincronización; nosotros mantenemos una réplica en Postgres con escrituras en ambos sentidos. Para replicar ese resultado con CDC hay que construir cinco capas adicionales.

Escritura bidireccional de vuelta. La REST API de Salesforce o la Bulk API 2.0 gestionan las escrituras hacia Salesforce. Necesitas claves de idempotencia para evitar escrituras dobles en los reintentos, lógica de deduplicación para evitar bucles entre los eventos CDC y tus propias escrituras, y manejo de rate limits porque la REST API tiene límites a nivel de org.

Carga inicial masiva. CDC es incremental. Para poblar un destino desde cero, recuperas los datos existentes con Bulk API 2.0 y luego empiezas a consumir CDC desde un replay ID que solape con el timestamp de la carga. Mal hecho, acabas con filas duplicadas o filas perdidas. La mayoría de equipos subestima cuánta ingeniería requiere esto.

Borrados en firme. CDC reporta los borrados, pero Salesforce borra en firme al pasar la ventana de la papelera. Si tu consumidor de CDC está caído durante el evento de borrado en firme, pierdes la oportunidad de aplicarlo. Heroku Connect lo resuelve como parte de su ciclo normal de polling.

Replay más allá de 72 horas. Si tu consumidor está caído 73 horas (una incidencia larga, un despliegue que sale mal, un debug de varios días), CDC no te ayuda a ponerte al día. Necesitas o bien un topic de Kafka delante de tu consumidor con retención más larga, o bien un trabajo periódico de reconciliación completa que compare tu destino contra un snapshot de Bulk API.

Detección de deriva de esquema. Los administradores de Salesforce añaden campos. Aparecen campos personalizados. El evento CDC trae el campo nuevo; tu destino no tiene columna para él; el cambio desaparece en silencio. Necesitas una capa que detecte cambios de esquema en los eventos CDC y que evolucione el esquema del destino o alerte.

Estas cinco capas son las que convierten un flujo de CDC en un sistema de sincronización listo para producción. O las construyes, o adoptas una plataforma gestionada que las traiga incluidas. Cubrimos el análisis de build vs buy en detalle en nuestro artículo complementario sobre build vs buy: reemplazar Heroku Connect con Debezium, Airbyte o una plataforma de sincronización gestionada.

La arquitectura hacia la que están convergiendo los equipos (post-Heroku-Connect)

Un stack moderno de sincronización de Salesforce en 2026 suele tener estas capas, tanto si construyes como si compras:

Salesforce
   │ (eventos CDC vía Pub/Sub API; Bulk API 2.0 para la carga inicial)
   ▼
Consumidor de stream (topic de Kafka, plataforma CDC gestionada o cliente gRPC propio)
   │
   ├──► Réplica en Postgres (lecturas operativas)
   ├──► Snowflake / BigQuery (analítica)
   └──► Ruta inversa: escritura de vuelta vía REST o Bulk API 2.0
        con idempotencia + deduplicación + resolución de conflictos

Que las cajas de este diagrama sean una plataforma gestionada (Stacksync, Whalesync, Bracket) o un stack auto-alojado (consumidor estilo Debezium + Kafka + escritura de vuelta propia) es la pregunta de build vs buy. La forma de la arquitectura es la misma.

Este es el patrón en el que Heroku Connect no pudo convertirse. Su modelo de polling es, en el fondo, de un solo nivel. No hay flujo de eventos, ni log reproducible, ni ruta de escritura independiente del ciclo de polling. Para llegar a la forma moderna hay que salir de Heroku Connect: no existe actualización in situ. Para más detalle sobre sus límites arquitectónicos concretos, mira el análisis a fondo de los límites de arquitectura de Heroku Connect de Stacksync.

Cuándo basta con CDC

Algunos equipos genuinamente no necesitan el stack completo. CDC solo encaja cuando:

• El destino es de solo lectura. Warehouses analíticos, índices de búsqueda, cachés.
• El replay de 72 horas es suficiente. Tu consumidor tiene alta disponibilidad y ventanas de caída cortas.
• No necesitas carga inicial masiva. El sistema es nuevo; puede arrancar en el estado actual.
• El volumen de datos es moderado. El throughput de la Pub/Sub API basta; no necesitas Kafka delante.
• Ya operas una plataforma de streaming en producción (Kafka, Kinesis, EventBridge).

Si marcas las cinco casillas, mete CDC directamente en tu plataforma de streaming y sáltate la pregunta de la sincronización gestionada.

Cuándo necesitas más que CDC

La mayoría de equipos en producción necesita más. Los dos indicadores fuertes:

Tienes un caso de uso operativo. Aplicaciones de cara al cliente que leen datos derivados de Salesforce, herramientas de soporte que escriben de vuelta en Salesforce, automatización de RevOps que actualiza registros a partir de modelos del warehouse. Operativo significa escrituras en ambos sentidos, la resolución de conflictos importa y la caída duele.

Tienes un despliegue de Salesforce multi-org o multi-tenant. Cada org tiene su propio flujo CDC, sus propios límites de API, su propio esquema. Agregar entre orgs exige enrutado por tenant, resolución de conflictos consciente del tenant y observabilidad que te deje ver la salud por tenant. Construir esto desde las primitivas de CDC es ingeniería de varios trimestres. Las plataformas gestionadas suelen incluirlo.

Si te aplica cualquiera de los dos, no construyas un sistema de sincronización solo con CDC. O adoptas una plataforma gestionada o te comprometes a un desarrollo de 3 a 6 meses. No hay camino intermedio que funcione en producción.

Preguntas frecuentes

¿Es Salesforce CDC un reemplazo de Heroku Connect?
No, no por sí solo. Salesforce CDC aporta la fuente de eventos de cambio, pero no incluye sincronización bidireccional, mapeo de esquema, resolución de conflictos, replay más allá de 72 horas ni carga inicial masiva. Para replicar el resultado de Heroku Connect necesitas CDC más un consumidor, más Bulk API 2.0 para la carga inicial, más una ruta de escritura de vuelta, más detección de deriva de esquema. O construyes ese stack o usas una plataforma gestionada que lo traiga incluido.

¿Puedo usar Salesforce CDC para sincronización bidireccional?
No. CDC es un flujo de eventos unidireccional de Salesforce a los consumidores. Para escribir de vuelta en Salesforce usas la REST API o la Bulk API 2.0 y gestionas tú la idempotencia, la deduplicación y la resolución de conflictos. La sincronización bidireccional es la capa que va encima de CDC, no parte de CDC.

¿Cuál es la latencia de Salesforce CDC?
La latencia de punta a punta desde que se guarda un registro en Salesforce hasta que un consumidor de la Pub/Sub API recibe el evento suele estar por debajo del segundo. La cifra exacta depende de la profundidad de la cola interna de Salesforce, de la ubicación de tu consumidor respecto a la región de Salesforce y de la salud de la conexión gRPC. Planifica para menos de 1 segundo en condiciones normales; espera picos ocasionales de 2 a 5 segundos bajo carga.

¿Cuánto tiempo retiene los eventos Salesforce CDC?
La ventana de retención de CDC es de 72 horas. Los consumidores pueden retomar un flujo con un replay ID guardado hasta ese horizonte. Los eventos de más de 72 horas no están disponibles; recuperarlos exige una reconciliación con un snapshot de Bulk API 2.0. Para necesidades de retención más larga, enruta los eventos CDC a un topic de Kafka con un periodo de retención configurable.

¿Salesforce CDC consume cuota de API?
Sí, pero a un ritmo mucho menor que el polling. El uso de la Pub/Sub API cuenta contra los límites de publicación de eventos de la streaming API, no contra los límites de llamadas síncronas de la REST API. Un despliegue de Heroku Connect que hace polling cada 10 minutos suele consumir más presupuesto de API que un consumidor de CDC equivalente sobre Pub/Sub API, según la documentación de Heroku Help sobre los límites de la streaming API.

¿Cuál es la diferencia entre Salesforce CDC y los Platform Events?
Salesforce CDC publica eventos de cambio de registro automáticamente cuando los objetos se crean, actualizan, borran o restauran. Los Platform Events son eventos personalizados que tu código publica desde Apex o APIs. CDC es para casos de sincronización (cambios de estado de registro); los Platform Events son para eventos de nivel de aplicación (un flujo de trabajo propio que se dispara). Ambos corren sobre la Pub/Sub API.

¿Puedo escribir en Salesforce desde una base de datos Postgres usando CDC?
No directamente. CDC va en la dirección equivocada: es Salesforce → consumidor, no consumidor → Salesforce. Para escribir desde Postgres hacia Salesforce necesitas una ruta aparte: normalmente replicación lógica de Postgres o triggers que alimenten un consumidor que llame a la REST API o a la Bulk API 2.0. Las plataformas gestionadas de sincronización bidireccional (Stacksync incluida) traen las dos direcciones; construir desde primitivas exige los dos pipelines.

¿Por qué Heroku Connect no usa Salesforce CDC por debajo?
Heroku Connect es anterior a la Pub/Sub API y a la forma actual de CDC. Salesforce no ha modernizado Heroku Connect para usar CDC, y esa es una de las razones principales de que su suelo de latencia sea de 10 minutos: la arquitectura de polling es estructural, no un parámetro ajustable. Con Heroku en sustaining mode, esa modernización es improbable.

Cierre — Próximos pasos para equipos que sustituyen Heroku Connect por un stack basado en CDC

Tres pasos concretos:

1. Decide si necesitas bidireccional o unidireccional. Si con unidireccional basta, un consumidor de CDC que aterrice en tu warehouse es el camino más simple.
2. Si necesitas bidireccional, decide build vs buy. Respuesta honesta: por debajo de 100M de eventos al día y con menos de 5 ingenieros de backend sénior, compra. Por encima de eso, o con requisitos de propiedad estratégica, construye. Lo desarrollamos en build vs buy: reemplazar Heroku Connect con Debezium, Airbyte o una plataforma de sincronización gestionada.
3. Concreta tus necesidades de latencia y replay. "Tiempo real" significa cosas distintas según el volumen. Si tu SLA operativo es "los cambios de Salesforce aparecen en Postgres en 5 segundos", el diseño es uno; si es "en 100 ms para flujos críticos de ingresos", cambia bastante.

La página de producto de Stacksync explica cómo se ve de punta a punta la sincronización bidireccional en tiempo real que escala en la ruta de comprar.

Sobre el autor

Bruno Galo — Fundador, Atypical Tech

Bruno Galo es el fundador de Atypical Tech, una consultora de NetSuite que trabaja con clientes del mercado medio en toda Iberia. Se especializa en conectar sistemas CRM y ERP para lograr flujos de order-to-cash sin fricciones, construyendo pipelines automatizados de gestión de pedidos que eliminan la entrada manual de datos entre los equipos de ventas y finanzas. Como partner oficial de implementación de Stacksync, Bruno diseña y despliega agentes de IA sobre plataformas de integración para gestionar el enrutamiento de excepciones, el procesamiento de documentos y la conciliación — convirtiendo flujos de pedidos fragmentados en sistemas fiables que se monitorizan a sí mismos.

LinkedIn

Fuentes

• 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