CDC gestionado vs Debezium autoalojado

Respuesta corta. El CDC gestionado suele ganar cuando nadie de su equipo opera hoy Kafka en producción, cuando solo tiene un puñado de pipelines o cuando hay una fecha límite. El autoalojamiento gana cuando ya opera Kafka con soltura, cuando las restricciones de red o de residencia de datos descartan a un proveedor, o cuando el volumen es lo bastante alto y constante como para que el precio por uso crezca más deprisa que el tiempo de un ingeniero de plataforma. En medio hay una vía intermedia: Kafka gestionado con sus propios conectores Debezium, o Debezium Server sin Kafka. Si lo que realmente necesita es sincronización operativa bidireccional entre un CRM y una base de datos, ninguno de los dos lados de esta decisión es la respuesta completa.

La licencia es la partida más pequeña. Debezium autoalojado es software libre que corre sobre una infraestructura y unas personas que usted paga. El CDC gestionado es una factura que sustituye parte de ese tiempo de personas. Este artículo le da un modelo de costes que puede rellenar con sus propias cifras, los modos de fallo que suelen decidir la cuestión y una respuesta corta para cada tipo de equipo. Lo escribimos como ingenieros que operan ambos: somos partner de Stacksync para sincronización operativa gestionada y construimos pipelines CDC a medida cuando es la mejor opción.

Qué significan «CDC gestionado» y «CDC autoalojado» en 2026

El change data capture (CDC) lee los cambios a nivel de fila del log de una base de datos y los transmite a otro destino. La elección no son dos casillas, gestionado o no. Es un espectro, y el punto en el que se sitúe decide qué opera usted.

Son ejemplos, no un ranking. Contraste cada afirmación sobre un producto con la documentación del propio proveedor antes de decidir, porque los planes y los conectores cambian.

Dos hechos hacen que el extremo autoalojado del espectro sea menos pesado que antes. Kafka 4.x funciona sin ZooKeeper. Y Debezium 3.7, publicado el 29 de septiembre de 2026, incorporó la primera CLI oficial de Debezium y permitió que Debezium Platform se despliegue en hosts por SSH en lugar de solo en Kubernetes. Es menos trabajo operativo que antes. Sigue siendo suyo.

En el extremo gestionado, el PostgreSQL CDC Source V2 de Confluent Cloud es un conector basado en Debezium que se factura por hora de tarea del conector más la transferencia de datos. La página de precios indica algunos conectores premium como «contacte con nosotros», así que aquí no citamos ninguna tarifa.

El modelo de costes: todas las partidas, no solo la licencia

La mayoría de las hojas de cálculo comparan la licencia y la factura del cloud. Las partidas que deciden la respuesta son las que nadie introduce.

Después, reúna las partidas en una fórmula:

TCO anual = infraestructura + licencias + (horas de ingeniería al mes × coste horario completo × 12) + margen para incidentes

Introduzca su propio coste completo por hora y su propia factura de cloud. A propósito no damos cifras en euros: cualquier precio que pudiéramos imprimir sería inventado o estaría desfasado, y el número interesante es el suyo. Lo mismo vale para el punto de cruce. Autoalojar sale más barato a medida que crece el volumen solo si el tiempo de personas se mantiene constante, así que calcule con sus propios datos el punto en que el precio por uso supera al tiempo de sus ingenieros, y desconfíe de cualquier umbral fijo que lea por ahí, incluidos los blogs de proveedores. Si quiere la versión específica de Salesforce de este argumento, lea el análisis de build-vs-buy para sustituir Heroku Connect.

Rellenaremos este modelo con usted: reserve una llamada de 30 minutos y traiga su factura de cloud y su turno de guardias.

Qué falla en producción (y quién lo arregla)

La comparación honesta está en los modos de fallo. Para cada uno, la pregunta es qué gestiona el proveedor y qué sigue recayendo sobre usted.

Replication slots de PostgreSQL que retienen WAL

Si el conector deja de consumir, el replication slot retiene segmentos de WAL y el disco de su primario se llena. Las mitigaciones son configurar max_slot_wal_keep_size (PostgreSQL 13 y posteriores), alertar sobre el lag del slot y usar un heartbeat en bases de datos poco activas. Autoalojado: lo hace todo usted. Gestionado: el proveedor opera el conector, pero el slot vive en su base de datos, así que el riesgo y las alertas siguen siendo suyos. La propia documentación de Airbyte señala que un slot invalidado tras superarse max_slot_wal_keep_size hay que recrearlo y exige una re-sincronización completa.

Cambios de esquema

El DDL sobre la tabla de origen cambia lo que emite el conector. Las reglas de compatibilidad del schema registry deciden si se rompen los consumidores posteriores. Autoalojado: usted diseña y hace cumplir la política de compatibilidad. Gestionado: la plataforma puede incluir un registry, pero sus equipos siguen siendo los dueños de los contratos con cada consumidor.

Snapshots y re-snapshots

Un snapshot inicial lee las tablas de origen y carga la base de datos de origen. Los snapshots incrementales reducen ese coste, y una interrupción larga puede obligarle a volver a hacer uno. Durante un snapshot largo el slot no avanza, así que en una tabla grande se acumula WAL. Autoalojado: usted lo programa y lo vigila. Gestionado: el proveedor ejecuta el snapshot, pero usted decide cuándo es aceptable la carga sobre su base de datos.

Semántica de entrega

Planifique para entrega at-least-once. Los consumidores deben ser idempotentes, y no prometeríamos exactly-once de punta a punta con ninguna opción. Autoalojado: usted diseña la idempotencia. Gestionado: lo mismo, porque vive en sus consumidores.

Fallos y reinicios de tareas del conector

Las tareas fallan, se reinician y a veces se topan con un mensaje venenoso. Las dead-letter queues y unos runbooks claros importan más que la plataforma. Autoalojado: el busca es suyo. Gestionado: el proveedor reinicia los workers, usted sigue clasificando los datos erróneos.

Actualizaciones

Debezium publica versiones 3.x con frecuencia, Kafka tiene versiones mayores, y una actualización mayor de su PostgreSQL gestionado exige planificación en torno a los replication slots lógicos. Autoalojado: las actualizaciones son trabajo de sprint. Gestionado: el proveedor actualiza la plataforma, usted planifica la parte de la base de datos.

Cuándo autoalojar es la decisión correcta

Autoalojar es la decisión correcta en estas situaciones:

• Ya tiene un equipo de plataforma Kafka, así que el coste marginal de un conector más es pequeño.
• Un requisito estricto de VPC, on-premises o de residencia que ningún proveedor puede cumplir.
• Volumen alto y constante en el que el precio por uso supera al coste de personas. Calcule el punto de cruce con sus propias cifras.
• Necesita single message transforms o conectores a medida que el catálogo gestionado no ofrece.
• Ser dueño del pipeline es estratégico, por ejemplo porque forma parte de su producto.

Cuándo gana el CDC gestionado

El CDC gestionado gana en estas situaciones:

• Hoy no tiene Kafka en producción.
• Una sola persona es la única que entiende el clúster de Connect. No existe un tamaño de equipo mágico: la prueba es si esa persona puede irse de vacaciones.
• La migración viene marcada por una fecha límite, por ejemplo al abandonar Heroku Connect.
• Tiene muchos pipelines pequeños, cada uno demasiado pequeño para justificar un cuidado propio.
• El trabajo de auditoría o de cumplimiento prefiere la evidencia SOC 2 o ISO de un proveedor.

La perspectiva europea: residencia de datos y RGPD

Un flujo CDC copia datos personales, así que el pipeline entra en el ámbito de su registro de actividades de tratamiento del RGPD. Compruebe las regiones del proveedor, si hay una región de la UE disponible para el conector que necesita, la lista de subencargados y el contrato de encargado del tratamiento. La mayoría de los grandes proveedores gestionados ofrecen regiones de la UE, pero verifíquelo por proveedor y por producto. Autoalojar dentro de su propia región cloud de la UE es la historia de residencia más sencilla. Esto no es asesoramiento jurídico.

Migrar de Kafka autoalojado a gestionado (o a la inversa)

Los equipos que buscan el mejor servicio de Kafka gestionado para una migración suelen preguntar cómo moverse sin un re-snapshot, no qué proveedor elegir. No clasificamos proveedores. La secuencia importa más que el logotipo:

1. Inventarie topics, conectores, configuraciones y offsets confirmados.
2. Elija la ruta de mirroring, por ejemplo MirrorMaker 2 o una opción tipo cluster linking de un proveedor, y pruébela con un topic no crítico.
3. Mantenga la continuidad del replication slot para que el conector reanude donde se detuvo y no vuelva a caer en un snapshot de sus tablas de producción.
4. Planifique el cutover y el rollback: quién cambia los consumidores, en qué orden y cuál es el punto a partir del cual ya no se puede volver atrás.
5. Ejecute ambos en paralelo el tiempo suficiente para comparar lag y recuentos antes de retirar nada.

El movimiento inverso, de gestionado de vuelta a autoalojado, sigue los mismos pasos. El coste de salida es bajo para Debezium de código abierto y más alto para una plataforma gestionada, que es una partida de coste más que registrar.

¿Y la sincronización bidireccional (CRM y base de datos)?

El CDC es un flujo unidireccional de cambios. Escribir de vuelta, por ejemplo entre Salesforce y PostgreSQL, exige gestión de conflictos, idempotencia y prevención de bucles. Esas capas son la parte difícil y se explican en el análisis de build-vs-buy. Si es su caso, vaya a nuestra página de integración Salesforce–PostgreSQL y a la página de partner de Stacksync.

Lista de decisión

Responda sí o no. Lo que importa es el patrón, no el recuento.

1. ¿Opera hoy Kafka en producción? (Sí apunta a autoalojado o a la vía intermedia, no apunta a gestionado.)
2. ¿Hay más de una persona que pueda arreglar el clúster de Connect a las 3 de la madrugada?
3. ¿Tendrá más de un puñado de pipelines en los próximos 12 meses?
4. ¿Existe una restricción de residencia o de red que un proveedor no pueda cumplir?
5. ¿Son todas sus bases de datos de origen de las que admite la opción gestionada?
6. ¿Necesita transformaciones o conectores a medida?
7. ¿Necesita sincronización bidireccional? (Sí: ninguna de las dos opciones por sí sola, vea la sección anterior.)
8. ¿El lag aceptable se mide en segundos, o bastan minutos?
9. ¿Prefiere quien controla el presupuesto una suscripción operativa o tiempo de ingeniería?
10. ¿Hay una fecha límite firme dentro del próximo trimestre?

Mayoría de «no» en las tres primeras y «sí» en la última: gestionado. Mayoría de «sí» en las tres primeras y en la 4 o la 6: autoalojado. Una mezcla: la vía intermedia de Kafka gestionado con sus propios conectores, o Debezium Server sin Kafka.

Preguntas frecuentes

¿Merece la pena pagar por CDC gestionado en lugar de operar su propio Kafka Connect?

Normalmente sí si nadie de su equipo opera ya Kafka en producción, o si una sola persona concentra todo el conocimiento. Autoalojar compensa cuando ya opera Kafka con soltura, tiene restricciones de residencia o un volumen alto y constante en el que el precio por uso supera al tiempo de ingeniería.

¿Cuánto cuesta realmente Debezium autoalojado?

El software es gratuito bajo Apache 2.0. El coste es la infraestructura (brokers de Kafka, workers de Connect, almacenamiento, red) más el tiempo de ingeniería para monitorización, actualizaciones, guardias y recuperación de incidentes. Modele cada partida con sus propias cifras.

¿Qué plataforma CDC tiene el menor coste total de propiedad?

Depende del volumen, del equipo y de la infraestructura existente. Ninguna plataforma es la más barata para todos. Compare todas las partidas de coste, no la licencia.

¿Necesito Kafka para usar Debezium?

No. Debezium Server y el Debezium Engine embebido transmiten cambios a otros destinos sin Kafka. Kafka Connect sigue siendo el despliegue más habitual.

¿El CDC gestionado elimina el riesgo del replication slot en PostgreSQL?

No. El slot vive en su base de datos. Si el conector deja de consumir, se acumula WAL. Configure max_slot_wal_keep_size y alerte sobre el lag del slot en cualquier caso.

¿Debezium o Airbyte para CDC?

Debezium es un motor CDC que transmite cambios de fila. Airbyte es una plataforma ELT que puede usar CDC en algunos orígenes, y su CDC de Postgres se apoya en Debezium por debajo. Elija según la latencia que necesite y lo que quiera operar. El artículo de build-vs-buy los compara para el caso de Salesforce.

¿Puede el CDC gestionado funcionar en una región de la UE por el RGPD?

La mayoría de los grandes proveedores ofrecen regiones de la UE. Compruebe la región, los subencargados y el contrato de encargado del tratamiento por proveedor. Autoalojar en su propia región cloud de la UE es la historia de residencia más sencilla.

¿Basta el CDC para la sincronización bidireccional entre Salesforce y PostgreSQL?

No. El CDC es unidireccional. La sincronización bidireccional necesita escritura de vuelta, reglas de conflicto y prevención de bucles. Vea nuestra página de Salesforce–PostgreSQL.

Cierre: ¿no sabe de qué lado de la línea está?

Empiece por listar sus pipelines, quién está de guardia en cada uno y cuánto cuesta un día de lag. Esa lista suele resolver la cuestión más rápido que una comparativa de proveedores. Si quiere una segunda opinión de gente que opera ambos, reserve una llamada de 30 minutos. Para el resto del grupo de temas, lea la guía de migración por el fin de vida de Heroku Connect, la introducción al CDC en Salesforce y Heroku Connect y iPaaS vs punto a punto vs middleware.

Sobre el autor

Bruno Galo es el fundador de Atypical Tech, una consultora de NetSuite que atiende a clientes mid-market en toda Iberia. Se especializa en conectar sistemas CRM y ERP para flujos order-to-cash fluidos, y construye pipelines automatizados de gestión de pedidos que eliminan la entrada manual de datos entre los equipos de ventas y de finanzas. Como partner oficial de implantació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 supervisan solos.

LinkedIn: https://www.linkedin.com/in/brunogd

Fuentes

• Debezium, «Debezium 3.7.0.Final released», 29 de septiembre de 2026 — https://debezium.io/blog/2026/09/29/debezium-3-7-final-released/
• Versiones de Debezium — https://debezium.io/releases/
• Confluent, conector PostgreSQL CDC Source V2 (Debezium) para Confluent Cloud — https://docs.confluent.io/cloud/current/connectors/cc-postgresql-cdc-source-v2-debezium/cc-postgresql-cdc-source-v2-debezium.html
• Confluent Cloud, precios de conectores totalmente gestionados (dimensiones de facturación comprobadas el 5 de octubre de 2026) — https://www.confluent.io/confluent-cloud/connect-pricing/
• Airbyte, documentación del origen Postgres (CDC y replication slots) — https://docs.airbyte.com/integrations/sources/postgres
• Experiencia de Atypical Tech en pipelines de CDC y de sincronización operativa