"PostgreSQL 能替代 Kafka、Elasticsearch、Redis、MongoDB、Clickhouse……"这个说法每隔一阵就会在社区引发激辩。今天 Raphael Bauer 的一篇《PostgreSQL for Everything》又把它炸了出来。

Bauer 的论点很直接：PG 的生态扩展已经覆盖了绝大部分专用数据系统的功能——全文搜索替代 Solr/ES，JSONB 替代 MongoDB，SKIP LOCKED 做消息队列替代 Kafka，TimescaleDB 做时序替代 Clickhouse，pgvector 做向量库，UNLOGGED 表做缓存替代 Redis。他的核心主张是"用 PG 统一你的 IT 基础设施，大幅降低复杂度"。

这个论点的诱惑力是显而易见的。谁不想少维护几套系统？有评论提到了 Revolut 的案例——这家银行的所有事件持久化和流处理都在 PostgreSQL 上完成，没有引入任何传统消息队列或消息代理。

但反对的声音同样激烈。一位 SRE 的评论代表了实用主义者的立场："作为 SRE，用 Kafka 这样的成熟软件的好处是，你遇到的绝大多数问题都有人遇到过、有解决方案。而自己用 PG 探索解决方案，到头来往往发现'Kafka 早就把这搞定了'。"

另一个持反对意见的评论者点出了 PG 统一栈的潜在风险："如果不深度思考你的 schema 和未来演化方向，用 PG 做一切很容易把自己逼到一个昂贵且难以脱身的角落。" 在 2026 年的今天，各种专业化、易扩展、成熟的替代方案并不稀缺——盲目追求"一个数据库管所有"可能适得其反。

也有中间立场："你可以在 PG 里搞定 80-95% 的需求，剩下那些真正需要专用系统的大不了再引入。" 这个观点在 Hack News 上获得了最多隐性认同——没人觉得 PG 不行，但也没人觉得"全栈 PG"是银弹。

有个评论者用自己的亲身经历说了句大实话："我们把 PG 的消息队列迁移到了 RabbitMQ，以为能解决压力问题。结果不仅没解决，还引入了一大堆新问题——因为用 PG 做队列实在太直观了，重试、死信、重处理全凭一个 SQL 接口就能搞定。"

这场争论每隔一阵就会翻新，但底层的张力一直没变：PG 的扩展性在增长，你的业务复杂度也在增长。选"PG 搞定一切"还是"最合适的工具做最合适的事"？可能没有标准答案——只有你的业务规模到了哪一步。

参考来源：

• PostgreSQL for Everything
• HN 讨论帖