Microsoft abre workflows durables en PostgreSQL

Microsoft abrió una pieza que vale la pena mirar con calma: pg_durable, una extensión open source para ejecutar workflows durables dentro de PostgreSQL. Si tu backend depende de tareas que no pueden fallar a mitad de camino, de reintentos, de estados intermedios y de procesos largos que no quieres reconstruir a mano, esto te toca de cerca.

La idea central es simple de explicar y difícil de hacer bien: mover la lógica de orquestación al mismo lugar donde ya guardas datos, transacciones y consistencia. En vez de repartir el estado del workflow entre una cola, un worker, una base y varios servicios auxiliares, pg_durable propone usar PostgreSQL como base de ejecución durable. Según el repositorio oficial de Microsoft, el proyecto está disponible en GitHub y apunta a ejecutar workflows con persistencia y tolerancia a fallos dentro de la base de datos. Fuente: https://github.com/microsoft/pg_durable

Qué problema intenta resolver

En muchos backends, un workflow no es solo una función larga. Es una secuencia de pasos que puede incluir llamadas HTTP, escrituras en base de datos, esperas, reintentos, compensaciones y decisiones condicionales. Si algo falla en el paso 4 de 9, no quieres repetir todo desde cero ni dejar el sistema en un estado raro. Ahí es donde entra la durable execution.

Hoy, muchas arquitecturas resuelven esto con herramientas externas como colas, schedulers o motores de workflow. Funcionan, sí, pero también agregan piezas que debes operar, monitorear y mantener sincronizadas. Si tu equipo es pequeño, o si tu producto vive sobre PostgreSQL desde el inicio, cada componente nuevo suma complejidad operativa. Y en LatAm esto pesa más de lo que parece, porque no siempre tienes el mismo margen de infraestructura, observabilidad o personal que una empresa grande en Silicon Valley.

pg_durable apunta justamente a ese hueco: workflows que sobreviven reinicios, fallos parciales y procesos largos sin obligarte a sacar la lógica fuera de la base. No significa que PostgreSQL deba hacer todo. Significa que puedes centralizar una parte crítica del control de estado en un sistema que ya conoces y que probablemente ya administras 24/7.

Durable execution, en términos prácticos

Si lo llevas a terreno real, durable execution significa que el sistema recuerda en qué paso iba un workflow y puede retomarlo sin repetir pasos que ya se completaron. Eso es útil para cosas como:

• procesamiento de pagos con validaciones y confirmaciones
• envíos de correos o mensajes con reintentos
• sincronización entre servicios internos
• aprovisionamiento de cuentas o recursos
• jobs que tardan minutos u horas y no deben perder progreso

La diferencia con un job runner tradicional es que el estado deja de vivir solamente en memoria o en una cola temporal. El workflow se vuelve rastreable y persistente. Si el proceso se cae, la información para retomarlo sigue ahí.

Por qué PostgreSQL es una base atractiva para esto

PostgreSQL ya resuelve transacciones, aislamiento, índices, locks, integridad referencial y persistencia confiable. Para muchos equipos, además, es la base más madura que tienen en producción. Por eso tiene sentido que Microsoft explore una extensión como pg_durable: si el estado del negocio ya vive en Postgres, meter la ejecución durable cerca de ese estado reduce saltos entre sistemas.

Eso no elimina todas las complejidades. Pero sí puede recortar una parte importante del costo de arquitectura. Menos servicios, menos moving parts, menos superficie para errores de integración.

Cómo funciona la propuesta de Microsoft

El repositorio de pg_durable describe una implementación open source para durable execution en la base de datos. Sin entrar en detalles no confirmados por la documentación, el enfoque general es el de registrar el progreso del workflow, persistir su estado y permitir reanudación controlada. Eso suena abstracto hasta que lo comparas con un patrón clásico: un worker que ejecuta pasos, guarda checkpoints y reintenta donde corresponde.

La diferencia es que aquí la base de datos no solo almacena resultados finales. También participa en el control del flujo. Eso puede ser útil si quieres evitar inconsistencias entre “lo que pasó” y “lo que quedó registrado”.

Si quieres revisar la fuente oficial, puedes mirar el proyecto en GitHub y la documentación asociada del repositorio: https://github.com/microsoft/pg_durable

Lo que sí resuelve y lo que no

No conviene vender esto como una solución mágica para todo. pg_durable puede ayudarte a persistir y retomar workflows, pero no reemplaza automáticamente el diseño de tu dominio. Si tu proceso tiene pasos externos lentos o frágiles, igual necesitas pensar en idempotencia, timeouts, compensaciones y observabilidad.

Tampoco significa que debas meter toda tu lógica de negocio dentro de la base solo porque puedes. Hay una línea sana entre “usar la base para coordinar” y “transformar la base en un monolito difícil de mantener”. La clave está en elegir workflows que realmente se benefician de durabilidad fuerte y reanudación confiable.

En otras palabras, pg_durable no elimina la necesidad de diseñar bien. Solo te da una plataforma más cercana al dato para hacerlo.

Ejemplo de flujo realista

Imagina una plataforma de e-commerce en Quito, Lima o Bogotá que procesa órdenes con validación antifraude, reserva de inventario y confirmación de pago. Si el servicio de pagos responde, pero el de inventario se cae, no quieres dejar la orden en un limbo. Un workflow durable puede registrar que el pago fue aprobado, esperar a que el siguiente paso vuelva a estar disponible y continuar desde ahí.

Ese tipo de secuencia también sirve para automatizaciones internas. Por ejemplo, una empresa de servicios puede abrir un caso, consultar sistemas externos, generar una tarea para soporte y enviar una notificación a WhatsApp o email. Si una parte falla, el proceso no debería perder el contexto.

Qué cambia en arquitectura backend

La primera ganancia es obvia: menos piezas para coordinar. Si hoy usas una combinación de base de datos, cola, worker y scheduler, pg_durable puede reducir parte de esa dispersión. Eso no siempre significa simplificar todo el stack, pero sí puede hacer más compacta la capa de orquestación.

La segunda ganancia es de consistencia. Cuando el estado del workflow y el estado del negocio están muy separados, aparecen bugs raros: pasos duplicados, tareas huérfanas, reintentos que no saben si ya hicieron efecto. Tener más cerca el registro del workflow ayuda a que el sistema sea más predecible.

La tercera ganancia es operativa. Si tu equipo ya sabe administrar PostgreSQL, sumar una extensión puede ser más llevadero que operar una plataforma nueva desde cero. Eso sí, también cambia tu responsabilidad: ahora debes mirar el impacto de los workflows sobre la base, los tiempos de respuesta y el uso de recursos.

Cuándo te conviene evaluarlo

Te conviene mirar pg_durable si estás en alguno de estos escenarios:

1. Tu producto ya usa PostgreSQL como base principal.
2. Tienes workflows con varios pasos y reintentos.
3. Necesitas continuidad después de fallos o reinicios.
4. Quieres reducir dependencia de una capa externa de orquestación.
5. Tu equipo prefiere consolidar infraestructura antes que sumar más servicios.

Si, en cambio, manejas millones de eventos por minuto, necesitas orquestación muy distribuida o ya tienes una plataforma madura de workflow automation, puede que esta propuesta sea más una pieza complementaria que un reemplazo.

Riesgos que debes mirar antes de adoptarlo

No todo lo que corre dentro de la base es automáticamente mejor. Hay tres riesgos claros:

• carga adicional sobre PostgreSQL si abusas de workflows pesados
• dificultad para separar lógica de dominio y lógica de orquestación
• dependencia de una extensión que todavía debes evaluar en madurez y soporte

La documentación oficial y el estado del proyecto te van a decir más que cualquier promesa. Antes de llevarlo a producción, conviene probarlo con un flujo pequeño, medir latencia, consumo de recursos y comportamiento bajo fallos.

Casos de uso donde sí tiene sentido

Hay varios escenarios donde esta idea encaja bien. Uno de los más claros es la automatización confiable de procesos internos. Piensa en onboarding de clientes, generación de contratos, validación de documentos o sincronización entre CRM y ERP. Son procesos con pasos definidos, dependencias claras y necesidad de reanudación.

También encaja en productos que ya trabajan con una lógica transaccional fuerte. Si tu aplicación vende suscripciones, maneja inventario, procesa pagos o coordina múltiples servicios internos, tener un workflow durable cerca del dato puede ahorrarte una buena cantidad de código defensivo.

Y sí, también puede servir para equipos pequeños. Muchas veces el problema no es la falta de capacidad técnica, sino el costo de operar demasiadas herramientas. Si puedes resolver una parte del problema desde PostgreSQL, tu arquitectura puede quedar más simple de entender y de depurar.

Comparación rápida con enfoques comunes

La tabla no dice que una opción sea universalmente mejor. Dice algo más útil: cada enfoque paga un precio distinto. Si ya estás pagando el costo de operar PostgreSQL, sumar durable execution ahí puede ser una jugada razonable para ciertos flujos.

Qué mirar si lo pruebas en tu stack

Antes de entusiasmarte, conviene hacer una evaluación corta y concreta. No necesitas una migración grande para aprender bastante. Un piloto bien diseñado te puede decir si la extensión encaja o no con tu realidad.

Checklist de prueba mínima

1. Define un workflow de 3 a 5 pasos con un fallo controlado.
2. Mide cuánto tarda en persistirse cada transición.
3. Simula reinicio del proceso a mitad del flujo.
4. Verifica si retoma donde debía y si evita duplicados.
5. Observa el impacto en CPU, memoria y latencia de PostgreSQL.
6. Repite la prueba con concurrencia moderada, por ejemplo 20 a 50 flujos simultáneos.

Si el piloto ya muestra problemas de consistencia o de carga, no lo lleves a producción todavía. Si funciona bien, recién ahí vale la pena pensar en una adopción más amplia.

Señales de que vas por buen camino

Vas por buen camino si puedes responder afirmativamente a estas preguntas: ¿el workflow se recupera tras un fallo?, ¿el estado es auditable?, ¿tu equipo entiende dónde vive cada parte del proceso?, ¿la base aguanta la carga sin degradarse demasiado?

También ayuda tener observabilidad desde el día uno. Logs estructurados, métricas de duración por paso y trazas de errores te van a ahorrar tiempo cuando algo no cierre. Durable no significa invisible; significa recuperable.

Tabla resumen

Si tu arquitectura backend ya vive alrededor de PostgreSQL, pg_durable merece una prueba seria. No porque vaya a resolver todo, sino porque puede simplificar una parte muy específica y muy costosa: ejecutar procesos largos sin perder el hilo cuando algo falla.

Para equipos en LatAm, donde muchas veces toca hacer más con menos, esto puede ser especialmente útil. Menos servicios, menos fricción operativa y más control sobre el estado real de los procesos. No es una decisión automática, pero sí una opción interesante para poner sobre la mesa cuando tu sistema empieza a necesitar workflows confiables de verdad.