企业官网建设流程全解析

DBOS 相关信息

5 月 7 日 DBOS 用户组提到，每秒能实现 40,000 个工作流。DBOS 有多种产品，包括开源持久执行库 DBOS Transact、代理和工作流的控制平面 DBOS Conductor 等，还有相关资源和文档。

产品

DBOS Transact：开源持久执行库
DBOS Conductor：代理和工作流的控制平面
定价

资源

关于 DBOS：认识致力于简化可靠性的团队
DBOS 客户：了解使用 DBOS 的用户及其原因
视频：演示、深度剖析等 DBOS 相关内容
合作伙伴：探索 DBOS 生态系统

文档

快速入门：数分钟内启动首个工作流
文档：分步指南和实际用例
示例应用程序：可直接运行的代码，激发项目灵感

博客

还有一些探索相关的链接：
dbos/dbos-transact-ts：持久执行库 - TypeScript
dbos/dbos-transact-py：持久执行库 - Python
dbos-inc/dbos-transact-go：持久执行库 - Go
dbos-inc/dbos-transact-java：持久执行库 - Java
dbos-inc/dbos-demo-apps：DBOS 演示应用程序
查看所有仓库

登录 开始使用

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/quickstart
GitHub：https://github.com/dbos-inc
Discord 社区：https://discord.gg/eMUHrvbu67

分享此文章

洞察

近期文章

持久执行、AI 工作流等领域的最新动态。

基准测试
2026 年 4 月 23 日
Postgres 能扩展吗？：对单个 Postgres 服务器的工作流执行和工作流排队可扩展性进行基准