Microsoft abre ejecución durable en PostgreSQL

Microsoft abrió una pieza que vale la pena mirar si tu equipo trabaja con procesos que no se pueden perder a mitad de camino: pg_durable, una extensión para llevar ejecución durable dentro de PostgreSQL. La idea es simple de explicar y potente en la práctica: en vez de sacar la orquestación a otro motor, puedes guardar el estado del workflow en la misma base de datos donde ya viven tus transacciones.

Eso cambia bastante el mapa para productos que necesitan tolerancia a fallos sin sumar otra capa de infraestructura. Si hoy coordinas tareas como cobros, aprobaciones, sincronización con APIs externas o jobs que deben reanudarse después de un corte, ya sabes el costo de operar colas, workers, retries, dead-letter queues y un orquestador aparte. pg_durable apunta justo a reducir esa complejidad, apoyándose en PostgreSQL como sistema de registro y recuperación.

Qué propone pg_durable y por qué importa

La propuesta de pg_durable es llevar el concepto de durable execution al motor de base de datos. En términos prácticos, eso significa que una secuencia de pasos puede persistir su estado, reanudarse después de un fallo y evitar repetir trabajo innecesario. No estás solo guardando datos finales; estás guardando el progreso del proceso.

Según el repositorio oficial, el proyecto está abierto en GitHub y se presenta como una forma de ejecutar workflows durables dentro de PostgreSQL. Puedes revisar el código y la documentación en el repositorio oficial de Microsoft: pg_durable. También conviene tener a mano la documentación de PostgreSQL sobre transacciones y concurrencia, porque ahí está buena parte de la base conceptual: PostgreSQL Documentation.

Esto le interesa a equipos que ya viven dentro de Postgres. Si tu sistema usa Postgres para autenticación, órdenes, inventario o eventos de negocio, meter la orquestación en la misma capa puede simplificar mucho la operación. Menos servicios que desplegar, menos puntos de falla y menos sincronización entre un orquestador externo y la base principal.

Qué significa “durable execution” en la práctica

Durable execution no es un slogan. Es la capacidad de retomar un proceso exactamente donde quedó, incluso si el worker se cae, reinicias el pod o la instancia pierde conectividad. En lugar de confiar solo en memoria o en un job runner efímero, el estado del proceso queda persistido.

Eso es útil en escenarios muy comunes: una orden que debe pasar por validación, cobro, emisión de factura y notificación; un flujo de onboarding que depende de varias APIs; o un proceso de conciliación que puede tardar minutos y no debe duplicarse. Si una llamada externa falla en el paso 3 de 5, no quieres volver a ejecutar todo desde cero.

La diferencia frente a un job tradicional es que aquí el motor no solo ejecuta tareas, también conserva el contexto. Y si ese contexto está en PostgreSQL, puedes aprovechar propiedades que ya conoces: transacciones, locks, índices, consultas SQL y observabilidad a nivel de datos.

Cómo encaja dentro de PostgreSQL

La parte más interesante del proyecto es que no te obliga a meter un sistema nuevo para coordinar estados. PostgreSQL ya es el lugar donde muchas empresas guardan la verdad del negocio, así que usarlo también para la orquestación puede tener sentido. No siempre, pero sí en bastantes casos.

La lógica de pg_durable se apoya en la base de datos para persistir el progreso y recuperar la ejecución. Eso reduce el salto entre “estado de negocio” y “estado del workflow”, que suele ser una fuente de bugs. Cuando el proceso vive cerca de los datos que lo disparan, es más fácil razonar sobre consistencia y reintentos.

Ahora bien, esto no significa que Postgres deba convertirse en una navaja suiza para todo. Si tu carga es enorme, si necesitas miles de ejecuciones concurrentes con patrones complejos de fan-out o si tu equipo ya opera un orquestador maduro, quizá no sea la pieza adecuada. El valor aparece cuando buscas una solución más simple, integrada y con menos moving parts.

Arquitectura mental: datos, pasos y recuperación

Piensa el flujo como tres capas. Primero, los datos de negocio: por ejemplo, una orden pagada. Segundo, los pasos del workflow: validar, reservar stock, emitir comprobante, avisar al cliente. Tercero, la recuperación: si algo falla, el sistema sabe qué pasó y qué falta.

En una implementación clásica, esa recuperación suele repartirse entre colas, tablas de estado y workers idempotentes. Con pg_durable, la idea es acercar esa información a PostgreSQL para que el propio sistema soporte la continuidad del proceso. Eso puede simplificar el diseño de servicios pequeños y medianos, sobre todo si ya tienes una base de datos bien administrada.

Un ejemplo realista: una fintech en Ecuador que procesa transferencias internas y notificaciones por WhatsApp. Si el proveedor de mensajería cae, el flujo no debería perder la transferencia ni repetir el débito. Guardar el paso exacto y reanudarlo luego vale más que correr otro microservicio solo para “recordar” qué faltaba.

Casos de uso donde sí tiene sentido

No todo workflow necesita ejecución durable dentro de la base. Si tienes tareas cortas, triviales y poco sensibles, una cola simple puede bastar. Pero hay escenarios donde la propuesta de Microsoft encaja muy bien y te puede ahorrar bastante operación.

El primero es el procesamiento de pagos. Ahí importa no duplicar cobros, no perder confirmaciones y poder reintentar llamadas a proveedores externos con control fino. El segundo es onboarding de usuarios, donde una sola alta puede disparar creación de cuentas, envío de correos, validación de identidad y provisión de recursos. El tercero es automatización interna, como aprobaciones, sincronización de catálogos o generación de documentos.

También funciona para sistemas que ya usan PostgreSQL como centro de gravedad. Si tu backend está en Node.js, Python, Go o .NET y la mayor parte del estado vive en Postgres, agregar otra plataforma para coordinar pasos puede ser demasiado. En LatAm esto se nota aún más cuando los equipos son pequeños y la operación tiene que ser sencilla de mantener.

Ejemplos concretos de implementación

1. Una tienda online en Perú recibe un pedido, reserva inventario, cobra con tarjeta y genera guía de despacho. Si el gateway de pago falla, el workflow queda pausado y se reanuda sin repetir la reserva.
2. Un SaaS B2B en Colombia crea un cliente, configura su tenant, envía invitaciones y aprovisiona integración con terceros. Si una API externa tarda 90 segundos, el proceso no se pierde.
3. Una empresa de logística en Chile valida una orden, asigna un conductor, notifica por SMS y registra el evento en auditoría. Si el SMS falla, el resto del flujo sigue controlado.
4. Un equipo en Ecuador automatiza aprobaciones internas de compras: solicitud, revisión, aprobación, emisión de orden y archivo. Si un aprobador no responde, el estado queda persistido y visible.

En estos casos, el beneficio no está solo en “hacerlo funcionar”. Está en operar menos piezas. Menos infraestructura significa menos costos de mantenimiento, menos debugging distribuido y menos dependencia de una plataforma externa para algo que tu base de datos ya puede ayudar a coordinar.

Qué mirar antes de adoptarlo

Antes de probar pg_durable en producción, conviene revisar tres cosas: el tipo de carga, la madurez del equipo y el nivel de aislamiento que necesitas. Si tu equipo ya domina PostgreSQL, la curva de entrada será más amable. Si no, meter lógica de orquestación en la base puede complicar el mantenimiento.

También tienes que pensar en idempotencia. Aunque la ejecución sea durable, muchos pasos seguirán llamando APIs externas o escribiendo en sistemas de terceros. Si un paso se reintenta, no quieres cobrar dos veces ni mandar el mismo correo dos veces. La durabilidad reduce pérdidas, pero no elimina la necesidad de diseñar bien cada acción.

Por último, mira el costo operativo real. A veces sumar una extensión a Postgres es más simple que operar un sistema nuevo. Otras veces, no. Si tu organización ya tiene colas, observabilidad, despliegues y runbooks para un orquestador, migrar solo por novedad no tiene sentido. La decisión debe salir de números y de complejidad, no de moda.

Lo que significa para equipos en LatAm

En América Latina muchas veces el problema no es solo técnico, también es operativo. Hay equipos pequeños, presupuestos ajustados y una presión fuerte por sacar producto sin multiplicar servicios. En ese contexto, una solución que aprovecha PostgreSQL para ejecución durable puede ser atractiva porque reduce la cantidad de piezas que debes aprender, monitorear y pagar.

Eso no quiere decir que sea la respuesta para todo. Pero sí puede ser una buena alternativa para startups, fintechs, e-commerce y plataformas internas donde Postgres ya es el centro del sistema. Si tu equipo en México, Colombia, Chile, Perú o Ecuador ya tiene expertise en SQL y la base está bien cuidada, la barrera de entrada baja bastante.

También hay un detalle práctico: muchas organizaciones de la región todavía prefieren evitar stacks demasiado fragmentados. Cada servicio nuevo agrega costos de soporte, alertas, backups y capacitación. Una extensión que vive cerca de los datos puede ser más fácil de justificar que una plataforma completa adicional, siempre que el caso de uso encaje.

Preguntas técnicas que deberías hacerte

Antes de mover nada a producción, hazte estas preguntas:

• ¿Cuántos pasos tiene el workflow promedio y cuánto tarda cada uno?
• ¿Qué pasa si un paso externo falla dos o tres veces seguidas?
• ¿Necesitas reanudar exactamente en el paso fallido o rehacer parte del proceso?
• ¿Tu equipo sabe operar PostgreSQL con buen nivel de detalle?
• ¿La carga esperada justifica una solución integrada o una plataforma separada?

Si respondes con claridad a esas preguntas, la evaluación será mucho más honesta. No se trata de adoptar pg_durable porque Microsoft lo publicó, sino porque resuelve un problema concreto con menos complejidad que las alternativas disponibles.

Tabla resumen

Si te quedas con una sola idea, que sea esta: pg_durable no intenta reemplazar todas las herramientas de workflow, sino acercar la ejecución durable a donde ya están tus datos. Esa cercanía puede ahorrarte bastante complejidad si tu producto depende de procesos largos, reintentos y tolerancia a fallos.

En la práctica, la decisión no se toma por hype sino por arquitectura. Si tu sistema ya vive en PostgreSQL y necesitas continuidad de procesos sin montar otra plataforma, vale la pena probarlo en un entorno controlado, medir cómo se comporta y comparar el costo total contra tu solución actual. Ahí está la conversación útil.