这条讨论围绕“Just Use Postgres for Durable Workflows”展开，核心是在问：能不能把 workflow state、队列、重试和业务数据都放进 Postgres，让 ACID 直接提供持久性。评论里反复提到的 absurd（一个基于 Postgres 的 durable workflows 实现）、DBOS（一个把 workflow 状态放进 Postgres 的平台）、Temporal（一个成熟的 workflow engine）和 Restate（一个可自托管的 orchestration 系统）都是这类方案的代表。大家争论的不是“数据库能不能做”，而是“做到什么规模后应该切换到专用系统”，以及切换前会不会自己先长成一个复杂的 workflow engine。评论也补充了很多具体原语和边界条件，比如 LISTEN/NOTIFY、SKIP LOCKED、advisory lock、Cassandra、ClickHouse、VictoriaMetrics 以及大数据量下的 vacuum 和索引问题。
不少人认为，把 durable workflows 直接建在 Postgres 上非常实用，尤其是在吞吐量不是特别夸张时。这样可以把业务状态和队列消息放进同一个 transaction 里，减少丢消息、补偿和多系统同步的复杂度。评论里提到的 absurd、DBOS 以及一些 Rust/TypeScript 自研实现，都强调客户端代码更简单，状态也更容易被人或 coding agent 理解。有人还举例说，AI 工作流、视频处理、通知投递、甚至内部控制面都已经在用这种模式。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12]
另一派的核心担忧是：一旦系统需要 retries、backoff、timeouts、cancellation、versioning、visibility、task routing、heartbeats、replay/debugging 和运维工具，所谓“只是用数据库”很快就会长成一个简化版 workflow engine。很多人指出，最初看起来只是几张表和几个 worker，但随着需求增长，最终会自己补齐一整套专业系统才有的能力。评论里还强调，是否值得这么做，不应只看数据库是否够用，而要看这部分复杂度是不是你的核心业务。也有人把这类自研形容为“买系统”与“自己背维护成本”之间的取舍。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
Temporal 被反复拿来对比：支持者认为它在 workflow 编排、parent/child workflow、Signal/Update 和事件驱动场景上非常强，开发体验也不错。批评者则集中抱怨它的基础设施太重，on-prem 可能要面对 Cassandra 集群、CPU 和运维成本，Cloud 价格与 payload 限制也被认为不够友好。DBOS 和 Restate 则被视为更轻的替代品，前者强调与 Postgres transaction 的原子集成，后者则主打 self-host 和较少 vendor lock-in。也有人直接指出，DBOS 的 tradeoff 是性能上限更容易被 Postgres 卡住。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13] [来源14] [来源15]
评论里也讨论了 Postgres 作为队列和工作流后端时的具体物理边界。有人提到 LISTEN/NOTIFY 在高负载下会遇到全局锁问题，不过 pg19/pg18 的改进被认为会有所缓解；也有人强调 SKIP LOCKED、advisory lock、分区表和更合理的主键设计，才是高并发队列的关键。与此同时，日志、metrics、timeseries 这类高读写负载数据，很多人仍然建议放到 ClickHouse、VictoriaMetrics 之类的专用系统，而不是硬塞进 Postgres。对于 TB 级数据、vacuum、索引扫描和查询放大，有人直接提醒：别把“小规模可行”误读成“永远可行”。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13] [来源14] [来源15] [来源16]
还有一组评论把重点放在 correctness 上，认为 workflow 示例往往过于乐观，忽略了 crash 后恢复、重复执行、补偿失败等真实问题。有人提出 idempotent operations 是另一条更稳的路，也有人说过去尝试把一切塞进 stored procedures，最后会因为版本控制、语言笨重和维护困难而变成灾难。线程里还出现了很多替代方案：Oban、Conductor OSS、PgFlow、pgque、Convex、SpacetimeDB，甚至 SQLite-based 的小规模 durable workflow 实现。另一个细节是 secrets 的处理，很多人都认为它应该与 workflow 状态分离，而不是直接塞进数据库消息里。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13] [来源14] [来源15] [来源16] [来源17] [来源18]
durable workflows: 可在崩溃、重启或失败后继续执行的工作流；状态和进度会被持久化。
atomic messaging: 把业务写入和队列/事件入队放在同一个 database transaction 里提交，避免消息丢失或状态不一致。
LISTEN/NOTIFY: Postgres 的通知机制，用来在数据变化时唤醒 worker 或触发异步处理。
SKIP LOCKED: Postgres 的行锁工作模式，允许多个 worker 安全抢任务而不互相阻塞。
advisory lock: 一种应用级锁，常用于跨进程协调任务、避免重复执行。
idempotent: 幂等：同一操作重复执行多次，结果仍然一致，不会额外污染状态。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。