DBOS says Postgres queues can reach 30,000 workflows a second

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 co-founders Qian Li and Peter Kraft say they reached about 30,000 workflow executions per second with a Postgres-backed queue, after changes to locking, transaction isolation, and indexes. The result supports their larger bet: developers can run durable jobs without adding a separate queueing and orchestration service.

Li and Kraft published the findings in a June 2 engineering post. Their work identified three bottlenecks that appeared in sequence as throughput increased: workers fighting over the same rows, transactions repeatedly aborting under concurrency, and indexes consuming database CPU.

The project follows years of database research by both founders. Li completed a Stanford computer science PhD focused on efficient and reliable cloud computing after earning her bachelor's degree at Peking University. Her Stanford research included the academic DBOS project that became the foundation for the commercial product. Kraft studied computer science at Harvard before pursuing a Stanford PhD, and previously worked on Slicer, Google's sharding system for stateful services.

They built DBOS with Michael Stonebraker, the Turing Award-winning database researcher MIT describes as a creator or architect behind Postgres and Ingres. Stonebraker has repeatedly turned database research into companies, including Vertica, which Hewlett-Packard bought for $340 million, according to MIT.

Three bottlenecks, three targeted fixes

The first problem was predictable. Multiple workers trying to pull the oldest jobs from the same table would select the same rows, leaving most of them competing for work that only one worker could claim.

DBOS addressed that contention with FOR UPDATE SKIP LOCKED. The query locks selected rows and instructs other workers to skip them, allowing each worker to claim a different batch. The official PostgreSQL documentation says SKIP LOCKED can prevent lock contention when multiple consumers access a queue-like table.

DBOS says its queue could not exceed roughly 100 workflows per second without that locking pattern. The improvement exposed a second limit at about 1,000 workflows per second, when most dequeue transactions began failing with serialization errors.

Those transactions were running at REPEATABLE READ, which gave workers a stable snapshot needed to enforce global limits such as a maximum number of workflows running across all workers. PostgreSQL's transaction-isolation documentation says applications using REPEATABLE READ must be prepared to retry transactions after serialization failures.

Li and Kraft found that large queues often relied on per-worker limits rather than global coordination. DBOS kept REPEATABLE READ for queues using global flow controls and moved other queues to READ COMMITTED, which PostgreSQL documents as its default isolation level. DBOS says the conditional approach eliminated those serialization failures in its tests.

CPU became the next constraint above roughly 8,000 workflows per second. DBOS traced the load to secondary indexes on its workflow status table. Each enqueue, dequeue, and completion changed indexed data, while autovacuum had to clear obsolete entries. The index serving the dequeue query also returned jobs without the priority and timestamp ordering needed to select the next work, forcing Postgres to sort the results.

DBOS's third fix was to make secondary indexes more selective and more closely aligned with the dequeue query, after DBOS traced CPU pressure to dequeue query cost and autovacuum/index maintenance.

What the 30,600 figure measures

DBOS's headline throughput is a vendor-published benchmark. In an April 23, 2026 benchmark report, Kraft said DBOS ran the tests against one AWS RDS db.m7i.24xlarge instance with 96 virtual CPUs, 384 GB of memory, and 120,000 provisioned IOPS. The workloads were no-op workflows with no steps, started concurrently from multiple asynchronous Python clients to measure orchestration overhead rather than application processing time.

DBOS reported that a single queue reached 12,100 queued workflows per second before contention at the head of the queue became the limiting factor. DBOS said it reached 30,600 queued workflows per second by distributing work across multiple queues or multiple partitions of the same queue. At that point, DBOS identified Postgres's write-ahead log, through which committed writes must pass, as the bottleneck.

The June 2 post says DBOS's optimized Postgres-backed queueing path reached about 30,000 workflow executions per second across thousands of servers. The supplied research does not include an independent reproduction, and the no-op workload does not establish a general production ceiling for applications whose jobs perform substantial work.

Those conditions leave the result best read as DBOS's engineering claim rather than an independently verified benchmark: with the right locking, isolation-level, and indexing choices, DBOS argues Postgres can carry queue workloads that many teams would otherwise move to a dedicated service.

The benchmark code is publicly available under DBOS's GitHub organization, where DBOS maintains separate open-source libraries for Python, TypeScript, Go, and Java. Developers connect a library to Postgres and annotate workflows and steps in ordinary application code; DBOS records execution state so interrupted work can resume after a process failure, restart, or redeployment.

The infrastructure bet behind the benchmark

DBOS is selling architectural consolidation. Dedicated stacks commonly pair RabbitMQ with Celery or Redis with BullMQ, while workflow platforms such as Temporal operate a separate orchestration service. DBOS wants Postgres to hold both application state and workflow execution state, reducing the number of systems developers must deploy and operate.

That approach carries an obvious boundary. A sufficiently large queue can still saturate its database, and DBOS's own multi-queue benchmark reached that point at the write-ahead log. Li and Kraft's case is that the ceiling is high enough for many applications.

DBOS announced an $8.5 million seed round in March 2024, led by Engine Ventures and Construct Capital, with Sinewave and GutBrain Ventures participating. DBOS has since shifted its product language toward durable AI agents as model-driven software creates more long-running jobs, external API calls, retries, and human approval steps.

A July 16 webcast with Cockroach Labs placed Stonebraker's database thesis directly against that newer workload. The queue benchmark supplies the engineering argument underneath the pitch. Li and Kraft are betting that the database already inside many applications can also become the recovery and coordination layer for their agents, background jobs, and durable workflows.