DBOS 相关信息5 月 7 日 DBOS 用户组提到每秒能实现 40,000 个工作流。DBOS 有多种产品包括开源持久执行库 DBOS Transact、代理和工作流的控制平面 DBOS Conductor 等还有相关资源和文档。产品DBOS Transact开源持久执行库DBOS Conductor代理和工作流的控制平面定价资源关于 DBOS认识致力于简化可靠性的团队DBOS 客户了解使用 DBOS 的用户及其原因视频演示、深度剖析等 DBOS 相关内容合作伙伴探索 DBOS 生态系统文档快速入门数分钟内启动首个工作流文档分步指南和实际用例示例应用程序可直接运行的代码激发项目灵感博客还有一些探索相关的链接dbos/dbos-transact-ts持久执行库 - TypeScriptdbos/dbos-transact-py持久执行库 - Pythondbos-inc/dbos-transact-go持久执行库 - Godbos-inc/dbos-transact-java持久执行库 - Javadbos-inc/dbos-demo-appsDBOS 演示应用程序查看所有仓库登录 开始使用7 月 24 日有 DBOS 用户组会议链接为 7 月 24 日DBOS 用户组会议。之后又提到了产品包括 DBOS Transact开源持久执行库、DBOS Cloud一键部署扩展至数百万规模还有 客户案例 定价 博客 文档。资源关于 DBOS了解我们的故事认识我们的团队视频DBOS 概念和最佳实践启动项目登录还有一些链接登录启动项目返回洞察页面Postgres 能扩展吗作者是 Peter Kraft日期为 2026 年 4 月 23 日。基准测试在基于 Postgres 构建持久工作流执行系统时常有人问“Postgres 能扩展吗”。很多顶级技术团队发文称 Postgres 可以扩展但并非所有文章都展示了实际性能扩展情况。此次对单个 Postgres 服务器的可扩展性进行了基准测试重点关注 Postgres 写入性能因为写入是工作流执行的瓶颈。先在理想环境下测量了 Postgres 的原始写入吞吐量然后分析了两种持久工作流工作负载的性能一种是在本地启动工作流另一种是使用 Postgres 支持的队列。结果发现Postgres 的扩展性比预期还好单个服务器可以维持每秒 144,000 次写入的吞吐量或者每秒处理 43,000 个工作流相当于每天 120 亿次写入或 40 亿个工作流能满足大多数用例需求。所有基准测试代码都是开源的可在 此处 查看。所有实验均在 AWS RDS db.m7i.24xlarge 实例上进行该实例拥有 96 个 vCPU、384 GB 内存以及在 io2 卷上配置的 120,000 个 IOPS。Postgres 单点写入性能先测量了 Postgres 对单个表能够维持的最大写入吞吐量使用了一个简单的三列表包含一个 UUIDv7 主键、一个 TEXT 数据字段和一个时间戳。然后通过大量异步 Python 客户端对每秒可以插入的行数进行了基准测试每行数据都在单独的事务中插入。总体而言Postgres 服务器每秒最多可以处理 144,000 次这样的写入相当于每天 120 亿次写入。为确保达到了 Postgres 可扩展性的极限分析了限制进一步性能提升的瓶颈。先检查了 CPU 和 IOPS 等关键指标发现它们并未被充分利用。为找到真正的瓶颈查询了内置的 Postgres pg_stat_activity 表以检查每个 Postgres 后端进程在每个时刻的操作。发现瓶颈在于将 Postgres 预写日志 (WAL) 刷新到磁盘。执行写入操作时Postgres 先将写入描述追加到 WAL 中然后将 WAL 刷新到磁盘使用 fsync 系统调用最后向客户端确认提交实际的数据文件会在后台稍后更新。查看 Postgres 进程活动时发现任何时刻都恰好有一个进程正在将 WAL 刷新到磁盘以 组提交 的方式刷新整个缓冲区包括其他进程的数据而绝大多数其他进程都在等待 WAL 锁以便将其数据刷新。性能瓶颈在于 Postgres 通过将 WAL 条目刷新到磁盘来提交写入事务的速度这是高度写入密集型工作负载常见的瓶颈因为 Postgres 只有一个 WAL每个写入操作都必须经过它。持久工作流性能接着测量了由 Postgres 支持的持久工作流的性能。一个持久工作流恰好执行两次 Postgres 写入一次是在启动时创建其数据库条目并记录其输入和初始状态一次是在完成时记录其结果和最终状态。如果工作流包含步骤还会为每个步骤执行一次写入以检查点该步骤的结果。在这个基准测试中评估了没有步骤的简单无操作工作流。通过多个异步 Python 客户端同时启动了许多工作流。总体而言单个 Postgres 服务器每秒最多可以处理 43,000 个工作流为每秒执行 43,000 个工作流的应用程序添加 Postgres 支持的持久性不会成为其性能瓶颈。与之前的基准测试一样寻找限制进一步性能提升的瓶颈发现瓶颈还是在于 WAL即 Postgres 通过将工作流的 INSERT 和 UPDATE 操作的 WAL 条目刷新到磁盘来提交这些操作的速度。有两个因素解释了原始 Postgres INSERT 性能和工作流性能之间的差异一是一个工作流需要两次写入因此每秒 43,000 个工作流实际上相当于每秒 86,000 次 Postgres 写入二是 workflow_status 表比简单写入基准测试表大得多31 列对 3 列9 个索引对 1 个索引因此对该表的更新需要刷新更多的数据。持久队列性能然后测量了由 Postgres 支持的队列的可扩展性。与之前的基准测试类似但客户端不是直接执行工作流而是将它们排入 Postgres 队列然后工作者从队列中取出并执行这些工作流。每个工作流需要四次 Postgres 写入一次写入用于将工作流排入队列创建其数据库条目并记录其输入和初始状态一次写入用于从队列中取出工作流更新其状态此写入与同一执行器在同一时间取出的所有其他工作流一起批量处理一次写入是在取出的工作流启动时更新其状态一次写入是在工作流完成时记录其结果和最终状态。总体而言单个 Postgres 服务器每秒最多可以处理 12,100 个排队的工作流。寻找性能瓶颈时发现这次的瓶颈不是在 WAL而是在 workflow_status 表中的锁争用。所有客户端进程都在队列头部的相同几行上进行入队或出队操作它们之间的争用限制了性能尽管有 SKIP LOCKED 等优化措施。推测 Python 是一种相对低效的语言加剧了这个问题因为需要大量客户端才能使 Postgres 达到饱和状态。如果使用像 Go 这样更快的语言所需的客户端数量会更少从而减少出队争用。为消除争用瓶颈测试了将工作分布到多个队列或者等效地同一队列的多个分区发现可实现的最大工作流吞吐量随着队列数量的增加而增加但收益递减。最终通过足够多的队列或分区排队工作流的吞吐量达到了每秒 30,600 个工作流大约是直接启动工作流时实现的每秒 43,000 个工作流的三分之二这是合理的因为排队工作流需要更多的写入操作三次非批量写入和一次批量写入而直接启动工作流只需要两次非批量写入。在这个规模下数据库瓶颈再次转移到了 WAL。总体而言这个基准测试表明Postgres 的扩展性非常出色。在一秒内单个 Postgres 服务器可以执行 144,000 次小写入操作或者处理 43,000 个持久工作流相当于每天 120 亿次写入或 40 亿个工作流足以满足大多数应用程序的需求。如果需要更高的性能可以将工作负载分布到多个 Postgres 服务器上以处理几乎任何负载。了解更多如果喜欢构建可扩展、可靠的系统DBOS 很乐意听取意见。DBOS 的目标是让持久工作流尽可能简单和高效。可查看以下内容快速入门https://docs.dbos.dev/quickstartGitHubhttps://github.com/dbos-incDiscord 社区https://discord.gg/eMUHrvbu67分享此文章洞察近期文章持久执行、AI 工作流等领域的最新动态。基准测试2026 年 4 月 23 日Postgres 能扩展吗对单个 Postgres 服务器的工作流执行和工作流排队可扩展性进行基准