一个SQL文件搞定消息队列，PgQue让Postgres自己跑起来

你有没有算过，为了跑一个消息队列，你的系统里多了多少台机器？

Redis、RabbitMQ、Kafka——随便选一个，都是新的进程、新的网络层、新的监控面板。而你的数据明明就在Postgres里，却要绕一大圈才能"排队"。

GitHub上有个新项目叫PgQue，238个星标，2个分支，看起来不起眼。但它干了一件很轴的事：把Skype用了十几年的队列架构，塞进了一个SQL文件。

纯PL/pgSQL（PostgreSQL的过程语言），没C扩展，没守护进程，RDS、Aurora、Supabase随便跑。这到底是技术复古，还是另一种先进？

一图读懂：PgQue的核心设计

先上一张图，看懂它的骨架：

【核心循环：快照批处理 + 表轮转】

这张图里有三个关键设计，我们逐层拆。

第一层：为什么"零膨胀"是硬需求

Postgres队列有个老毛病，业内叫"膨胀（bloat）"。

普通做法是用SKIP LOCKED抢行，然后DELETE或UPDATE标记已消费。听起来合理，但Postgres的MVCC机制会让这些操作留下死元组（dead tuples）。

死元堆多了，VACUUM跟不上，索引膨胀，性能漂移。玩具demo跑得欢，生产环境跑三个月，延迟从毫秒变秒级。

PgQue的解法很粗暴：不删行，直接换表。

它用两张表轮着来，一张写、一张读。读完了？TRUNCATE清空，瞬间归零，不留给死元组任何生存空间。热路径（hot path）永远 predictable，没有渐进式性能衰减。

这是Skype在亿级用户场景下验证过的模式。PgQue只是把它从C扩展+守护进程，翻译成了纯SQL。

第二层：快照批处理 vs 逐行争抢

传统队列是"抢单模式"：消费者来了，抢一行，处理，确认，下一行。并发一高，锁竞争、连接数、网络往返全是开销。

PgQue玩的是"批处理模式"：

消费者用一个快照（snapshot）批量拉取一批事件，本地处理，批量确认。ACID语义全在Postgres事务里完成，没有外部状态机。

代价是端到端延迟。默认配置下，发送方到消费方的延迟大概在1秒左右——不是毫秒级，但对大多数业务场景够用。

这是典型的工程权衡：用可接受的延迟，换架构简洁性和零运维负担。

第三层：安装即运行，托管数据库友好

这是PgQue最反直觉的地方。它自称"反扩展（anti-extension）"：

—— 不需要shared_preload_libraries

—— 不需要提供商批准安装C扩展

—— 不需要重启数据库

一个SQL文件，psql执行完就能用。pg_cron负责定时触发轮转，而pg_cron在RDS、Aurora、Cloud SQL、AlloyDB、Supabase、Neon上都是开箱即用的。

这意味着什么？你的队列和主数据在同一个事务边界内。发消息和业务写库原子提交，丢消息的概率降到理论最低。

没有网络分区，没有"最终一致性"的玄学，没有凌晨三点调试Kafka消费者组的噩梦。

谁该认真看看这个项目

三类人：

第一，托管Postgres用户。你想用队列，但提供商不让装C扩展，PgQue是目前最干净的解法。

第二，厌恶分布式系统的团队。每加一个中间件，故障域就扩大一圈。PgQue把复杂度压回数据库层，符合"能少一个进程就少一个"的洁癖。

第三，延迟敏感但非实时敏感的异步任务。邮件通知、报表生成、数据同步——1秒延迟换零运维，这笔账多数团队算得过来。

当然，它不是万能的。如果你要亚毫秒级延迟、每秒百万级吞吐、或者跨地域多活，PgQue的设计目标就不是为你写的。回去用Kafka。

项目现状与风险提示

GitHub显示108次提交，238星标，2个fork。作者Nikolay Samokhvalov是Postgres资深贡献者，但项目明确标注：

「Project status: Experimental」

实验性意味着API可能变，生产环境请自行评估。不过核心机制——快照批处理+表轮转——是经过Skype十年生产验证的，风险主要在实现成熟度，不在设计本身。

客户端库目前有Python、Go、TypeScript的社区实现，CLI工具链也在完善中。

benchmarks目录里有性能测试脚本，可以对着自己的Postgres版本跑一遍，看膨胀控制和延迟是否符合预期。

一个值得玩味的趋势

PgQue的出现，其实是"Postgres万能化"浪潮的一朵浪花。

向量扩展（pgvector）让它抢了Elasticsearch的饭碗，pg_cron+PL/pgSQL让它能替代定时任务系统，现在队列也要收编进来。

这不是说专用中间件会消失，而是"默认Postgres"的决策门槛在降低。对于资源有限、团队精悍的创业公司，少一个需要深度调优的组件，就多一分活下去的概率。

技术选型从来不是选最强的，而是选"足够强且我能hold住"的。PgQue的赌注是：对大多数团队来说，"零膨胀的Postgres原生队列"已经足够强。