pg_durable: Microsoft abre el código de la ejecución durable en la base de datos

Resumen

• pg_durable se ve como parte de una tendencia más amplia de 2026 de “Postgres como cola/orquestador”, junto con otros sistemas de trabajos/colas basados en PG.
• La discusión se divide entre quienes se entusiasman con “llevar el cómputo a los datos” y quienes prefieren firmemente la orquestación y la lógica de negocio en el código de la aplicación.

Ejecución durable en la BD vs orquestadores externos

• Los partidarios argumentan: si Postgres es el principal componente con estado, mantener los flujos de trabajo dentro de la BD simplifica la pila, evita infraestructura adicional (p. ej., Temporal, Airflow), reduce la latencia y los ida y vuelta, y permite que las instantáneas de la base capturen tanto los datos como el estado del flujo de trabajo.
• Los críticos: para flujos de trabajo entre sistemas, los orquestadores externos y los programadores de DAG (Airflow, sistemas tipo Temporal) se consideran una mejor opción; mantienen el control de flujo en lenguajes y cadenas de herramientas familiares.

Casos de uso y beneficios mencionados

• Flujos de trabajo de larga duración / reanudables, pipelines ETL/IA, trabajos tipo cron con semántica exactly-once y reintento desde puntos de control.
• Capacidad de restaurar el “punto en el tiempo” incluyendo los flujos de trabajo, útil para ETL y pipelines de IA estrechamente acoplados al estado de la BD.
• Ayuda cuando las llamadas HTTP y el procesamiento son mayormente orientados a datos y ya apuntan a la base de datos.

Preocupaciones y críticas

• “Huele a procedimientos almacenados”: temor a lógica de negocio oculta, mala observabilidad, presión de escalado centralizada en la BD, IO limitado e integración limitada con APIs externas.
• Problemas de experiencia de desarrollo: sintaxis SQL/DSL incómoda, depuración difícil, herramientas limitadas frente a lenguajes principales y flujos CI/CD.
• Preocupación por cargar bases de datos ya difíciles de escalar con trabajos de larga duración.

Herramientas, versionado y pruebas

• Varios comentarios preguntan cómo versionar, probar, depurar y liberar funciones durables.
• Algunos sostienen que todos los objetos de BD (funciones, triggers) ya deberían estar en control de स्रोत y migraciones; otros dicen que la mayoría de los equipos no tiene flujos de trabajo de BD maduros, así que mantener la lógica en código es más seguro.

Cómo se comporta pg_durable (según el hilo)

• Los flujos de trabajo se definen e inician mediante df.start(...), devolviendo un ID de instancia.
• df.wait_for_signal es por instancia y “exactly once” dentro de esa instancia; llamadas repetidas a df.start crean nuevas instancias.
• Los timeouts y el manejo de errores se presentan como estado del flujo de trabajo e instancias fallidas, aunque la semántica detallada de errores sigue siendo algo poco clara para los lectores.

Meta: Postgres, extensiones y Rust

• Debate secundario sobre si Postgres es lo suficientemente extensible (muchos citan el rico ecosistema de extensiones) frente a pedidos de una reescritura en Rust con una arquitectura más modular.
• Algunos ven la orquestación en la BD como un efecto de plataforma interna; otros la ven como una reutilización pragmática de un sistema maduro y extensible.