Postgres suma ejecución durable para workflows

Postgres ya no sirve solo para guardar filas y responder consultas. Con pg_durable, Microsoft abrió una pieza interesante para ejecutar workflows durables directamente sobre la base de datos, sin obligarte a sumar otra capa solo para coordinar pasos, reintentos y estado.

Si trabajas con sistemas que no pueden perder eventos, pagos, órdenes, tareas programadas o procesos de aprobación, sabes dónde duele: el código de negocio termina mezclado con lógica de retries, colas, locks, cron jobs y tablas auxiliares. Eso funciona un tiempo, pero cuando crecen los casos de falla, también crece el costo de operar.

Qué problema intenta resolver pg_durable

La idea de una ejecución durable es simple de explicar y difícil de implementar bien: tu flujo debe poder seguir desde donde quedó aunque el proceso se caiga, el pod muera, el worker se reinicie o una dependencia tarde más de lo esperado. No basta con “volver a intentar”. Necesitas persistir estado, decisiones y progreso de forma confiable.

En la práctica, muchos equipos terminan armando esa capacidad con una combinación de Redis, RabbitMQ, SQS, tablas de estado, locks optimistas, cron y bastante código propio. Esa mezcla puede funcionar, pero también crea más puntos de falla y más cosas que monitorear. Si tu stack ya usa Postgres como fuente de verdad, mover parte de esa coordinación al mismo motor tiene sentido.

Microsoft publicó pg_durable como proyecto open source en GitHub: pg_durable. La propuesta no es reemplazar todo tu sistema de colas ni convertir Postgres en una plataforma mágica. Es más concreta: darle al motor una capa para ejecutar workflows con durabilidad, de modo que puedas construir procesos resilientes con menos piezas externas.

Qué significa “durable” en este contexto

Durable no significa “rápido por defecto” ni “sin fallas”. Significa que el sistema registra suficiente información para reanudar una ejecución después de una interrupción. Si un paso ya se completó, no lo repites por accidente. Si un paso falló de forma transitoria, puedes reintentarlo sin perder el contexto.

Eso cambia bastante el diseño. En lugar de pensar solo en funciones que corren y terminan, empiezas a pensar en estados, checkpoints y transiciones. El workflow deja de depender tanto de la memoria del proceso y pasa a depender del estado persistido.

Cómo encaja dentro de Postgres

La parte interesante de pg_durable es que se apoya en un componente que ya conoces y probablemente ya operas. Postgres ya te da transacciones, consistencia, locks y observabilidad básica. Agregar durabilidad sobre esa base reduce la necesidad de repartir la lógica entre varios servicios con contratos distintos.

Según la documentación oficial del proyecto, la idea es habilitar ejecución de workflows dentro de la base de datos, usando mecanismos de persistencia para que el proceso sobreviva reinicios y fallos. Puedes revisar el repositorio y su documentación en el enlace oficial: pg_durable en GitHub.

Eso no significa que todo deba vivir dentro de SQL. Lo razonable es pensar en una división: la base administra el estado duradero del workflow y tu aplicación sigue encargándose de la lógica de negocio, la API, la UI y las integraciones externas. Es una separación útil cuando quieres menos infraestructura, pero no quieres perder control.

Una comparación rápida con enfoques comunes

La tabla no dice que una opción sea universalmente mejor. Dice algo más útil: si ya estás pagando el costo operativo de Postgres, quizá no quieras sumar un sistema más solo para coordinar ejecución y reintentos.

Qué ganas si ya usas Postgres como base principal

Primero, reduces el número de componentes críticos. Menos infraestructura suele significar menos despliegues, menos credenciales, menos paneles que revisar y menos incidentes entre servicios que se “hablan” pero no se entienden.

Segundo, simplificas la consistencia. Si tu orden, tu pago y tu workflow viven cerca del mismo sistema de verdad, es más fácil razonar sobre qué pasó y en qué momento. Eso no elimina la complejidad, pero la concentra.

Tercero, facilitas la adopción en equipos chicos o medianos. Para una startup en Quito, Medellín o Lima, operar una cola más un orquestador más un scheduler puede ser demasiado para el tamaño del equipo. Si ya tienes Postgres bien administrado, una solución de este tipo puede ser una forma más pragmática de avanzar.

Casos de uso donde sí tiene sentido

No todos los procesos necesitan ejecución durable. Si solo quieres disparar un email o registrar una métrica, no hace falta complicarlo. Pero hay casos donde la durabilidad cambia la arquitectura de forma clara.

Piensa en un flujo de onboarding que hace 5 pasos: crear cuenta, validar identidad, provisionar recursos, cobrar y notificar. Si el paso 4 falla por un timeout en el gateway de pago, no quieres repetir los pasos 1 al 3. Quieres retomar desde el punto correcto, con trazabilidad y sin duplicar efectos.

Otro ejemplo realista es el procesamiento de órdenes en un e-commerce regional. Tienes inventario, pagos, facturación electrónica y despacho. Cada parte puede fallar por razones distintas, y muchas de esas fallas son transitorias. Un workflow durable te ayuda a ordenar ese caos sin depender de scripts sueltos.

Ejemplos concretos de procesos

1. Pagos con reintentos controlados: si el proveedor responde con error temporal, el workflow espera y reintenta sin duplicar la captura.
2. Aprobaciones internas: una solicitud se pausa hasta que alguien aprueba o rechaza, y el estado queda persistido.
3. Provisioning de infraestructura: crear recursos en secuencia, con checkpoints por paso, para no repetir tareas costosas.
4. Procesos de facturación: generar documento, validar respuesta, registrar resultado y notificar, todo con trazabilidad.
5. Sincronización de datos: mover lotes entre sistemas con checkpoints para continuar desde el último lote exitoso.

En todos esos casos, la ventaja no es solo “que funcione”. La ventaja es que puedas operar el flujo cuando algo falla a mitad de camino. Eso es lo que suele separar un script útil de un sistema que aguanta producción.

Qué cambia para tu arquitectura

La primera consecuencia es que puedes bajar la dependencia de un orquestador externo para ciertos escenarios. Eso no significa eliminar herramientas maduras como Temporal o sistemas de colas, sino elegir mejor cuándo realmente las necesitas.

La segunda consecuencia es más sutil: tu modelo mental se acerca a la base de datos. En vez de tratar el workflow como una caja negra en otro servicio, lo entiendes como una extensión del estado que ya gestionas. Para equipos que ya piensan en tablas, transacciones y eventos, eso reduce fricción.

La tercera consecuencia es operativa. Menos infraestructura no siempre equivale a menos complejidad total, pero sí suele significar menos superficie de fallo. Y cuando el incidente ocurre a las 2:00 a. m., agradecerás tener menos piezas que revisar.

Cuándo no te conviene

No te conviene si tu problema principal es escalar millones de eventos por segundo en colas especializadas. Tampoco si ya tienes un orquestador bien adoptado, observabilidad madura y un equipo que lo domina. Cambiar por cambiar sale caro.

Tampoco lo elegiría para flujos muy simples que no necesitan reanudación. Si el trabajo es efímero, una cola o un job runner puede ser suficiente. La durabilidad agrega valor cuando perder contexto cuesta dinero, tiempo o reputación.

Cómo pensar una adopción realista

Si te interesa probar pg_durable, no empieces migrando todo. Empieza con un flujo acotado, de alto dolor y baja dependencia externa. Un buen candidato suele tener estas características: varios pasos, posibilidad de reintento, estado intermedio y costo claro si se repite una operación.

Luego define métricas antes de tocar código. Por ejemplo: cuántos fallos transitorios tienes por día, cuánto tarda el proceso completo, cuántas veces duplicas trabajo y cuánto tiempo se pierde recuperando tareas manualmente. Sin esa línea base, no sabrás si la solución te ayudó o solo movió el problema.

También conviene revisar la documentación oficial del proyecto y el modelo de ejecución que propone. Empieza por el repositorio en GitHub y por la documentación de Postgres que ya usas para entender límites y comportamiento: PostgreSQL documentation.

Un plan de prueba en 5 pasos

1. Elige un workflow con dolor real: por ejemplo, cobro + notificación + actualización de estado.
2. Mide el comportamiento actual: fallos, reintentos manuales, tiempos de recuperación y duplicados.
3. Modela estados explícitos: pendiente, en progreso, reintentando, completado, fallido.
4. Prueba fallos controlados: mata el proceso, corta red, simula timeout y revisa si retoma bien.
5. Compara costo operativo: menos componentes, menos alertas o menos tiempo de soporte.

Si haces esto con disciplina, vas a saber rápido si la propuesta encaja en tu entorno o si solo te interesa por curiosidad técnica.

Lo que vale la pena mirar con lupa

Hay tres preguntas que deberías hacerte antes de adoptar algo así. La primera: ¿qué pasa con la concurrencia y los reintentos duplicados? Si dos workers intentan avanzar el mismo estado, necesitas reglas claras para evitar inconsistencias.

La segunda: ¿qué tan visible es el workflow? Una solución durable sirve mucho más si puedes inspeccionar estados, pasos y errores sin entrar a logs dispersos. La trazabilidad no es un lujo; es parte del producto.

La tercera: ¿cómo se integra con tu aplicación actual? Si te obliga a reescribir demasiada lógica, el costo puede superar el beneficio. La mejor adopción suele ser la que aprovecha lo que ya tienes, no la que te pide empezar de cero.

Señales de que vas por buen camino

• Tu equipo ya opera Postgres como pieza central.
• Tienes flujos con reintentos, pausas o pasos largos.
• Los incidentes actuales vienen de duplicados, timeouts o recuperación manual.
• Quieres reducir dependencias sin perder control.
• No necesitas una plataforma de orquestación gigante para cada proceso.

Tabla resumen

La lectura práctica es bastante clara: pg_durable no intenta inventar una categoría nueva, sino acercar una capacidad útil al lugar donde ya vive buena parte de tus datos. Para muchos equipos, eso puede ser más valioso que sumar otra plataforma a la lista.

Si tu arquitectura ya depende de Postgres, esta propuesta merece una prueba seria. No porque resuelva todo, sino porque puede quitarte una capa completa de infraestructura en procesos donde la durabilidad importa de verdad.