DBOS dice que las colas de Postgres pueden alcanzar 30,000 flujos de trabajo por segundo

Why it matters

DBOS is testing whether developers can collapse queues, workflow recovery, and application state into Postgres. Its vendor-published benchmark reports high throughput under a defined no-op workload while exposing the hardware, partitioning, and database limits operators must consider.

DBOS cofundadores Qian Li y Peter Kraft dicen que alcanzaron alrededor de 30,000 ejecuciones de flujos de trabajo por segundo con una cola respaldada por Postgres, después de cambios en los bloqueos, el aislamiento de transacciones y los índices. El resultado respalda su apuesta mayor: los desarrolladores pueden ejecutar trabajos duraderos sin añadir un servicio separado de encolamiento y orquestación.

Li y Kraft publicaron los hallazgos en una publicación de ingeniería del 2 de junio. Su trabajo identificó tres cuellos de botella que aparecían en secuencia conforme aumentaba el rendimiento: trabajadores compitiendo por las mismas filas, transacciones que abortaban repetidamente bajo concurrencia e índices que consumían CPU de la base de datos.

El proyecto sigue años de investigación en bases de datos por parte de ambos fundadores. Li completó un doctorado en ciencias de la computación en Stanford enfocado en computación en la nube eficiente y confiable después de obtener su licenciatura en Peking University. Su investigación en Stanford incluyó el proyecto académico DBOS que se convirtió en la base del producto comercial. Kraft estudió ciencias de la computación en Harvard antes de cursar un doctorado en Stanford, y trabajó anteriormente en Slicer, el sistema de particionado (sharding) de Google para servicios con estado.

Construyeron DBOS con Michael Stonebraker, el investigador de bases de datos galardonado con el Premio Turing que MIT describe como creador o arquitecto detrás de Postgres e Ingres. Stonebraker ha convertido repetidamente la investigación en bases de datos en empresas, incluida Vertica, que Hewlett-Packard compró por $340 millones, según MIT.

Tres cuellos de botella, tres soluciones dirigidas

El primer problema fue predecible. Múltiples trabajadores intentando extraer los trabajos más antiguos de la misma tabla seleccionaban las mismas filas, dejando a la mayoría compitiendo por trabajo que solo uno podía reclamar.

DBOS resolvió esa contención con FOR UPDATE SKIP LOCKED. La consulta bloquea las filas seleccionadas e indica a los demás trabajadores que las omitan, permitiendo que cada trabajador reclame un lote distinto. La documentación oficial de PostgreSQL dice que SKIP LOCKED puede prevenir la contención de bloqueos cuando múltiples consumidores acceden a una tabla similar a una cola.

DBOS afirma que su cola no podía superar aproximadamente 100 flujos de trabajo por segundo sin ese patrón de bloqueo. La mejora dejó al descubierto un segundo límite en torno a 1,000 flujos de trabajo por segundo, cuando la mayoría de las transacciones de desencolado empezaron a fallar con errores de serialización.

Esas transacciones se estaban ejecutando en REPEATABLE READ, lo que daba a los trabajadores una instantánea estable necesaria para imponer límites globales, como un número máximo de flujos de trabajo en ejecución entre todos los trabajadores. La documentación de PostgreSQL sobre aislamiento de transacciones dice que las aplicaciones que usan REPEATABLE READ deben estar preparadas para reintentar transacciones después de fallos por serialización.

Li y Kraft descubrieron que las colas grandes a menudo dependían de límites por trabajador en lugar de coordinación global. DBOS mantuvo REPEATABLE READ para las colas que usan controles de flujo globales y movió otras colas a READ COMMITTED, que PostgreSQL documenta como su nivel de aislamiento por defecto. DBOS dice que el enfoque condicional eliminó esas fallas de serialización en sus pruebas.

La CPU se convirtió en la siguiente restricción por encima de aproximadamente 8,000 flujos de trabajo por segundo. DBOS rastreó la carga hasta índices secundarios en su tabla de estado de flujos de trabajo. Cada encolado, desencolado y finalización cambiaba datos indexados, mientras que autovacuum tenía que limpiar entradas obsoletas. El índice que servía la consulta de desencolado también devolvía trabajos sin el orden por prioridad y marca de tiempo necesario para seleccionar el siguiente trabajo, forzando a Postgres a ordenar los resultados.

La tercera solución de DBOS fue hacer que los índices secundarios fueran más selectivos y estuvieran más alineados con la consulta de desencolado, después de que DBOS rastreara la presión de CPU al costo de la consulta de desencolado y al mantenimiento de autovacuum/índices.

Qué mide la cifra de 30,600

El rendimiento destacado por DBOS es un benchmark publicado por el proveedor. En un informe de benchmark del 23 de abril de 2026, Kraft dijo que DBOS ejecutó las pruebas contra una instancia AWS RDS db.m7i.24xlarge con 96 virtual CPUs, 384 GB de memoria y 120,000 IOPS aprovisionadas. Las cargas de trabajo eran flujos de trabajo no-op sin pasos, iniciados concurrentemente desde múltiples clientes Python asíncronos para medir la sobrecarga de orquestación más que el tiempo de procesamiento de la aplicación.

DBOS informó que una única cola alcanzó 12,100 flujos de trabajo encolados por segundo antes de que la contención en la cabeza de la cola se convirtiera en el factor limitante. DBOS dijo que alcanzó 30,600 flujos de trabajo encolados por segundo distribuyendo trabajo entre múltiples colas o múltiples particiones de la misma cola. En ese punto, DBOS identificó el write-ahead log de Postgres, por el que deben pasar las escrituras confirmadas, como el cuello de botella.

La publicación del 2 de junio dice que la ruta de encolamiento optimizada respaldada por Postgres de DBOS alcanzó alrededor de 30,000 ejecuciones de flujos de trabajo por segundo en miles de servidores. La investigación suministrada no incluye una reproducción independiente, y la carga de trabajo no-op no establece un techo de producción general para aplicaciones cuyos trabajos realizan trabajo sustancial.

Esas condiciones hacen que el resultado sea mejor leído como la afirmación de ingeniería de DBOS más que como un benchmark verificado de forma independiente: con las elecciones correctas de bloqueo, nivel de aislamiento e indexación, DBOS argumenta que Postgres puede soportar cargas de cola que muchos equipos de otro modo moverían a un servicio dedicado.

El código del benchmark está disponible públicamente bajo la organización de DBOS en GitHub, donde DBOS mantiene bibliotecas de código abierto separadas para Python, TypeScript, Go y Java. Los desarrolladores conectan una biblioteca a Postgres y anotan flujos de trabajo y pasos en el código de aplicación ordinario; DBOS registra el estado de ejecución para que el trabajo interrumpido pueda reanudarse después de una falla de proceso, reinicio o redepliegue.

La apuesta de infraestructura detrás del benchmark

DBOS está vendiendo consolidación arquitectónica. Los stacks dedicados comúnmente emparejan RabbitMQ con Celery o Redis con BullMQ, mientras que plataformas de flujos de trabajo como Temporal operan un servicio de orquestación separado. DBOS quiere que Postgres almacene tanto el estado de la aplicación como el estado de ejecución de los flujos de trabajo, reduciendo el número de sistemas que los desarrolladores deben desplegar y operar.

Ese enfoque presenta un límite obvio. Una cola lo suficientemente grande aún puede saturar su base de datos, y el propio benchmark multi-cola de DBOS alcanzó ese punto en el write-ahead log. El argumento de Li y Kraft es que el techo es lo suficientemente alto para muchas aplicaciones.

DBOS anunció una ronda semilla de $8.5 millones en marzo de 2024, liderada por Engine Ventures y Construct Capital, con la participación de Sinewave y GutBrain Ventures. Desde entonces DBOS ha orientado su lenguaje de producto hacia agentes de IA duraderos a medida que el software impulsado por modelos crea más trabajos de larga duración, llamadas a API externas, reintentos y pasos de aprobación humana.

Un webcast del 16 de julio con Cockroach Labs enfrentó directamente la tesis de bases de datos de Stonebraker contra esa carga de trabajo más nueva. El benchmark de colas aporta el argumento de ingeniería bajo el pitch. Li y Kraft apuestan a que la base de datos ya presente en muchas aplicaciones también puede convertirse en la capa de recuperación y coordinación para sus agentes, trabajos en segundo plano y flujos de trabajo duraderos.