Postgres LISTEN/NOTIFY 其实能扩展
Postgres LISTEN/NOTIFY actually scales
很多人认为 Postgres 的 LISTEN/NOTIFY 功能只适合小规模应用，无法应对高并发场景。但 DBOS 团队的最新测试表明，只要配置得当，这套机制完全能够支撑大规模生产环境。文章通过实际数据展示了其在高负载下的表现，打破了传统认知。如果你正在寻找轻量级、无需额外中间件的实时通知方案，Postgres 自带的 LISTEN/NOTIFY 或许比你想象的更强大。
Postgres 的 LISTEN/NOTIFY 功能其实具备出色的扩展能力，足以支撑大规模生产场景。
HN 评论区
77- jerf
"扩展性"（Scale）不是非黑即白的二元概念，而是一个连续谱。"能扩展到 60K/s"对某个系统来说可能多出了 5 个数量级，对另一个系统来说却又少了 5 个数量级。就我个人而言，我会把通用的"过早优化"从"最常见的开发者错误"列表中划掉，取而代之的是"使用了扩展因子不匹配的技术"。如果你用的东西太小而超出了其承载能力，失败是显而易见的；但反过来同样是个问题。对于一个本可以用更丰富的模型（其丰富性虽限制了扩展性，但能节省大量精力）来更好处理的系统，却引入了超可扩展技术带来的开销、管理问题及其为了扩展而施加的限制，这同样是个糟糕的选择。
LISTEN/NOTIFY 的上限确实很小，需要引起注意，我个人倾向于在考虑到最悲观的负载数据后，至少还要留出 1 个数量级的余量。但这对于许多项目来说已经绰绰有余了。考虑到它与数据库其余部分的集成度、高可用性，以及它不需要你额外运维另一个服务，这绝对不应该被简单地视为一个不可行的选项而直接否决。甚至他们引用的原始 2K/s 这个数字，对于那些更应以"秒/条消息"来衡量的系统来说，消息量也已经非常庞大了。
- nzoschke
我继续为 DBOS 点赞，因为它能恰当地利用 Postgres（现在还有 SQLite）。将其集成到现有的 CRUD 架构中毫不费力。
一旦你踏上"持久化工作流"（durable workflows）这条路，你会发现它们无处不在。
我最新的实验是将单封邮件视为持久化工作流，其中你、你沟通的对象、智能体以及 GitHub 或 Attio 等工具都在流程中轮流参与。
https://housecat.com/blog/gmail-durable-workflows-sandbox-vm
- elendilm
测试用的机器看起来很大，拥有 96 个 vCPU 和 384GB 内存，但仅产生 20k 的写入量听起来太低了。跳到 60k 确实很好，但对于这台机器的能力来说，吞吐量仍然太小。
批处理（Batching）能确保你在 CPU 和内存速度下运行，只为刷新（flush）支付显著的延迟——如果并发执行，Linux 内核通常能很好地合并这些操作。
- dang
相关主题，推测如下：
Postgres LISTEN/NOTIFY 无法扩展 - https://news.ycombinator.com/item?id=44490510 - 2025 年 7 月（321 条评论）
- sandeepkd
我认为这类帖子大多是对个人问题、理解和解决方案的独立评估。如果一个人试图使用工具的默认设置并期望获得特定性能，就将其称为"缺乏专业知识"是存疑的。每个人都在通过失败进行持续学习。
1. 我觉得有趣的是，该实验似乎使用了一台拥有 96 核、384GB 内存的数据库服务器（https://github.com/dbos-inc/dbos-postgres-benchmark/blob/mai...）。这是任何此类实验的关键部分，本应明确指出。数据库是垂直扩展的，且其本身也有极限。
2. 谁在建立连接，以及连接来自何处，对性能和整体延迟也有影响。
3. 60k 看起来是个大数字，但在现实世界中，导致系统崩溃的往往是突发流量，而非常规流量。
除非我是大公司，否则我个人绝不会一开始就使用这么大的服务器。如果包含只读副本和跨区域冗余，一个生产级数据库集群的成本将超过 10 万美元。