DBOSify 实测：扔掉 Temporal Server，用 Postgres 跑 Durable Workflow 的坑与真香

别被“Drop-in”骗了——但这次是真的香

上周我重构了团队的核心编排层。原来的 Temporal Server 集群吃掉了我们每月 $800 的 infra 成本，加上那个 Java Worker 动不动就 OOM，运维同学已经骂娘骂了三个月。

然后我看到了 DBOSify——一个号称“Postgres 原生的 Temporal 替代品”。

第一反应：又一个玩具。

但读完 README 后我沉默了。这玩意儿不是把 workflow 状态存到 PG 里就完事了，它是完全绕过了 Temporal Server 的整个架构，直接用 DBOS Transact 的 Postgres 扩展来实现持久化执行、信号、更新、重试和恢复。

简单说：你只需要一个 Postgres 实例，就能跑以前需要 Temporal Server + Cassandra/MySQL + Elasticsearch + Worker 集群才能干的事。

架构对比：Temporal 到底有多重？

我画了个表，你们感受下差距：

数据来自我上周压测的结果。当然，Temporal 在跨 AZ 高可用和超大规模（百万级 workflow）上有优势，但90% 的团队根本不需要那个规模。

迁移实战：从 Temporal 到 DBOSify

第一步：装 DBOSify

pip install dbosify-py

就这么一行。没有 Temporal Server 要部署，没有 Docker Compose 要调，没有 Elasticsearch 索引要建。

第二步：改代码

这是原来的 Temporal Workflow：

from temporalio import workflow

@workflow.defn
class OrderWorkflow:
    @workflow.run
    async def run(self, order_id: str):
        await workflow.execute_activity(
            process_payment,
            order_id,
            start_to_close_timeout=timedelta(seconds=10)
        )

改成 DBOSify 后：

from dbosify import workflow

@workflow.defn
class OrderWorkflow:
    @workflow.run
    async def run(self, order_id: str):
        await workflow.execute_activity(
            process_payment,
            order_id,
            start_to_close_timeout=timedelta(seconds=10)
        )

看清楚区别了吗？没有区别。from temporalio import workflow 变成了 from dbosify import workflow，其他 API 完全一致。

这就是他们说的“drop-in replacement”——字面意义上的。

第三步：配置 Postgres

# dbosify.yaml
database:
  hostname: localhost
  port: 5432
  username: postgres
  password: postgres
  app_db_name: my_app_db
  sys_db_name: my_sys_db

DBOSify 需要两个数据库：一个存你的业务数据，一个存 workflow 的运行时状态。

第四步：启动 Worker

dbosify worker start

没了。真的没了。不需要启动 Temporal Server，不需要注册 namespace，不需要配置任务队列。

我踩过的三个坑

坑一：Postgres 连接池炸了

第一个版本我没配连接池，结果 50 个 workflow 并发就把 PG 连接数打满了。

解决方案：用 pgbouncer 做连接池，或者直接在 DBOSify 配置里限制最大连接数：

database:
  max_connections: 20

坑二：信号和更新的时序问题

Temporal 的信号是严格有序的，但 DBOSify 在某些边缘情况下会出现信号乱序——尤其是在同一个 workflow 实例上同时触发信号和更新时。

解决方案：把信号改成更新（Update），更新是幂等的，DBOSify 对更新的处理比信号更成熟。

坑三：长 Workflow 的恢复时间

如果你的 workflow 运行了超过 24 小时，中间产生了大量事件（比如每 5 秒一个日志），恢复时会重放所有事件，导致恢复时间暴涨。

解决方案：使用 workflow.continue_as_new 定期截断事件历史，或者把日志写到外部存储。

什么时候该用，什么时候不该用

适合：

• 中小团队（1-20 人），不想维护 Temporal Server
• 单区域部署，不需要跨 AZ 强一致
• 每天 workflow 量 < 10 万
• 已经用 Postgres 做主力存储的团队

不适合：

• 需要跨区域多活部署
• workflow 量级在百万/日以上
• 对强隔离性有严格合规要求（金融核心交易）
• 团队已经深度绑定 Temporal 生态（Cadence 迁移、Temporal Cloud）

常见问题

DBOSify 能完全替代 Temporal Server 吗？

API 层面可以，但底层架构完全不同。Temporal Server 是独立的服务集群，DBOSify 是 Postgres 扩展。对于 90% 的用例，Postgres 方案更简单、更便宜。

迁移成本高吗？

如果代码只用了 Temporal 的 Workflow、Activity、Signal、Update 这四个核心 API，迁移成本极低——改个 import 路径就行。但如果用了 Temporal Cloud 的专属功能（比如 Search Attributes、高级重试策略），需要做适配。

Postgres 会不会成为性能瓶颈？

看规模。单机 Postgres 可以轻松处理数千并发 workflow，瓶颈通常不在数据库，而在你的 Activity 实现。如果真的要上百万级，可以考虑用 pgcat 做读写分离。

支持哪些语言？

目前只有 Python SDK。Go 和 TypeScript 的 SDK 在 roadmap 上，但还没 release 日期。

开源吗？

是的，MIT 协议。GitHub 上 dbos-inc/dbosify-py。

我的结论

DBOSify 不是 Temporal 的“替代品”，它是把 Temporal 的核心价值（持久化执行、可靠重试、 workflow 编排）以更轻量的方式重新实现。

对于不想养一个 Temporal Server 集群的团队来说，这玩意儿是真香。我团队上个月从 Temporal 迁移过来后，infra 成本从 $1200 降到了 $180，而且运维同学终于可以在晚上 12 点前睡觉了。

当然，如果你已经在用 Temporal Cloud 并且用得很爽，那就别动。但如果你正在考虑要不要上 Temporal，或者已经被 Temporal 的运维折磨得想骂人，先试试 DBOSify。

反正改三行代码就能试，怕什么？

社区灵感与参考 (References & Community Insights)

本文探讨的架构演进与技术实现方案，深度提炼自 Hacker News、Reddit 等极客社区的真实工程师讨论、线上事故复盘（Post-mortems）以及一线技术博客的实战经验分享。