为什么需要
做出海 SaaS 需要后台任务队列：发送邮件、跑 AI Agent、处理 webhook、定时清理数据库。AWS SQS 好用但要钱还绑云，Redis + BullMQ 又要维护另一套服务。PGMQ 把消息队列做进 Postgres——单 SQL 扩展安装，0 额外中间件，事务性和现有业务数据保持一致。
怎么用
sql
-- 1. 安装扩展（一次）
CREATE EXTENSION pgmq;
-- 2. 创建队列
SELECT pgmq.create('email_jobs');
-- 3. 入队
SELECT pgmq.send('email_jobs', jsonb_build_object(
'to', 'user@example.com',
'template', 'welcome'
));
-- 4. 出队（带可见性超时）
SELECT * FROM pgmq.read('email_jobs', 30, 5);
-- 读最多 5 条消息，30 秒内其他 worker 看不到
-- 5. 完成后删除
SELECT pgmq.delete('email_jobs', msg_id);
Python / Node / Go SDK 全都有：
python
from pgmq import PGMQueue
q = PGMQueue(conn)
q.send("email_jobs", {"to": "a@b.com"})
核心能力
- 事务性 — 入队 / 出队可以和外层事务一起 commit / rollback
- 可见性超时 — 消息被一个 worker 取出后，N 秒内其他 worker 看不到
- 延迟队列 —
send_at参数指定未来某个时间投递 - 死信队列 — 失败 N 次的消息自动转死信队列
- 跨实例 — 多个 worker 进程 / 机器同时消费同一队列
- FIFO + 优先级 — 同一队列内保证顺序，可配置优先级
使用案例
出海独立开发者做 SaaS 后台，原本用 Redis + BullMQ 跑任务队列。多了一台 Redis 服务要备份、要监控、要做高可用——一个 1 人团队维护不动。换成 PGMQ 后，任务表直接存在业务 Postgres 库里：
sql
-- 失败任务查询（Redis 需要单独排查日志）
SELECT * FROM pgmq."email_jobs" WHERE status = 'failed';
整套基础设施从「Postgres + Redis」简化到「只有 Postgres」，运维复杂度降一半。
实际性能
- 处理 webhook：每分钟 500 条 Stripe 事件，3 个 worker 进程，CPU 用满率 < 30%
- 异步邮件：日均 2 万封，PGMQ 队列深度稳定在 0-5
- 跨实例：两个 AWS EC2 节点同时消费，零重复投递
注意事项
- 完全免费开源（PostgreSQL License）
- 需要 Postgres 14+，最好 16
- 不是 Redis 替代品，延迟敏感 / 高吞吐（>1 万 msg/s）场景还是 Redis Streams 更合适
- 队列消息默认 JSONB，1MB 以下都可以