由 John Doe 十一月 2, 2026
现在的问题已经不再是代码好坏，而是一套有 35 年历史的架构遇上了 2026 年的世界。
目录
作者：Oz
如果你关注我的写作已有一段时间，你会知道我一直是 PostgreSQL 的狂热粉丝。我曾称它是你永远需要的最后一个数据库。但最近，有些事情发生了变化。
上个月，我在做一个本应很简单的项目。我们并没有做什么疯狂的事，只是一个带有一些 AI 功能的高流量应用。但十年来第一次，Postgres 让我觉得有点沉重。
我开始深挖原因，然后意识到我们已经到了一个临界点。我们正试图让一件 80 年代的杰作来支撑 2026 年的世界。以下是关于为什么“Postgres 优先”的思维模式开始出现裂痕的诚实真相。
功能蔓延问题
Postgres 是终极的瑞士军刀。需要存储 JSON？用 JSONB。需要找最近的咖啡店？用 PostGIS。需要存储 AI 嵌入向量？用 pgvector。
但他们没有告诉你的是：你能在 Postgres 里做某事，并不意味着你应该这么做。当我们把向量搜索推上生产环境时，我们意识到，随着表不断增长，管理关系型 ACID 属性以及高维数学计算带来的开销开始拖垮性能。我们是在要求一位马拉松选手表演芭蕾。它能行，但一个专用的向量数据库（比如 Pinecone）会让这件事看起来像小儿科。
扩展性仍然是房间里的大象
大家都说 Postgres 能扩展。它确实能垂直扩展。你买一台更大的服务器。你加更多内存。
但我们生活在一个水平扩展的时代。当我们的项目遇到流量尖峰时，我们意识到，用 Postgres 管理跨多个区域的写密集型工作负载，就像在拥堵的车流里开手动挡汽车。太累了。
像 CockroachDB 或 TiDB 这样的新玩家已经在架构层面解决了这个问题。它们没有主节点瓶颈。在 2026 年，如果你的数据库不能像你的前端一样轻松扩展，你就是在亏钱。
隐藏的工程税
Postgres 是开源且免费的，但隐藏成本是真实存在的。我说的是工程税。
- 连接池：为什么我只是为了处理几千个 serverless 连接，仍然需要 pgbouncer？
- Vacuum：看着 CPU 飙升，因为 autovacuum 决定该清理死行了，这是每个开发者其实都不享受的成人礼。
- 迁移：在巨大的表上做 schema 变更，仍然感觉像是在病人跑马拉松时给他做开胸手术。
残酷的真相
Postgres 要死了吗？绝对没有。它可能会比我们所有人都活得久。它可靠、久经战斗考验，而且对 80% 的项目来说，它仍然是正确选择。
但我们需要停止把它当作银弹。
科技世界正在走向专业化。我们正在走向 serverless 优先和 AI 原生的数据层。如果你在为下一个十年构建东西，不要只是因为 Postgres 是你熟悉的，就选择它。选择它，是因为它确实是这项工作的最佳工具。
而且越来越多时候我发现，对于最有雄心的项目来说，最佳工具已经不再是我们从小用到大的那个了。