pg_durable es una extensión de PostgreSQL desarrollada por Microsoft que aporta ejecución duradera a funciones SQL de larga duración, sin necesidad de infraestructura adicional como Redis, Temporal o Airflow. La herramienta responde a un problema habitual: equipos que mantienen su estado en Postgres y necesitan ejecutar trabajos en segundo plano de forma fiable, pero que hoy dependen de una combinación frágil de cron, workers, colas y tablas de estado.
El modelo es nativo en SQL. Una función de pg_durable se define como un grafo de pasos (operadores componibles como ~> y |=>) que PostgreSQL ejecuta y va guardando en checkpoints a medida que avanza. Si la base de datos se cae, se reinicia o un paso falla, la ejecución continúa desde el último checkpoint persistente en lugar de obligar a reconstruir el estado manualmente. El resultado es un flujo de trabajo cuyo código y cuyo estado viven en el mismo lugar que los datos que procesa.
Entre los casos de uso que el repositorio menciona figuran pipelines de embeddings con pgvector (trocear documentos, llamar a una API de embeddings e insertar en pgvector), ingestas por lotes con deduplicación y publicación, mantenimiento programado con aprobación humana, agregaciones en paralelo y llamadas a APIs externas para enriquecimiento o clasificación. También se posiciona como sustituto de orquestadores externos como Airflow, Temporal, Step Functions o Argo para cargas que ya viven dentro de Postgres.
La instalación sigue el camino habitual de cualquier extensión de PostgreSQL: paquetes Debian para PostgreSQL 17 y 18 sobre amd64 publicados como release assets, o compilación desde código fuente con Rust nightly y cargo-pgrx 0.16.1. Tras añadir pg_durable a shared_preload_libraries y reiniciar, la extensión se crea con CREATE EXTENSION pg_durable. El repositorio también ofrece un devcontainer de VS Code y scripts que arrancan un clúster local con pgrx. Por defecto, la extensión aplica seguridad a nivel de fila (RLS) para que cada rol gestione solo sus propias instancias, y el rol del worker en segundo plano debe ser superusuario para saltarse RLS y administrar las instancias de todos los usuarios. Los privilegios se otorgan explícitamente con df.grant_usage('rol').