PostgreSQL 一个打十个：从搜索、队列到向量库，砍掉半个中间件栈

2024 年 2 月，柏林的 interim CTO Raphael Bauer 在个人博客发了《PostgreSQL for Everything》，中心思想一句话：架构图里那些搜索、文档库、消息队列、时序库、向量库、缓存，大部分都可以砍掉，留一个 PostgreSQL 就够了。

写这篇稿子的时候（2026 年 8 月 20 日），这篇文章又登上了 Hacker News 首页：315 分、195 条讨论。两年半过去，一篇选型文还能吵成这样，说明大家确实有这个痛点：中间件越加越多，迭代越来越慢。

同一份业务，两套架构

回头再看，这篇文章的判断算是被生态用真金白银验证了：Databricks 花 10 亿美元收购了 Neon，Snowflake 收购了 Crunchy Data，Supabase 的估值两年内从 20 亿美元涨到约 100 亿，Stack Overflow 调查里 PostgreSQL 的使用率到了 58.2%。

下面按原文的顺序过一遍这些主张，看看哪些站住了、哪些不能照抄，最后给一份决策矩阵。原文和主要资料在文末参考链接。

复杂度是速度的敌人

Bauer 的论点说到底是个运维常识：每引入一个独立系统，就多一份部署、监控、升级、容灾、备份和值班。对绝大多数团队，多养一个系统的真实成本，远大于它在跑分上的优势。至于单点性能，PG 往往并不是最快的，但这从来都不是重点。

还有一类隐性成本更容易被忽略：数据同步。应用库和搜索集群之间要双写、要对账；业务库和消息队列之间，永远有「写库成功、消息发丢」的裂缝要打补丁。这些胶水代码不会出现在架构图上，但它们贡献了大部分凌晨三点的告警。

砍掉中间件之后，这类麻烦直接消失：数据只有一份，事务天生一致。原文里有句话很朴素，值得一记：

You need simplicity if you want to move fast.（想快，先把事情变简单。）

能力地图

把原文的十个替代主张压成一张表：

全文搜索

原文最推的案例是 Contentful：这家 headless CMS 直接用 PostgreSQL 给用户做全文搜索。Instacart 也走了同一条路，把搜索基础设施建在 Postgres 上，没有养独立的搜索集群。

PG 这边的机制是 tsvector 加 GIN 索引，模糊和相似度搜索交给 pg_trgm 扩展。省事的点在架构：数据天然同步，不会出现「商品已下架、搜索结果还在卖」的尴尬。

中文场景有个额外的注意点：PG 的默认解析器不做中文分词，要先加 zhparser 或 pg_jieba 扩展，否则搜索效果没法看。

边界也清楚：亿级文档、精细的相关性调优、召回实验体系，Elastic 仍然更合适。Contentful 做的是站内搜索，真要做搜索引擎，那就是另一回事了。

文档存储：jsonb

jsonb 让 PG 能存也能查 JSON，GIN 索引可以加速字段内部的查询。经典案例是《卫报》：2018 年他们把 25 年积累的内容数据从 MongoDB 迁到 PostgreSQL on RDS，还写了公开复盘。

这两年多了个背景值得留意：开源数据库的许可证反复摇摆——MongoDB 2018 年改 SSPL，Redis 2024 年换协议逼出了 Valkey 分叉。对比之下，PostgreSQL 那份类 BSD 的许可证三十年没动过。做选型的时候，「这家会不会哪天改协议」本身就要算进风险。

如果写入量需要水平分片扩展，文档数据库的分片方案依然更成熟。

队列：SKIP LOCKED

这是原文里技术含量最高的部分。PG 的行锁语法里藏着一个现成的队列原语：

1
2
3
4
5

SELECT * FROM jobs
WHERE status = 'pending'
ORDER BY created_at
FOR UPDATE SKIP LOCKED
LIMIT 1;

SKIP LOCKED 的语义：已经被别的消费者锁住的行直接跳过。多个 worker 并发抢单，互不阻塞、互不重复。更实际的好处是任务表和业务表在同一个库里，「扣库存」和「记任务」在同一个事务里提交，分布式事务的问题压根不存在。

生态这两年也跟上了：Tembo 开源的 PGMQ 在 PG 上包了一层 SQS 语义（可见性超时、消息归档、FIFO），Supabase 直接把它做成了内置扩展。今天 HN 评论区的高赞补充提到，Revolut 这家英国金融科技独角兽把全部事件持久化和流处理跑在 Postgres 上，没有用传统消息代理。

Bauer 的建议很实在：先用 PG 做队列，真撑不住了再换 Kafka 或 SQS，你会惊讶它能撑多久。反过来说，百万级 msg/s、长时间回溯重放、多消费者组，这些 Kafka 的主场就别让 PG 硬扛了。

时序与向量

时序方面，作者自己就拿 TimescaleDB 扛着高流量的 Web 分析产品，原生的 BRIN 索引加分区也能应付多数时序场景。

变化最大的是向量。原文写作时 pgvector 还是 Timescale 生态里的一个扩展，现在它已经是 AI 应用事实上的默认向量库。资本的动作最能说明问题：Databricks 2025 年 5 月以约 10 亿美元收购 Neon，披露时提到平台上 80% 的数据库由 AI agent 创建；Snowflake 随后以约 2.5 亿美元买下 Crunchy Data；Supabase 的估值两年从 20 亿涨到约 100 亿。PG 引擎本身也在变强：2025 年 9 月发布的 PostgreSQL 18 引入异步 I/O，读密集负载的吞吐最高翻倍。

缓存、文件、图数据库

缓存这节的关键是语义：缓存本来就可以丢了重建，而 UNLOGGED 表（不写 WAL 日志）恰好就是这个语义，TTL 过期用触发器模拟即可。会话、低频热点数据够用；亚毫秒延迟、几十万 QPS 的纯内存场景，Redis/Valkey 该用还得用。

文件系统是原文里最反直觉的案例：一个客户项目要高频读写海量二进制小对象，实测 PG 比直接读写文件系统还快。PG 自己的缓存和 I/O 调度，比随手写的文件读写高效，数据用 Flatbuffers 序列化后存进 bytea 列。当然，海量文件的归宿依然是 S3/R2 这类对象存储。

层级数据用 ltree 类型，比递归 CTE 可读得多；要跑图查询还有 Apache AGE 扩展。原文在这几项上的态度也是「能，但酌情」。

中间层也能省

原文的半开玩笑之作：很多「微服务」干的事，就是从数据库取数、拼成 JSON 返回，而 PG 的 row_to_json 能让 SQL 直接吐 JSON，中间层薄到只剩鉴权和权限。这话和这两年 modular monolith 的回潮是同一个方向：拆分应该被规模逼出来，别写在第一天的架构图里。

两年半的成绩单

原文发表后的两年半

边界

这篇原文最值得学的其实是姿态：一边列「PG 替代一切」，一边毫不吝啬地夸 ClickHouse amazing。诚实的边界大概有五条：

1. 写入水平扩展。PG 是单机写加异步复制，写吞吐到顶之后的路（分库分表、Citus）都不轻松，天生多写的业务一开始就要想清楚。
2. 海量分析。列存碾压行存是物理规律，大宽表的实时聚合、PB 级分析，ClickHouse / DuckDB 快出一个量级。
3. 亚毫秒缓存。极高 QPS 的纯内存加丰富数据结构，Redis/Valkey 还是正解。
4. 高吞吐流处理。百万级 msg/s、按时间回溯重放、多消费者组，是 Kafka 的主场。
5. 组织因素。团队会不会、运维扛不扛得住、已有投资沉没多少，这些和技术同样真实。

原文结尾那句话的分寸拿捏得很好：PostgreSQL might not be the answer to everything - but it is the answer to a lot more than you might think!（PostgreSQL 也许无法回答一切，但它能回答的，比你以为的多得多。）

决策矩阵

落到实操就一条：把「PG 先行」当默认规则。新需求来了先问 PG 能不能干，答案经常是可以；真被瓶颈顶住了再换专用系统，而且那时候你对瓶颈的理解会准确得多。每一个专用系统都应该被真实的需要逼出来，而不是被简历驱动加进来。

延伸阅读：建设期的 schema 设计、索引与查询优化，看《创业公司的 Postgres 生存指南》；线上诊断连接池、膨胀、锁等待，看《Postgres 生产运维实战》。

参考链接

• PostgreSQL for Everything — Raphael Bauer（2024-02，原文）
• 今日 HN 讨论（315 分 / 195 评论）
• Stack Overflow 2025 开发者调查
• Databricks 收购 Neon 公告
• Contentful：用 PG 做全文搜索
• The Guardian：Bye bye Mongo, Hello Postgres
• PGMQ：跑在 Postgres 上的消息队列