一份叫“PostgreSQL is Enough”的公开清单，最近在开发者圈里被反复提到。

它做的事很简单：把 PostgreSQL 生态里的扩展和工具按场景摆出来。队列、全文搜索、向量搜索、GIS、时序数据、NoSQL/JSON、GraphQL/API、CDC、缓存、迁移、性能调优、扩展管理，都能在这张清单里找到对应工具。

有意思的地方不在“Postgres 什么都能做”。这个说法太满，也不准确。

更值得讨论的是另一个问题：一个后端团队在搭新系统时，是否还需要一上来就把 Kafka、Elasticsearch、MongoDB、Redis、ClickHouse 全摆进架构图？

我的判断是，对很多中小型到相当规模的应用，默认先用 Postgres，已经比过去更合理。不是因为专用系统不重要，而是因为过早拆系统，常常先带来运维成本和数据同步成本。

Postgres 正在从数据库变成应用底座

这份清单不是 PostgreSQL 官方路线图，也不是基准测试报告。它更像一张选型地图。

它把很多原本分散在不同系统里的能力，重新拉回到 Postgres 周围：PostGIS 做地理空间，pgvector 做向量检索，TimescaleDB 做时序，PostgREST、Hasura、pg_graphql 做 API，Debezium 做 CDC，pg_cron、pgmq 做任务和队列，pgBouncer、HypoPG、pgxman 处理连接、调优和扩展管理。

这些名字本身不等于生产成熟度。GitHub Star、Fork 数，也不能直接证明一个项目适合关键业务。

但它们合在一起，至少说明一件事：Postgres 已经不只是“存关系表”的数据库。它正在变成很多应用默认的数据基础设施底座。

这对后端工程师的影响很直接。以前做一个功能，可能要先问“要不要接 Redis、要不要建 ES、要不要上消息队列”。现在可以先问一句：Postgres 现有能力够不够？

对创业团队 CTO 来说，动作更具体：采购和引入新系统可以延后。先把核心数据、权限、备份、迁移、监控压在一套主数据库体系里，等瓶颈出现，再拆出去。

这不是保守。是把复杂度花在该花的地方。

哪些能力适合收敛，哪些不该硬塞

Postgres 路线的好处，主要不在“功能更多”。真正的收益是少系统、少同步、少故障面。

一个订单状态如果要同步到搜索、缓存、消息队列和数仓，每多一条链路，就多一份延迟、重试、权限、回放和一致性问题。架构图看起来漂亮，值班时未必漂亮。

更现实的选型，可以按下面这张表看：

场景Postgres 生态可用能力适合先放进 Postgres 的情况需要谨慎拆出去的信号
队列与后台任务pgmq、pg_cron、pg_timetable、LISTEN/NOTIFY任务量可控，业务需要和数据库事务靠得很近高吞吐事件流、复杂回放、跨系统流处理
全文/向量搜索内置全文搜索、pgvector、ParadeDB 等站内搜索、RAG 初期检索、结果规模有限搜索相关性复杂、索引规模大、查询模式变化快
GIS 与时序PostGIS、TimescaleDB位置服务、轨迹、监控指标、业务时序数据专业 OLAP、海量聚合、冷热分层要求高
NoSQL/JSONJSONB、索引、约束半结构化字段、配置、事件载荷文档模型高度动态，读写模式更像专用文档库
API 与 GraphQLPostgREST、Hasura、pg_graphql快速生成内部 API，减少胶水代码权限模型复杂，审计和隔离要求高
CDC 与同步逻辑复制、Debezium需要把变更同步到下游系统回放语义、顺序保证、跨区域一致性要求高
缓存、迁移、调优、扩展管理pgBouncer、迁移工具、HypoPG、pgxman 等团队希望减少独立组件数量托管云不支持、版本不兼容、升级风险不可控

这张表的重点不是替代谁。

Kafka 仍然适合高吞吐事件流。Elasticsearch 仍然擅长复杂搜索。Redis 在低延迟缓存和特定数据结构上有优势。ClickHouse 这类列式系统在分析场景里很强。MongoDB 也有自己的文档模型和生态。

问题是，很多产品还没长到这些系统真正发挥优势的阶段，却已经提前付了全套成本。

所以，“Postgres is Enough”更像一句选型纪律：先证明 Postgres 不够，再引入新系统。

真正该看的，不是清单有多长，而是生产约束

这条路线最容易被误读成“一个数据库打天下”。我不太买账。

数据库能承担更多职责，不代表它应该承担所有职责。贪多求全，最后也可能把 Postgres 变成新的泥潭。

几个边界要提前写在架构文档里：极端吞吐日志管道、复杂流处理、专业 OLAP、跨区域强一致、强隔离多租户、毫秒级大规模缓存、复杂搜索相关性，这些场景仍可能需要专用系统。

还有一个更细但更要命的问题：扩展质量不一样。

有些扩展成熟、维护活跃、云厂商支持好。有些扩展可能版本跟不上，许可证不适合，备份恢复路径不清楚，或者托管数据库根本不给装。自建当然自由，但升级、安全、监控和事故恢复也会回到团队自己身上。

对负责选型的人，我会看四个条件：

要看的变量为什么重要更稳的动作
托管云支持决定能不能低成本进生产先查目标云厂商支持哪些扩展和版本
扩展维护状态决定升级和安全风险看发布频率、兼容版本、问题响应，不只看 Star
数据恢复路径决定出事能不能救回来在引入前做备份、恢复、回滚演练
拆分触发条件决定什么时候该上专用系统提前写清吞吐、延迟、查询复杂度和隔离要求

这也给后端工程师一个很具体的工作方式：不要为了“架构完整”先接一堆系统。先把 Postgres 能做的做好，把监控指标留足，把拆分点写清。

给 CTO 的判断也很简单：如果团队规模小、业务还在验证，先少买系统，往往比追求组件齐全更重要。等到吞吐、查询、隔离或分析需求真的压上来，再拆出去，成本反而更可控。

回到开头那份清单。它的价值不在于证明 PostgreSQL 能赢过所有专用系统，而是把一个老问题重新摆到桌面上：你到底是在解决业务瓶颈，还是在提前维护一张过度设计的架构图？