← Volver al blog
Build vs buy: reemplazar Heroku Connect con Debezium, Airbyte o una plataforma de sincronización gestionada
Integración con Salesforce

Build vs buy: reemplazar Heroku Connect con Debezium, Airbyte o una plataforma de sincronización gestionada

porBruno Galo · Publicado el 15 may 2026

Actualizado el 07 ago 2026

Disponible enCatalàEnglishEspañolPortuguês

Con Heroku en sustaining mode tras el anuncio del 6 de febrero de 2026, los equipos están sopesando si auto-alojar el CDC de Salesforce sobre Debezium, Airbyte o Kafka — o comprar una plataforma gestionada como Stacksync. La ruta de construir es viable, pero subestima 5 costes ocultos que fácilmente suman 300.000–600.000 $ el primer año. Aquí tienes el análisis y una comparación de 90 días frente a 14.

Por qué esta pregunta está viva de repente

Chocaron dos cambios. La decisión de sustaining mode de Salesforce (cubierta por Salesforce Ben y otra prensa del sector) hizo que todo cliente de Heroku Connect se preguntara si seguir pagando. Y el tooling de CDC open source — Debezium, Airbyte, Apache Kafka — ha madurado hasta el punto en que un equipo de backend sénior puede plantearse con credibilidad auto-alojar el reemplazo.

La conversación que hoy ocurre en todo equipo de ingeniería con Salesforce es alguna versión de: "Heroku Connect nos cuesta 25.000 $ al mes. ¿No podríamos construirlo?". La respuesta es a veces sí, a menudo no, y la línea divisoria rara vez está donde los equipos esperan.

Para el encuadre de urgencia de la migración, mira nuestro artículo complementario sobre el fin de vida de Heroku Connect. Para el fundamento arquitectónico de qué es realmente un stack de sincronización basado en CDC, mira Salesforce CDC vs Heroku Connect.

Qué implica realmente la ruta de construir

Una sincronización bidireccional completa entre Salesforce y Postgres, construida desde primitivas, tiene ocho capas. Heroku Connect agrupa las ocho; las rutas de construcción las reproducen pieza a pieza.

  1. Fuente de cambios. CDC de Salesforce entregado por la Pub/Sub API. Latencia por debajo del segundo, ventana de replay de 72 horas. Esta es la capa "fácil".
  2. Consumidor del stream. Un cliente gRPC suscrito a la Pub/Sub API, persistiendo eventos en Kafka, Kinesis o directamente en Postgres. Las tiendas que ya tienen Kafka tienen casi todo esto; los proyectos desde cero deben diseñarlo.
  3. Carga inicial masiva. Bulk API 2.0 de Salesforce para rellenar los datos existentes. Debe coordinarse con el stream de CDC para no aplicar dos veces ni perder registros durante el cambio.
  4. Ruta de escritura de vuelta. REST API de Salesforce + claves de idempotencia + lógica de reintentos + deduplicación para evitar bucles entre tus escrituras y los eventos CDC entrantes. Solo esta capa son de 6 a 8 semanas de ingeniería sénior.
  5. Detección de deriva de esquema. Los administradores de Salesforce añaden campos personalizados. CDC trae el campo nuevo. Tu esquema de destino no lo tiene. La sincronización lo descarta en silencio salvo que construyas detección, alertas y auto-evolución.
  6. Resolución de conflictos. Cuando el mismo registro cambia en Salesforce y en Postgres en la misma ventana, ¿quién gana? Last-write-wins es la respuesta fácil; reglas configurables por objeto es lo que necesitan los equipos en producción.
  7. Almacenamiento de replay más allá de 72 horas. La ventana de CDC es de 72 horas. Si tu consumidor está caído 73 horas, necesitas un topic de Kafka delante con retención más larga o un trabajo periódico de reconciliación completa con snapshots de Bulk API 2.0.
  8. Observabilidad y alertas. Retardo de sincronización, eventos perdidos, deriva de esquema, número de conflictos, fallos de escritura de vuelta. Nada de esto viene gratis; todo es obligatorio para operar en producción.

Heroku Connect hacía las ocho, mal en algunos puntos (polling de 10 minutos en vez de streaming CDC), pero las hacía. Reemplazarlo desde primitivas significa reconstruir las ocho.

Los tres stacks open source / híbridos más considerados

Debezium + Kafka

Debezium es el framework canónico de CDC en el mundo Postgres / MySQL. A fecha de 2026, Debezium no incluye un conector fuente estable para Salesforce — el trabajo específico de Salesforce ha vivido históricamente en proyectos adyacentes, no en el Debezium upstream. Los equipos que construyen sobre Debezium lo suelen combinar con un cliente de la Pub/Sub API de Salesforce (Java o Python) que emite registros a Kafka, y luego usan el sink de Postgres de Debezium.

Fortalezas: probado a escala, tooling operativo maduro, comunidad grande. Debilidades: sin conector de Salesforce de primera clase, exige Kafka en producción, y tu equipo es dueño del cliente gRPC del lado de Salesforce.

Airbyte (open source)

El conector fuente de Salesforce de Airbyte está bien mantenido y se usa activamente. El modo por defecto es sincronización incremental programada (normalmente 5 minutos o más). Airbyte no corre de forma nativa en un modelo de streaming por debajo del segundo; está más cerca de "un Fivetran moderno" que de "CDC en tiempo real".

Fortalezas: fácil de desplegar, biblioteca amplia de conectores, razonable para sincronización de estilo analítico. Debilidades: no es tiempo real en el sentido de Heroku Connect, sin escritura de vuelta bidireccional integrada, programado en vez de streaming.

Conector Salesforce CDC Source de Confluent

El conector gestionado Salesforce CDC Source de Confluent es la ruta "Salesforce → Kafka" lista para usar más cercana. Basado en streaming, soporta CDC y Platform Events. Listo para producción. Combina de forma natural con el sink de Postgres de Debezium.

Fortalezas: gestionado, streaming, grado de producción. Debilidades: exige Confluent Cloud o un clúster de Kafka Connect auto-alojado, los costes de licencia no son triviales a escala, y sigue exigiendo que construyas la ruta de escritura de vuelta.

Los 5 costes ocultos de construir

Son los costes que sorprenden a los equipos a las seis semanas de empezar. Cada uno es tiempo real de ingeniería, no opcional.

  1. Pipelines de reconciliación. La entrega de CDC es at-least-once con una ventana de replay de 72 horas. Los equipos en producción descubren que entre el 0,1% y el 1% de los eventos necesita reconciliación contra un snapshot de Bulk API 2.0 — normalmente por caídas del consumidor, borrados en firme o huecos de deriva de esquema. Construir la infraestructura de reconciliación: de 4 a 6 semanas de ingeniería sénior.
  2. Escritura bidireccional de vuelta. REST API de Salesforce + idempotencia + deduplicación + resolución de conflictos para la dirección Postgres → Salesforce. Incluye gestionar los rate limits de la API, los fallos de reglas de validación y la lógica de reintentos. De 6 a 8 semanas.
  3. Detección de deriva de esquema. Campo personalizado añadido en Salesforce → CDC lo trae → tu destino no tiene columna → pérdida silenciosa. Construir la detección que compara los payloads CDC entrantes contra el esquema de destino y lo evoluciona automáticamente o alerta: de 2 a 4 semanas al principio, más mantenimiento continuo.
  4. Soporte multi-org / multi-tenant. Si sincronizas más de una org de Salesforce o llevas un SaaS donde cada cliente tiene la suya, necesitas enrutado por tenant, aislamiento y observabilidad. De 6 a 12 semanas.
  5. Carga de guardia. Una vez en producción: de 2 a 4 horas por ingeniero y semana en régimen estable, con picos periódicos por incidentes. Repartido en el equipo, a largo plazo equivale típicamente a un ingeniero a tiempo completo.

Suma el tiempo de ingeniería: aproximadamente de 18 a 34 semanas de trabajo de backend sénior antes de que el sistema tenga grado de producción. A coste cargado (~300.000–500.000 \(por año de backend sénior), el TCO del primer año de construir aterriza en **300.000–600.000\)**, con un coste operativo continuo equivalente a ~1 FTE.

Comparativa lado a lado

Dimensión CDC auto-alojado (Debezium / Airbyte) Plataforma gestionada (Stacksync, etc.) Heroku Connect (titular)
Tiempo de construcción inicial 3–6 meses 1–2 semanas 1–2 semanas
Equipo de ingeniería necesario Backend sénior × 2–3 Ninguno continuo Ninguno continuo
Suelo de latencia Posible por debajo del segundo Por debajo del segundo Mínimo 10 min
Bidireccional de serie No (construir escritura de vuelta)
TCO año 1 300.000–600.000 \((con FTE) | 20.000–120.000\) 60.000–300.000 $
TCO año 2+ ~200.000–400.000 \((~1 FTE continuo) | 20.000–120.000\) 60.000–300.000 $
Replay más allá de 72h Sí (coste de almacenamiento) N/A (basado en estado)
Mantenimiento / guardia Continuo, tu equipo Proveedor Proveedor
Gestión de deriva de esquema Constrúyela Integrada Manual
Destinos no Postgres No (solo Heroku Postgres)
Propiedad estratégica Tú eres dueño del pipeline El proveedor El proveedor

La economía rara vez favorece construir hasta cruzar los 100M de eventos al día, donde el precio gestionado se invierte y un stack de Kafka auto-alojado sale más barato por unidad. Por debajo de ese volumen, el coste total de la plataforma gestionada (licencia + cero ingeniería continua) suele ser entre el 30% y el 60% del coste cargado de la ruta de construir.

Cuándo gana de verdad la ruta de construir

Hay cuatro razones genuinamente buenas para construir.

Propiedad estratégica del pipeline de datos. Algunas empresas tratan su stack de integración como competencia central — fintechs que sincronizan datos de clientes entre muchos sistemas, o grandes plataformas SaaS cuyo producto va fundamentalmente de mover datos. Para estos equipos, ser dueño del pipeline de punta a punta es la decisión correcta al margen del TCO.

Datos de Salesforce multi-tenant con aislamiento estricto. Las plataformas SaaS que corren sobre orgs de Salesforce por cliente a veces necesitan aislamiento de red a nivel de org que las plataformas gestionadas no dan en sus tramos estándar. Auto-alojar en tu propia VPC lo resuelve — a cambio de construir todo lo demás.

Restricciones de cumplimiento que exigen CDC on-premise / en VPC. Sectores regulados que no pueden sacar datos hacia una plataforma SaaS de terceros. El listón de cumplimiento manda sobre la arquitectura; el coste es secundario.

Coste a muy gran escala. Por encima de ~100M de eventos CDC de Salesforce al día, el precio de las plataformas gestionadas suele invertirse y Kafka auto-alojado sale más barato por unidad. La mayoría de clientes de Heroku Connect no está en ese volumen; para los que sí, construir es una decisión económica defendible.

Cuándo pierde la ruta de construir

Tres señales que dicen comprar.

Equipo por debajo de 5 ingenieros de backend. La ruta de construir exige de 2 a 3 ingenieros sénior sostenidos durante 3 a 6 meses, más la propiedad operativa continua. Los equipos más pequeños no pueden permitirse el coste de oportunidad.

Sincronización bidireccional requerida desde el día uno. Solo la capa de escritura de vuelta son de 6 a 8 semanas. Los equipos que necesitan bidireccional en producción rápido casi siempre pierden construyendo.

Ninguna plataforma de streaming ya en producción. Si hoy no corres Kafka o equivalente, la ruta de construir incluye levantar Kafka — sumando de 4 a 8 semanas de trabajo operativo más ingeniería de plataforma continua. Compra.

Para una visión más profunda de por qué la arquitectura de Heroku Connect topa en polling de 10 minutos y de cómo es una arquitectura de reemplazo moderna, mira el análisis a fondo de los límites de Heroku Connect de Stacksync.

Cronograma de referencia de 90 días si construyes

El calendario realista para un equipo sénior de 2 a 3 ingenieros de backend construyendo un reemplazo de Heroku Connect con grado de producción sobre arquitectura estilo Debezium.

  1. Semanas 1–2: spike de arquitectura. Levanta un consumidor gRPC de la Pub/Sub API en el lenguaje que prefieras (Java, Python, Go). Suscríbete a un canal de CDC. Demuestra latencia por debajo del segundo de punta a punta. Decide Kafka frente a aterrizaje directo en Postgres.
  2. Semanas 3–4: carga inicial con Bulk API 2.0. Construye el trabajo de backfill. Coordínalo con el stream de CDC para que el paso de "carga masiva" a "CDC incremental" sea exacto (sin duplicados, sin huecos).
  3. Semanas 5–8: escritura bidireccional de vuelta. Cliente de la REST API de Salesforce. Claves de idempotencia. Reintentos con backoff exponencial. Lógica de deduplicación para evitar bucles entre tus escrituras y los eventos CDC entrantes. Reglas de resolución de conflictos por objeto.
  4. Semanas 9–10: detección de deriva de esquema y auto-evolución. Compara los payloads CDC entrantes contra el esquema de destino. O añade columnas automáticamente o alerta. Integra la alerta en tu guardia existente.
  5. Semanas 11–12: observabilidad y almacenamiento de replay. Dashboards de retardo de sincronización, número de conflictos, eventos perdidos. Topic de Kafka de retención larga (o equivalente) para replay más allá de 72 horas.
  6. Semana 13: ejecución en shadow. Corre el nuevo stack contra el despliegue existente de Heroku Connect durante 14 días. Reconcilia la integridad de los datos cada hora. Marca y resuelve cada discrepancia antes del cambio.

13 semanas de trabajo de ingeniería, más una ventana shadow de 14 días. Total: unos 90 días desde el arranque hasta el paso a producción, con 2 o 3 ingenieros de backend sénior dedicados a tiempo completo.

Cronograma de referencia de 14 días si compras (con Stacksync como ejemplo)

Para comparar, el calendario típico de una migración a plataforma gestionada:

  • Días 1–3: conecta Salesforce y la base de datos destino. Mapea el primer conjunto de objetos. Valida la autenticación y la sincronización básica.
  • Días 4–7: valida la dirección de sincronización, los ajustes de resolución de conflictos y los dashboards de observabilidad. Configura alertas.
  • Días 8–10: ventana shadow contra el despliegue existente de Heroku Connect. Reconcilia recuentos de filas y hashes.
  • Días 11–14: cambia el tráfico de escritura. Mantén lectura doble 7 días para revertir al instante. Da de baja Heroku Connect.

Total: 14 días de punta a punta con 1 o 2 ingenieros a tiempo parcial. Así es como se ve en la práctica la sincronización gestionada en tiempo real que escala.

Preguntas frecuentes

¿Puede Debezium sincronizar Salesforce con Postgres?
No directamente con Debezium de serie. Debezium no incluye un conector fuente de Salesforce de primera clase a fecha de 2026. Los equipos que construyen sobre Debezium lo combinan con un cliente gRPC propio de la Pub/Sub API (o con el conector Salesforce CDC Source de Confluent) que emite registros a Kafka, y luego usan el sink de Postgres de Debezium para el destino. El stack completo es viable, pero no es un despliegue de Debezium llave en mano.

¿Airbyte es tiempo real?
No, no en el sentido de Heroku Connect. El conector fuente de Salesforce de Airbyte corre con sincronizaciones incrementales programadas — normalmente de 5 minutos o más. Está más cerca de "un Fivetran moderno" que de "CDC en tiempo real". Para latencia por debajo del segundo necesitas un cliente de la Pub/Sub API (el conector de Confluent o uno gRPC propio), no Airbyte.

¿Cuál es la alternativa open source más barata a Heroku Connect?
No hay un sustituto directo perfecto. El patrón más cercano es conector Salesforce CDC Source de Confluent → Kafka → sink de Postgres de Debezium, más un servicio propio de escritura de vuelta. Los costes de licencia son mínimos a escala pequeña (Confluent tiene tramo gratuito; Kafka y Debezium son open source). El coste de ingeniería empequeñece al de licencia — normalmente más de 300.000 $ el primer año en tiempo de construcción con FTE incluidos.

¿Cuánto se tarda en construir un reemplazo de Heroku Connect?
De tres a seis meses para una construcción con grado de producción con 2 o 3 ingenieros de backend sénior. Los sumideros de tiempo dominantes son la capa de escritura bidireccional (6–8 semanas), los pipelines de reconciliación (4–6 semanas) y la integración de todas las capas bajo una única superficie de observabilidad. Los equipos que estiman "dos semanas para montar un consumidor de CDC" están estimando la capa 1 de 8.

¿Salesforce CDC soporta sincronización bidireccional?
No. CDC es un flujo de eventos unidireccional de Salesforce al consumidor, sin primitiva de escritura integrada. La sincronización bidireccional exige una ruta de escritura de vuelta aparte con la REST API o la Bulk API 2.0, con claves de idempotencia, lógica de deduplicación y resolución de conflictos. Cubrimos el detalle arquitectónico en Salesforce CDC vs Heroku Connect.

¿Cuánto cuesta reemplazar Heroku Connect?
Para la mayoría de equipos, una plataforma de sincronización gestionada se sitúa en el rango de 20.000 a 120.000 \(al año** — normalmente entre un 50% y un 80% por debajo del gasto equivalente en Heroku Connect Enterprise. Auto-alojar sobre Debezium/Airbyte/Kafka suele salir por **300.000 a 600.000\) el primer año (tiempo de ingeniería con FTE incluidos) más un coste operativo continuo equivalente a aproximadamente un ingeniero a tiempo completo. La economía solo se invierte a escala muy alta.

¿Cuál es un calendario realista para migrar fuera de Heroku Connect?
Comprando una plataforma gestionada: 14 días de punta a punta con 1 o 2 ingenieros a tiempo parcial (3 días de conexión, 4 de validación, 4 de shadow, 3 de cambio). Construyendo desde primitivas: de 3 a 6 meses con 2 o 3 ingenieros de backend sénior a tiempo completo. Los despliegues grandes de Heroku Connect (más de 50 flujos, más de 100M de filas) alargan cualquiera de los dos calendarios entre 2 y 4 semanas por el trabajo de reconciliación.

¿El conector Salesforce CDC de Confluent está listo para producción?
Sí. El conector Salesforce CDC Source de Confluent es un conector gestionado con grado de producción que se suscribe a los eventos CDC de Salesforce por la Pub/Sub API. Es la ruta lista para usar más fiable de Salesforce a Kafka. No aporta sincronización bidireccional; esa capa sigue siendo tuya.

¿Cuándo comprar es siempre mejor que construir la sincronización de Salesforce?
Tres condiciones: equipo por debajo de 5 ingenieros de backend, sincronización bidireccional requerida desde el día uno, o ningún equivalente a Kafka ya en producción. Si se cumple cualquiera, el coste de ingeniería de construir casi siempre supera el coste plurianual de licencia de la plataforma gestionada. Por encima de 100M de eventos CDC al día con un equipo sénior, las cuentas pueden darse la vuelta.

¿Cómo cobran las plataformas de sincronización gestionada — por registro, por conexión o tarifa plana?
Cada plataforma cobra distinto. Stacksync usa un modelo de suscripción transparente basado en número de conexiones y tramo. Whalesync usa un modelo por registro / volumen de sincronización. Algunas plataformas iPaaS heredadas cobran por registro procesado, lo que escala mal a volumen alto. Modela siempre tu volumen esperado contra cada modelo de precio antes de firmar.

Cierre — Recomendación de decisión

Recorre primero las tres señales de "comprar". Si se cumple cualquiera, compra. Si las tres son falsas (tienes 5 o más ingenieros de backend sénior, no necesitas bidireccional desde el día 1 y ya operas Kafka), la ruta de construir empieza a merecer un modelado — pero compara el TCO de año 1 y de año 3 con honestidad.

Si estás migrando fuera de Heroku Connect en concreto y el volumen está por debajo de 100M de eventos CDC al día, la sincronización gestionada en tiempo real que escala de Stacksync es la ruta que elige la mayoría. Hemos visto cambios en 14 días de forma consistente en migraciones del mercado medio.

Sobre el autor

Bruno GaloFundador, 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

Comentarios

Todavía no hay comentarios.

Deja un comentario

Tu comentario se revisará antes de publicarse.

An unhandled error has occurred. Reload 🗙