DBOS 表示 Postgres 的队列每秒可达到 30,000 个工作流

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 联合创始人 Qian Li 和 Peter Kraft 表示，他们通过对锁、事务隔离和索引进行调整，在基于 Postgres 的队列上实现了 约每秒 30,000 次工作流执行。这一结果支持了他们更大的赌注：开发者可以在不增加单独的排队和编排服务的情况下运行持久化任务。

Li 和 Kraft 在一篇 6 月 2 日的工程文章 中发布了这些发现。他们的工作识别出随着吞吐量增加按顺序出现的三个瓶颈：工作者争抢相同的行、并发导致事务反复中止，以及索引消耗数据库 CPU。

该项目延续了两位创始人多年的数据库研究。Li 在获得 Peking University 学士学位后在 Stanford 完成了以高效可靠的云计算为重点的计算机科学博士学位。她在 Stanford 的研究包括成为商业产品基础的学术 DBOS 项目。Kraft 在 Harvard 学习计算机科学，随后攻读 Stanford 的博士学位，之前曾参与 Google 面向有状态服务的分片系统 Slicer 的工作。

他们与获得图灵奖的数据库研究员 Michael Stonebraker 一起构建了 DBOS。MIT 将 Stonebraker 描述为 Postgres 和 Ingres 背后的创建者或架构师。Stonebraker 多次将数据库研究转化为公司，包括 Vertica，MIT 报道称 Hewlett-Packard 曾以 3.4 亿美元收购该公司。

Three bottlenecks, three targeted fixes

第一个问题是可以预见的。多个工作者尝试从同一个表中拉取最旧的任务时，会选中相同的行，导致大多数工作者争抢只有一个工作者能领取的任务。

DBOS 用 FOR UPDATE SKIP LOCKED 解决了这种争用。该查询锁定被选中的行并指示其他工作者跳过它们，从而允许每个工作者领取不同的批次。官方的 PostgreSQL 文档 表示 SKIP LOCKED 可以在多个消费者访问类似队列的表时防止锁争用。

DBOS 表示，如果没有这种锁模式，其队列的吞吐量无法超过大约每秒 100 个工作流。该改进暴露了第二个约每秒 1,000 个工作流的限制，此时大多数出队事务开始因序列化错误而失败。

这些事务运行在 REPEATABLE READ 下，该隔离级别为工作者提供了执行全局限制（例如所有工作者间同时运行的最大工作流数）所需的稳定快照。PostgreSQL 的事务隔离文档 表示，使用 REPEATABLE READ 的应用必须准备在发生序列化失败后重试事务。

Li 和 Kraft 发现，较大的队列通常依赖于每个工作者的限额而非全局协调。DBOS 在使用全局流控的队列中保留了 REPEATABLE READ，并将其他队列移至 READ COMMITTED，而后者是 PostgreSQL 文档中所述的默认隔离级别。DBOS 表示，这种有条件的方法在其测试中消除了那些序列化失败。

在大约每秒 8,000 个工作流之上，CPU 成为下一个约束。DBOS 将负载追溯到其工作流状态表上的二级索引。每次入队、出队和完成都会更改被索引的数据，同时 autovacuum 必须清理过时的条目。为出队查询服务的索引还在返回任务时缺少用于选择下一个任务所需的优先级和时间戳排序，迫使 Postgres 对结果进行排序。

DBOS 的第三个修复是使二级索引更具选择性并更紧密地与出队查询对齐，这在 DBOS 将 CPU 压力追溯到出队查询成本和 autovacuum/索引维护之后实施。

What the 30,600 figure measures

DBOS 的头条吞吐量是由厂商发布的基准。在一份 2026 年 4 月 23 日的基准报告 中，Kraft 表示 DBOS 在一台 AWS RDS db.m7i.24xlarge 实例上运行了测试，该实例具有 96 个虚拟 CPU、384 GB 内存和 120,000 个已配置 IOPS。工作负载是没有步骤的无操作工作流，由多个异步 Python 客户端并发启动，以测量编排开销而非应用处理时间。

DBOS 报告称，单个队列在队列头的争用成为限制因素之前达到了每秒 12,100 个排队工作流。DBOS 表示，通过将工作分布到多个队列或同一队列的多个分区，它达到了每秒 30,600 个排队工作流。在那时，DBOS 认定 Postgres 的 write-ahead log（提交写入必须通过的途径）成为瓶颈。

6 月 2 日的文章称，DBOS 优化后的基于 Postgres 的排队路径在数千台服务器上达到了 约每秒 30,000 次工作流执行。所提供的研究未包含独立复现，而且无操作工作负载并不能为那些任务执行大量工作的应用建立一个通用的生产上限。

这些条件使得该结果更适合被解读为 DBOS 的工程性主张，而非独立验证的基准：DBOS 的论点是，通过正确的锁定、隔离级别和索引选择，Postgres 可以承载许多团队本会迁移到专用服务的队列工作负载。

基准代码公开可用，位于 DBOS 的 GitHub 组织下，DBOS 在那里维护面向 Python、TypeScript、Go 和 Java 的独立开源库。开发者将库连接到 Postgres，并在普通应用代码中注释工作流和步骤；DBOS 记录执行状态，以便在进程故障、重启或重新部署后恢复中断的工作。

The infrastructure bet behind the benchmark

DBOS 正在销售架构整合。专用栈通常将 RabbitMQ 与 Celery 配对或将 Redis 与 BullMQ 配对，而像 Temporal 这样的工作流平台则运行单独的编排服务。DBOS 希望 Postgres 同时保存应用状态和工作流执行状态，从而减少开发者必须部署和运维的系统数量。

这种方法带有一个明显的边界。足够大的队列仍然可能使其数据库饱和，DBOS 自己的多队列基准在 write-ahead log 达到了该点。Li 和 Kraft 的观点是，对于许多应用而言，这个上限足够高。

DBOS 在 2024 年 3 月宣布了由 Engine Ventures 和 Construct Capital 领投、Sinewave 和 GutBrain Ventures 参与的 850 万美元种子轮。此后，随着模型驱动的软件产生更多长时间运行的任务、外部 API 调用、重试和人工审批步骤，DBOS 已将其产品语言转向持久化 AI agents。

与 Cockroach Labs 的一次 7 月 16 日网络讲座 将 Stonebraker 的数据库论点直接置于那种新工作负载之上。该队列基准为该宣传提供了工程论据。Li 和 Kraft 的赌注是，许多应用中已存在的数据库也可以成为他们的 agents、后台任务和持久化工作流的恢复与协调层。