已有Postgres，还需要独立系统吗？

背景

这篇文章源自 Hacker News 上一条 gist 引发的热烈讨论，讨论的核心是一个看似简单的问题：当你已经拥有 Postgres 时，是否真的需要为缓存、队列、搜索、文档、向量嵌入等功能分别引入独立的系统？原始 gist 提出的前提是：Postgres 并非在每项任务上都是最佳选择，但它对大多数场景而言已经足够好。而现实中有太多团队过早地引入了过多的微服务和数据库，导致运维负担、维护成本、监控复杂度、排查难度都大幅增加。

核心内容

文章指出，在许多团队中会出现一个典型的模式：需要缓存 → 加 Redis；需要全文搜索 → 加 Elasticsearch；需要后台任务 → 再加一个 Redis 或 Sidekiq；需要 flexible schema 的文档存储 → 默认用 MongoDB；需要分析 → 上 Snowflake；需要处理事件 → 用 Kafka。很快，一个“简单”的应用就要与七八种不同的数据存储和微服务通信，每个系统都有自己独立的部署方式、备份策略、故障模式，以及半夜被叫醒处理它们之间通信中断的告警。每个新系统都增加了操作面：监控、告警、故障切换测试、安全补丁、版本升级。

相比之下，如果只用 Postgres：一个数据库、一套备份策略、一组故障模式。

文章反击了常见的“但 Postgres 不够 Webscale”的说法。它指出，真正能达到所谓“webscale”（互联网规模）的软件项目比例大概只有 0.3%。对于大多数初创公司或 SaaS 产品而言，是否应该把宝贵的创新点数（innovation tokens）消耗在多个微服务和数据库上，而不是解决手头的实际业务问题？如果像 Notion、Netflix、Instagram 这类服务数百万用户的公司都在使用“无聊”的技术，那么初创公司大概率也可以不用搞七数据库架构。而且，如果真的有一天达到了 webscale 并压榨干了 Postgres 的能力，那时再按需引入额外组件也完全来得及。

文章最后给出了一个原则：在伸手抓另一个数据库之前，先看看 Postgres 本身能否满足需求。例如：

• 缓存可以用 Postgres 的物化视图或 LISTEN/NOTIFY
• 队列可以用 pgq、SKIP LOCKED 或 pg_jobmon
• 全文搜索可以用内置的 tsvector
• 文档可以用 JSONB
• 向量嵌入可以用 pgvector 扩展
• 分析可以用并行查询、列存储扩展（如 cstore_fdw）或物化视图

当然，文章不是教条主义——有些场景确实需要专门的系统，但门槛应该很高：只有在你已经把 Postgres 推到极限、记录下它为什么不够用、并且愿意承担替代方案的运维成本之后，才应该引入新系统。在此之前，每增加一个系统就是一次赌博，赌它带来的好处能超过未来数年维护、监控和调试的代价。

关键要点

• 不要过早优化：许多团队在完全没有达到性能瓶颈之前，就预判 Postgres 不够用，从而引入多个专用系统，造成不必要的复杂度。
• Postgres 的通用性超出想象：借助扩展（如 pgvector、JSONB、tsvector）和特性（物化视图、LISTEN/NOTIFY、并行查询），Postgres 可以覆盖缓存、搜索、文档、向量、队列、分析等大多数常见需求。
• 每个新系统都有隐形成本：运维、备份、安全、监控、故障切换、版本升级——每增加一个数据存储，这些成本都会成倍上升。
• Webscale 是个伪命题：真正需要“webscale”规模的项目极少，绝大部分应用在 Postgres 的容量范围内。即使将来需要，也可以渐进式地引入专门系统。
• 证据驱动而非假设驱动：只有在用尽 Postgres 能力并明确记录其不足之后，才有理由引入替代方案；否则优先使用单一数据库。
• 知名大厂也在用“无聊”技术：Notion、Netflix、Instagram 等服务于数亿用户的公司选择了简单可靠的基础设施，说明复杂化并非成功的必要条件。

意义与影响

这篇文章在 Hacker News 上引发共鸣，反映了当前软件工程社区对微服务狂热和“数据库选型过度”的一种反思。它提醒团队，在架构设计上回归务实：与其为了追求理论上的“最佳工具”而建立七七八八的独立系统，不如先充分利用现有 Postgres 的能力，减少运维复杂度，将精力集中在实际业务逻辑上。这种理念有助于遏制“过早分布式”和“过度工程化”的趋势，推动更多团队采用“单体优先、逐步拆分”的演进式架构。同时，本文也为 Postgres 生态（如 pgvector 等扩展）的价值提供了有力佐证，鼓励开发者重新审视被低估的关系型数据库在现代应用中的潜力。尽管文章并非反对所有专门系统的使用，但它抬高了引入新数据库的决策门槛，促使团队更审慎地评估“是否真的需要”，从而降低长期维护成本与风险。