Dbos

DBOS 是一个开源持久化执行与工作流编排系统。

Postgres 中的"删除"比你想象得贵：大规模删除性能优化实践

DBOS 团队在做基于 Postgres 的持久化执行库时发现：大规模批量删除旧 workflow 居然比执行它们还慢。根本原因是 MVCC：Postgres 的 DELETE 只是给行打戳标记为“死元组”，不会真正释放磁盘空间，旧版本要靠 VACUUM 清理。 加上外键 ON DELETE CASCADE 让删除散落在不同磁盘页上的子表数据，缓存局部性差，性能进一步恶化。解决办法包括：放弃外键、按表物理创建顺序分批删除，并在每轮清理前后手动 VACUUM。 文中还详细复盘了一个“索引查找耗时 20 分钟”的诡异 bug——由于死元组堆积在 created_at 索引最前端，查询必须逐个回表验证元组是否真的存活，导致最坏情况下的性能崩溃。 最后解释了为什么没有采用按时间分区再 DROP PARTITION 的方案：那种方式对短期数据很高效，但对长运行 workflow 和复杂保留策略不友好。 整体是面向 Postgres 用户的实用性工程优化文章，对理解 MVCC 删除行为、索引扫描、VACUUM 时机、缓存局部性、外键取舍有较高参考价值。
评论点赞收藏12 天前

Postgres的SELECT DISTINCT无法随数据量扩展

DBOS在分区队列场景中发现Postgres的SELECT DISTINCT性能随总行数线性增长而非唯一值数量，原因是Postgres只能做全索引扫描，无法像MySQL那样做loose index scan。 作者用10分区、100到100万行的基准测试验证了延迟线性增长，并提出用递归CTE作为替代方案。Postgres 18的skip scan也帮不上忙，2018年曾有人尝试实现loose index scan但被放弃。
评论点赞收藏46 天前

Postgres LISTEN/NOTIFY 实际上可以扩展

针对 Postgres NOTIFY 因全局锁导致并发写入瓶颈的问题，DBOS 团队通过缓冲通知并批量提交的方式优化了 LISTEN/NOTIFY 机制。实测在单台 Postgres 服务器上实现了每秒 6 万次的写入吞吐量和毫秒级延迟，打破了“LISTEN/NOTIFY 无法扩展”的固有认知。 文章详细解析了全局锁的原理及 Postgres 19 相关补丁的局限性，为构建高并发实时流系统提供了具体的工程实践方案。
评论点赞收藏67 天前

Postgres 事务：分布式系统的超能力

DBOS 团队提出将工作流状态与应用数据共存于同一 Postgres 数据库，利用原生事务解决分布式系统的幂等性和原子性问题。 这种方法消除了对额外出队表和应用层记账逻辑的需求，实现了步骤的精确一次执行语义，简化了复杂工作流的构建。
评论点赞收藏89 天前

直接用PostgreSQL做任务队列

DBOS团队分享了在大规模场景下使用PostgreSQL作为任务队列的实践与优化经验。文章指出通过合理使用SKIP LOCKED、调整事务隔离级别以及优化索引，PostgreSQL可以高效处理每秒数千甚至上万的任务吞吐量。 这打破了PostgreSQL不适合高并发任务队列的传统认知。作者详细解释了序列化失败、CPU瓶颈等具体问题的成因及解决方案，适合后端架构师和数据库工程师参考。
评论点赞收藏95 天前

在 Postgres 上构建持久化工作流

DBOS 提出一种去中心化的持久工作流架构，主张直接用 Postgres 替代 Temporal 等外部编排器。应用服务器直接通过数据库表进行任务分发与状态检查点记录。 文章认为这种设计能简化架构，利用 Postgres 现有的扩展性、高可用及 SQL 查询能力实现可观测性，降低系统复杂度。
评论点赞收藏124 天前

GOTO语句有害论：为何事件驱动是糟糕的架构选择

文章借迪杰斯特拉反对GOTO语句的经典理论，论证在AI Agent和多步骤业务流程中，工作流架构优于事件驱动架构。作者认为事件驱动在处理依赖、原子性和错误恢复时，代码难以理解和调试。 针对电商等复杂场景，工作流能提供更清晰的控制流和更简单的排错体验，因此建议大多数应用采用工作流模式。
评论点赞收藏138 天前

利用 PostgreSQL 构建可靠的通知系统

文章介绍如何利用 PostgreSQL 构建可靠的消息通知系统。通过将消息存储在表中并利用事务保证 Exactly-Once 语义，解决分布式系统中的重复和丢失问题。 同时结合 LISTEN/NOTIFY 机制实现低延迟推送，避免轮询带来的性能瓶颈。 针对连接断开可能导致通知丢失的问题，文章提供了具体的解决方案和代码示例，帮助开发者在现有 Postgres 架构上实现高可用的消息传递。
评论点赞收藏145 天前

PostgreSQL 到底能扩展吗？

DBOS 团队对单台 Postgres 服务器进行了基准测试，发现其写入吞吐量可达每秒 14.4 万次，能支撑每秒 4.3 万次持久化工作流。 文章深入分析了性能瓶颈在于 WAL（预写日志）的磁盘刷新，并提供了详细的测试代码和 AWS 环境配置参数。
评论点赞收藏152 天前

用 Postgres 和工作流打通多语言服务

文章介绍利用 Postgres 数据库作为不同语言服务间的通信桥梁，替代传统的消息队列或 RPC 中间件。通过共享数据库 Schema 和统一的 JSON 序列化格式，实现跨语言工作流协调。 这种方法减少了额外基础设施依赖，适合多语言微服务架构场景。
评论点赞收藏193 天前

如何为 Go 打造原生支持的可执行工作流库

DBOS 团队介绍如何在 Go 语言中构建原生支持的可执行工作流库。 针对 Go 类型系统的限制，他们设计了扩展 context.Context 的 durable.Context，以在保持单一接口和编译时类型检查的同时实现状态持久化。 文章详细讨论了处理 Deadline 和取消机制的工程细节，以及为解决 Go 不支持变参泛型而采用的包级通用函数方案。此外，还解释了从 Gob 切换回 JSON 进行序列化的原因，以解决异构切片解码难题。
评论点赞收藏216 天前

构建可扩展的去中心化工作流

DBOS 团队深入探讨了去中心化工作流系统的架构实现。 文章对比了集中式与去中心化方案，重点解决了多服务器并发执行时的冲突检测、 Cron 调度中的“惊群效应”以及高效队列实现等技术难题。 作者提出利用数据库唯一约束解决重复执行问题，并通过引入随机抖动（Jitter）降低高并发下的数据库写入竞争。这是一篇面向后端工程师和架构师的硬核技术分享，提供了具体的工程落地思路。
评论点赞收藏249 天前

2025 数据界回顾：与 Mike Stonebraker 和 Andy Pavlo 的对谈

DBOS 举办了一场网络研讨会，由图灵奖得主 Mike Stonebraker 和卡内基梅隆大学教授 Andy Pavlo 共同回顾 2025 年数据技术趋势。两人讨论了 AI 是否是泡沫、图数据库的前景、AI Agent 是否会取代 DBA 以及 Postgres 初创公司的并购潮等话题。
评论点赞收藏281 天前

AI Agent为何行为怪异？用持久化工作流解决调试难题

针对AI Agent因非确定性导致的调试难题，提出利用持久化工作流（Durable Workflows）进行故障复现与修复的方案。通过记录每一步LLM调用状态，实现类似Git分支的“Fork”操作，隔离并快速迭代修复Agent的错误行为。 文章介绍了DBOS提供的持久化工作流技术，该技术通过数据库检查点记录Agent执行轨迹，解决复杂长程Agent难以复现Bug的问题。作者强调通过强制确定性来降低调试成本，并推广其开源框架。
评论点赞收藏298 天前

十五年后，我解决了分布式队列难题

作者结合在 Reddit 维护基础设施的经验，分析了传统分布式队列（如 RabbitMQ）在系统崩溃时容易丢失数据的问题。文章介绍了持久化队列（Durable Queues）的概念，即利用数据库作为消息代理和后端，实现故障恢复时的断点续传。 文章对比了持久化队列与传统内存队列在性能和可靠性上的权衡，建议在高价值、低并发的业务场景中使用持久化队列，并提到了 DBOS 提供的解决方案及相关案例。
评论点赞收藏387 天前

分布式系统测试心得：从混沌测试中发现隐蔽 Bug

DBOS 团队分享了测试持久化工作流库的经验。文章对比了形式化验证、确定性模拟和混沌测试，认为后两者在应对复杂依赖时更具实用性。 作者详细描述了如何通过随机注入故障来验证系统不变性，并分享了一个因数据库断连导致的罕见竞态条件 Bug 及其修复过程。
评论点赞收藏403 天前

为什么你应该用 Postgres 构建持久化工作流

DBOS 团队分享为何选择 PostgreSQL 作为持久化工作流的数据存储。文章重点分析了 Postgres 在并发控制、可观测性查询和事务一致性方面的技术优势。 作者通过分布式队列锁机制、SQL 索引优化和 Exactly-Once 语义实现细节，展示了如何利用 Postgres 特性解决工作流系统的扩展性与可靠性问题。
评论点赞收藏417 天前

如果持久化执行是一个更简单的架构决策

文章认为持久化执行应是软件默认选项，但传统方案如 AWS Step Functions 或 Temporal 需要重构架构且成本高昂。 作者介绍 DBOS 库可直接在代码中实现持久化，无需额外服务，旨在推广其开源产品。
评论点赞收藏435 天前

持久化工作流架构基准测试：Temporal 与 DBOS 对比

DBOS 发布了一篇对比博客，比较了使用外部编排系统 Temporal 和嵌入式库 DBOS 实现持久化工作流的架构差异。文章通过一个文档索引应用案例，指出 DBOS 仅需少量代码修改即可集成，而 Temporal 需要重构应用并增加服务依赖。 作者认为嵌入式方案更符合业务逻辑紧密耦合的特点，且减少了额外故障点。但这篇内容带有明显的 DBOS 推广性质，旨在突出其产品的易用性和架构优势，属于厂商视角的技术选型对比。
评论点赞收藏473 天前

利用分支处理工作流故障

文章提出工作流“Fork”机制，允许从特定步骤和代码版本重启流程，复用已计算结果以快速恢复故障。通过计费场景示例，展示了如何处理下游服务中断或代码Bug导致的批量失败，并简述了基于数据库Checkpoint的实现原理。 该方案旨在解决大规模工作流运维中的痛点，强调恢复过程需具备上下文感知能力。虽然提供了具体的实现思路，但主要服务于DBOS框架用户，通用性讨论价值中等。
评论点赞收藏487 天前

为什么你的工作流应该变成 Postgres 数据行

文章提出将工作流状态直接存储在 Postgres 数据库中，通过 SQL 查询即可管理业务流程。 作者认为这种方式比传统日志监控更直观，能简化复杂故障下的恢复与排查过程。
评论点赞收藏517 天前

登录芦苇

登录后关注作者、收藏内容和参与讨论。

热门话题

人工智能12,865 人关注AI 会怎样改变日常工作？产品思考8,243 人关注怎样判断一个产品值得长期做？独立开发5,917 人关注一个人如何持续完成作品？
关于芦苇 · 联系我们 · © 2026 芦苇