⏱️ Lectura: 12 min
Durante años, construir programas que sobrevivan a una caída del servidor implicó montar un orquestador externo: Temporal, Apache Airflow o AWS Step Functions. El 20 de mayo de 2026, Peter Kraft, cofundador de DBOS, publicó un argumento técnico que desafía esa práctica. Su tesis sobre los workflows durables es directa: si todo se reduce a guardar el estado en una base de datos, entonces la base de datos misma puede oficiar de orquestador y el servidor central sobra.
📑 En este artículo
La idea no es solo teórica. DBOS afirma procesar más de 4.000 millones de workflows por día sobre Postgres, sin un orquestador dedicado. Acá explicamos cómo funciona el patrón, por qué simplifica la arquitectura y qué implica para los equipos de desarrollo en LATAM.
TL;DR
- El 20 de mayo de 2026 DBOS argumentó que Postgres por sí solo basta para ejecutar workflows durables, sin orquestador externo.
- Los workflows durables guardan checkpoints en una base de datos para recuperarse tras una caída, como guardar partida en un videojuego.
- El patrón clásico usa orquestadores como Temporal, Airflow o AWS Step Functions; DBOS sostiene que ese servidor central es innecesario.
- Los workers reclaman tareas con SELECT … FOR UPDATE SKIP LOCKED, garantizando que cada workflow lo ejecute exactamente un worker.
- Un solo Postgres escala a decenas de miles de workflows por segundo; se escala más con CockroachDB o sharding.
- DBOS afirma procesar más de 4.000 millones de workflows por día sobre Postgres.
- La observabilidad es gratis: cualquier consulta sobre el estado de los workflows se expresa en SQL sobre las tablas de checkpoints.
Qué pasó
DBOS es una empresa fundada por investigadores de bases de datos —entre ellos Michael Stonebraker, ganador del premio Turing— que propone un modelo distinto para la ejecución durable. En su publicación del 20 de mayo de 2026, titulada Postgres is All You Need for Durable Workflows, sostienen que la industria se acostumbró a una arquitectura más complicada de lo necesario.
El planteo no ataca la utilidad de los workflows durables, sino la forma en que se implementan. Si la durabilidad consiste en escribir checkpoints a una base de datos, ¿para qué interponer un servidor orquestador entre la aplicación y la base? DBOS responde que no hace falta: la propia base de datos —Postgres, en este caso— puede coordinar todo.
Qué son los workflows durables
Un workflow durable es un programa que registra periódicamente su progreso en una base de datos. La analogía que usa DBOS es la de guardar partida en un videojuego: a medida que el programa avanza, va guardando su estado. Si el proceso se cae —por un despliegue, un corte de energía o un bug—, puede recargar desde el último punto guardado en lugar de empezar de cero.
Esto importa porque muchos procesos de negocio no toleran ejecutarse dos veces ni quedarse a la mitad. Pensá en un flujo de pago: cobrar la tarjeta, descontar inventario, enviar el email de confirmación. Si el servidor muere después de cobrar pero antes de descontar inventario, no querés volver a cobrarle al cliente al reiniciar. Los workflows durables resuelven exactamente eso: cada paso se ejecuta a lo sumo una vez y el flujo se reanuda desde donde quedó.
Un esquema típico en Python con la librería de DBOS se ve así:
from dbos import DBOS
@DBOS.step()
def cobrar_tarjeta(orden_id: str) -> str:
return pasarela.procesar_pago(orden_id)
@DBOS.step()
def descontar_inventario(orden_id: str) -> None:
inventario.reservar(orden_id)
@DBOS.step()
def enviar_confirmacion(orden_id: str) -> None:
correo.notificar(orden_id)
@DBOS.workflow()
def procesar_orden(orden_id: str):
recibo = cobrar_tarjeta(orden_id) # checkpoint 1
descontar_inventario(orden_id) # checkpoint 2
enviar_confirmacion(orden_id) # checkpoint 3
return reciboCada función decorada con @DBOS.step() guarda su resultado en Postgres apenas termina. Si el proceso muere entre el paso 2 y el 3, al reiniciar el workflow no vuelve a cobrar ni a descontar inventario: salta directo a enviar la confirmación.
El patrón de orquestación externa
La forma más común de implementar workflows durables es a través de orquestación externa, el modelo de Temporal, Airflow y AWS Step Functions. Acá, los programas durables se escriben como workflows de pasos cuya ejecución coordina un orquestador central.
El ciclo es el siguiente: un cliente envía un workflow, el orquestador crea un registro en su almacén de datos y lo despacha a un worker. Cada vez que el worker completa un paso, devuelve el resultado al orquestador, que lo guarda como checkpoint y despacha el siguiente paso. Si un worker se cae, el orquestador reasigna sus workflows a otro worker, arrancando desde el último checkpoint.
Funciona, pero DBOS señala el costo oculto: ese orquestador es una pieza de infraestructura más que hay que desplegar, escalar, monitorear y asegurar. Y muchos orquestadores guardan el estado en almacenes clave-valor con modelos de datos limitados, lo que complica las consultas analíticas.
Postgres como orquestador: el mecanismo
En un sistema de workflows durables sobre Postgres, los servidores de aplicación hablan directamente con la base, sin pasar por un orquestador. El flujo cambia de esta manera:
graph LR
C["Cliente"] -->|"INSERT workflow"| PG[("Postgres")]
W1["Worker 1"] -->|"dequeue SKIP LOCKED"| PG
W2["Worker 2"] -->|"dequeue SKIP LOCKED"| PG
W1 -->|"checkpoint paso"| PG
W2 -->|"checkpoint paso"| PGUn cliente envía un workflow creando una fila en una tabla de workflows. Los servidores de aplicación consultan esa tabla para tomar (dequeue) los workflows pendientes y ejecutarlos. A medida que un servidor ejecuta un workflow, va escribiendo el resultado de cada paso a Postgres. Si un servidor se cae, otro recupera sus workflows desde los checkpoints.
La pieza clave para que dos workers no tomen el mismo trabajo es la cláusula FOR UPDATE SKIP LOCKED de Postgres:
-- Un worker reclama un workflow pendiente sin pisar a otro worker
UPDATE workflows
SET status = 'RUNNING',
worker_id = 'worker-7',
started_at = now()
WHERE id = (
SELECT id FROM workflows
WHERE status = 'PENDING'
ORDER BY created_at
FOR UPDATE SKIP LOCKED
LIMIT 1
)
RETURNING *;SKIP LOCKED hace que cada worker que corre esta consulta tome una fila distinta: si una fila ya está bloqueada por otra transacción, Postgres simplemente la salta en vez de esperar. Así, decenas de workers pueden competir por la cola sin coordinarse entre sí y sin duplicar trabajo. Y si por una condición de carrera dos workers intentaran ejecutar el mismo workflow, las restricciones de integridad de Postgres detectan el trabajo duplicado al hacer el checkpoint y uno de los dos se retira.
💭 Clave: El mecanismo no es nuevo: SKIP LOCKED existe en Postgres desde la versión 9.5 (2016) y es la misma técnica que usan colas de tareas como graphile-worker. DBOS la lleva al terreno de los workflows completos, no solo de tareas sueltas.
Escalabilidad y disponibilidad
La escalabilidad y la disponibilidad de un sistema de workflows durables respaldado por base de datos dependen, en el fondo, de la base de datos. El sistema escala horizontalmente agregando más servidores worker, de modo que el techo lo marca qué tan rápido procesa la base. Y como los workers son intercambiables y pueden recuperar el estado de otros, el sistema sigue disponible mientras la base lo esté.
Con Postgres esto juega a favor, porque su escalabilidad y disponibilidad son problemas muy estudiados. Un solo servidor Postgres escala verticalmente hasta decenas de miles de workflows por segundo. Para ir más allá, se puede usar Postgres distribuido (como CockroachDB) o sharding. En disponibilidad, Postgres ofrece replicación por streaming con failover automático, y los servicios administrados traen despliegues multi-AZ con SLAs de alta disponibilidad de fábrica.
La consecuencia práctica es contundente: décadas de ingeniería e investigación dedicadas a operar Postgres a escala se traducen directamente en operar workflows durables. No hay que reinventar la rueda de la confiabilidad.
Observabilidad gratis con SQL
Como los workflows y sus pasos quedan registrados en tablas de Postgres, la observabilidad viene incluida. Podés escanear esos checkpoints para monitorear los workflows en tiempo real y visualizar su ejecución. Y lo mejor: prácticamente cualquier consulta de observabilidad se expresa en SQL.
Por ejemplo, encontrar todos los workflows que fallaron en el último mes es una sola consulta:
SELECT workflow_id, name, error, updated_at
FROM workflow_status
WHERE status = 'ERROR'
AND updated_at > now() - interval '1 month'
ORDER BY updated_at DESC;Parece obvio, pero cuesta sobredimensionar lo potente que es. Solo es posible porque el modelo relacional de Postgres permite expresar filtrados y operaciones analíticas complejas de forma declarativa, apoyándose en décadas de investigación en optimización de consultas. Muchos sistemas con modelos de datos más simples —como los almacenes clave-valor de los orquestadores externos— no tienen ese soporte.
Agregando índices secundarios para acelerar las consultas analíticas, obtenés observabilidad eficiente casi gratis, sin montar un stack de métricas aparte.
💡 Tip: Si ya usás Postgres en producción, podés conectar tu herramienta de BI o un panel de Grafana directamente a las tablas de workflows y armar dashboards sin exportar datos a otro sistema.
Impacto y análisis para equipos en LATAM
Para muchos equipos en la región, la propuesta tiene un atractivo concreto: menos infraestructura que operar. Desplegar y mantener Temporal o Airflow exige conocimiento especializado y recursos que no siempre están disponibles en startups o equipos chicos. Si ya tenés un Postgres —y casi todos lo tienen—, sumar durabilidad sin un componente extra reduce costos y superficie de fallas.
También baja la barrera de entrada. Un desarrollador que entiende SQL y transacciones ya tiene el modelo mental necesario; no necesita aprender la semántica particular de un orquestador propietario. En entornos donde el presupuesto en la nube se cuida con lupa, evitar un servicio administrado adicional puede significar un ahorro real mes a mes.
Conviene matizar: el patrón no es magia. Si tu carga supera lo que un Postgres puede absorber, vas a necesitar sharding o una base distribuida, con su propia complejidad. Y el acoplamiento fuerte a la base de datos implica que su rendimiento es tu techo. Aun así, para la enorme mayoría de los casos de uso —flujos de pago, pipelines de datos, orquestación de tareas de IA—, un Postgres bien afinado sobra.
Qué sigue
DBOS ofrece su modelo a través de librerías de código abierto (DBOS Transact, disponible para Python y TypeScript) y una plataforma administrada. El argumento de fondo, sin embargo, trasciende a la empresa: cuestiona si la complejidad de los orquestadores externos se justifica para la mayoría de los proyectos.
Es probable que veamos más adopción del patrón de base de datos como orquestador, sobre todo a medida que crecen las cargas de trabajo de agentes de IA, que encadenan muchos pasos y necesitan reanudarse con confiabilidad. Si el dato de 4.000 millones de workflows diarios se sostiene, queda claro que Postgres puede con cargas serias. La pregunta que cada equipo deberá responder es si su caso justifica un orquestador dedicado o si, como sugiere DBOS, Postgres ya alcanza.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué es un workflow durable?
Es un programa que guarda checkpoints de su progreso en una base de datos. Si se cae, se reanuda desde el último checkpoint en lugar de reiniciar desde cero, garantizando que cada paso se ejecute a lo sumo una vez.
¿Por qué DBOS dice que no hace falta un orquestador externo?
Porque la durabilidad se reduce a escribir el estado en una base de datos. Si la base ya hace ese trabajo, un servidor orquestador intermedio agrega complejidad sin aportar nada esencial: los workers pueden coordinarse directamente a través de Postgres.
¿Cómo evitan que dos workers ejecuten el mismo workflow?
Usan la cláusula FOR UPDATE SKIP LOCKED de Postgres para que cada worker tome filas distintas de la cola. Si aun así hubiera duplicación, las restricciones de integridad detectan el trabajo repetido al hacer el checkpoint y uno de los workers se retira.
¿Cuánto escala Postgres para esto?
Un solo servidor Postgres maneja decenas de miles de workflows por segundo. Para más, se usa Postgres distribuido (CockroachDB) o sharding. DBOS afirma procesar más de 4.000 millones de workflows por día.
¿Sirve para reemplazar a Temporal o Airflow?
Para muchos casos, sí, sobre todo si ya usás Postgres y querés reducir infraestructura. Para cargas extremas o necesidades muy específicas de un orquestador propietario, conviene evaluar caso por caso.
¿Necesito una versión especial de Postgres?
No. El mecanismo central, SKIP LOCKED, está disponible desde Postgres 9.5 (2016). Cualquier Postgres moderno, incluido un servicio administrado en la nube, funciona.
Referencias
- DBOS Blog — Postgres is All You Need for Durable Workflows, artículo original de Peter Kraft (20 de mayo de 2026).
- PostgreSQL Docs — documentación oficial de SELECT, incluyendo la cláusula FOR UPDATE SKIP LOCKED.
- Temporal — uno de los orquestadores externos de workflows durables citados como referencia del patrón clásico.
- DBOS — sitio oficial del proyecto, con documentación de DBOS Transact y la plataforma administrada.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios