Postgres的SELECT DISTINCT无法随数据量扩展
DBOS在分区队列场景中发现Postgres的SELECT DISTINCT性能随总行数线性增长而非唯一值数量，原因是Postgres只能做全索引扫描，无法像MySQL那样做loose index scan。作者用10分区、100到100万行的基准测试验证了延迟线性增长，并提出用递归CTE作为替代方案。Postgres 18的skip scan也帮不上忙，2018年曾有人尝试实现loose index scan但被放弃。
Dbos
DBOS 是一个开源持久化执行与工作流编排系统。
评论
点赞
收藏Postgres LISTEN/NOTIFY 实际上可以扩展
针对 Postgres NOTIFY 因全局锁导致并发写入瓶颈的问题，DBOS 团队通过缓冲通知并批量提交的方式优化了 LISTEN/NOTIFY 机制。实测在单台 Postgres 服务器上实现了每秒 6 万次的写入吞吐量和毫秒级延迟，打破了“LISTEN/NOTIFY 无法扩展”的固有认知。文章详细解析了全局锁的原理及 Postgres 19 相关补丁的局限性，为构建高并发实时流系统提供了具体的工程实践方案。
Postgres 事务：分布式系统的超能力
DBOS 团队提出将工作流状态与应用数据共存于同一 Postgres 数据库，利用原生事务解决分布式系统的幂等性和原子性问题。 这种方法消除了对额外出队表和应用层记账逻辑的需求，实现了步骤的精确一次执行语义，简化了复杂工作流的构建。
直接用PostgreSQL做任务队列
DBOS团队分享了在大规模场景下使用PostgreSQL作为任务队列的实践与优化经验。文章指出通过合理使用SKIP LOCKED、调整事务隔离级别以及优化索引，PostgreSQL可以高效处理每秒数千甚至上万的任务吞吐量。 这打破了PostgreSQL不适合高并发任务队列的传统认知。作者详细解释了序列化失败、CPU瓶颈等具体问题的成因及解决方案，适合后端架构师和数据库工程师参考。
在 Postgres 上构建持久化工作流
DBOS 提出一种去中心化的持久工作流架构，主张直接用 Postgres 替代 Temporal 等外部编排器。应用服务器直接通过数据库表进行任务分发与状态检查点记录。 文章认为这种设计能简化架构，利用 Postgres 现有的扩展性、高可用及 SQL 查询能力实现可观测性，降低系统复杂度。
GOTO语句有害论：为何事件驱动是糟糕的架构选择
文章借迪杰斯特拉反对GOTO语句的经典理论，论证在AI Agent和多步骤业务流程中，工作流架构优于事件驱动架构。作者认为事件驱动在处理依赖、原子性和错误恢复时，代码难以理解和调试。 针对电商等复杂场景，工作流能提供更清晰的控制流和更简单的排错体验，因此建议大多数应用采用工作流模式。
利用 PostgreSQL 构建可靠的通知系统
文章介绍如何利用 PostgreSQL 构建可靠的消息通知系统。通过将消息存储在表中并利用事务保证 Exactly-Once 语义，解决分布式系统中的重复和丢失问题。同时结合 LISTEN/NOTIFY 机制实现低延迟推送，避免轮询带来的性能瓶颈。 针对连接断开可能导致通知丢失的问题，文章提供了具体的解决方案和代码示例，帮助开发者在现有 Postgres 架构上实现高可用的消息传递。
PostgreSQL 到底能扩展吗？
DBOS 团队对单台 Postgres 服务器进行了基准测试，发现其写入吞吐量可达每秒 14.4 万次，能支撑每秒 4.3 万次持久化工作流。 文章深入分析了性能瓶颈在于 WAL（预写日志）的磁盘刷新，并提供了详细的测试代码和 AWS 环境配置参数。
用 Postgres 和工作流打通多语言服务
文章介绍利用 Postgres 数据库作为不同语言服务间的通信桥梁，替代传统的消息队列或 RPC 中间件。通过共享数据库 Schema 和统一的 JSON 序列化格式，实现跨语言工作流协调。 这种方法减少了额外基础设施依赖，适合多语言微服务架构场景。
如何为 Go 打造原生支持的可执行工作流库
DBOS 团队介绍如何在 Go 语言中构建原生支持的可执行工作流库。 针对 Go 类型系统的限制，他们设计了扩展 context.Context 的 durable.Context，以在保持单一接口和编译时类型检查的同时实现状态持久化。 文章详细讨论了处理 Deadline 和取消机制的工程细节，以及为解决 Go 不支持变参泛型而采用的包级通用函数方案。此外，还解释了从 Gob 切换回 JSON 进行序列化的原因，以解决异构切片解码难题。
构建可扩展的去中心化工作流
DBOS 团队深入探讨了去中心化工作流系统的架构实现。 文章对比了集中式与去中心化方案，重点解决了多服务器并发执行时的冲突检测、 Cron 调度中的“惊群效应”以及高效队列实现等技术难题。 作者提出利用数据库唯一约束解决重复执行问题，并通过引入随机抖动（Jitter）降低高并发下的数据库写入竞争。这是一篇面向后端工程师和架构师的硬核技术分享，提供了具体的工程落地思路。
2025 数据界回顾：与 Mike Stonebraker 和 Andy Pavlo 的对谈
DBOS 举办了一场网络研讨会，由图灵奖得主 Mike Stonebraker 和卡内基梅隆大学教授 Andy Pavlo 共同回顾 2025 年数据技术趋势。两人讨论了 AI 是否是泡沫、图数据库的前景、AI Agent 是否会取代 DBA 以及 Postgres 初创公司的并购潮等话题。
AI Agent为何行为怪异？用持久化工作流解决调试难题
针对AI Agent因非确定性导致的调试难题，提出利用持久化工作流（Durable Workflows）进行故障复现与修复的方案。通过记录每一步LLM调用状态，实现类似Git分支的“Fork”操作，隔离并快速迭代修复Agent的错误行为。 文章介绍了DBOS提供的持久化工作流技术，该技术通过数据库检查点记录Agent执行轨迹，解决复杂长程Agent难以复现Bug的问题。作者强调通过强制确定性来降低调试成本，并推广其开源框架。
十五年后，我解决了分布式队列难题
作者结合在 Reddit 维护基础设施的经验，分析了传统分布式队列（如 RabbitMQ）在系统崩溃时容易丢失数据的问题。文章介绍了持久化队列（Durable Queues）的概念，即利用数据库作为消息代理和后端，实现故障恢复时的断点续传。 文章对比了持久化队列与传统内存队列在性能和可靠性上的权衡，建议在高价值、低并发的业务场景中使用持久化队列，并提到了 DBOS 提供的解决方案及相关案例。
分布式系统测试心得：从混沌测试中发现隐蔽 Bug
DBOS 团队分享了测试持久化工作流库的经验。文章对比了形式化验证、确定性模拟和混沌测试，认为后两者在应对复杂依赖时更具实用性。 作者详细描述了如何通过随机注入故障来验证系统不变性，并分享了一个因数据库断连导致的罕见竞态条件 Bug 及其修复过程。
为什么你应该用 Postgres 构建持久化工作流
DBOS 团队分享为何选择 PostgreSQL 作为持久化工作流的数据存储。文章重点分析了 Postgres 在并发控制、可观测性查询和事务一致性方面的技术优势。 作者通过分布式队列锁机制、SQL 索引优化和 Exactly-Once 语义实现细节，展示了如何利用 Postgres 特性解决工作流系统的扩展性与可靠性问题。
如果持久化执行是一个更简单的架构决策
文章认为持久化执行应是软件默认选项，但传统方案如 AWS Step Functions 或 Temporal 需要重构架构且成本高昂。 作者介绍 DBOS 库可直接在代码中实现持久化，无需额外服务，旨在推广其开源产品。
持久化工作流架构基准测试：Temporal 与 DBOS 对比
DBOS 发布了一篇对比博客，比较了使用外部编排系统 Temporal 和嵌入式库 DBOS 实现持久化工作流的架构差异。文章通过一个文档索引应用案例，指出 DBOS 仅需少量代码修改即可集成，而 Temporal 需要重构应用并增加服务依赖。 作者认为嵌入式方案更符合业务逻辑紧密耦合的特点，且减少了额外故障点。但这篇内容带有明显的 DBOS 推广性质，旨在突出其产品的易用性和架构优势，属于厂商视角的技术选型对比。
利用分支处理工作流故障
文章提出工作流“Fork”机制，允许从特定步骤和代码版本重启流程，复用已计算结果以快速恢复故障。通过计费场景示例，展示了如何处理下游服务中断或代码Bug导致的批量失败，并简述了基于数据库Checkpoint的实现原理。 该方案旨在解决大规模工作流运维中的痛点，强调恢复过程需具备上下文感知能力。虽然提供了具体的实现思路，但主要服务于DBOS框架用户，通用性讨论价值中等。
为什么你的工作流应该变成 Postgres 数据行
文章提出将工作流状态直接存储在 Postgres 数据库中，通过 SQL 查询即可管理业务流程。 作者认为这种方式比传统日志监控更直观，能简化复杂故障下的恢复与排查过程。
新型三层应用架构：引入工作流编排层
文章提出在后端微服务化的今天，传统三层架构需要增加“编排层”来解决分布式事务和异步协调难题。作者对比了自建方案与专用编排系统，认为后者虽易用但带来额外复杂性。 DBOS 提出嵌入式工作流编排作为新方向，旨在降低性能开销并简化开发体验，让开发者能更直观地处理分布式系统中的故障恢复。