由 John Doe 七月 13, 2026
既然已经用上了 Postgres，你真的有必要为缓存、消息队列、全文搜索、文档存储、向量嵌入分别搭建独立的系统吗？
目录
来龙去脉
这一切始于一则 Gist 短文与 Hacker News 上的热烈讨论。核心逻辑很简单：Postgres 不是样样都做到顶尖，但应对绝大多数场景都绰绰有余。现实中，大多数团队都堆砌了过多的微服务与数据库，本质上全是过早优化。最终换来的只有更高的运维开销、更重的维护负担、更复杂的监控体系、更高的成本、更难的链路追踪，以及更漫长的故障排查过程。
典型的技术栈膨胀路径
需要缓存？加一套 Redis。全文搜索？硬接 Elasticsearch。后台任务？再搭一套 Redis，或者上 Sidekiq。存灵活结构的文档？默认选 MongoDB。数据分析？上 Snowflake。事件流处理？安排 Kafka。
用不了多久，你那 “简简单单” 的应用就要对接七八个不同的数据存储与微服务 —— 每个都有独立的部署方式、备份策略、故障模式，凌晨三点还会因为它们之间连通中断而收到运维告警。每多一个系统，就拓宽一分运维边界：监控、告警、故障切换演练、安全补丁、版本升级，样样都要专人跟进。
“可 Postgres 撑不起 Web 级规模啊！”
这种论调我们听过无数次。但真正能触达所谓 Web 级规模 的软件项目，实际占比能有多少？大概也就 0.3% 吧。对于还在保密阶段的初创团队或是 SaaS 产品而言，你真的要把宝贵的创新筹码浪费在搭建一整套微服务与多数据库架构上，而不是聚焦解决核心业务问题吗？
像 Notion、Netflix、Instagram 这类服务千万级用户的公司，都愿意信赖这种 “乏味” 的成熟技术，你的创业公司没理由非要靠七数据库架构才能运转。更何况，等你真的做到了 Web 级规模、把 Postgres 的能力彻底用尽时，再按需引入额外组件也完全来得及 —— 那才是真正的刚需。
或许 Postgres 就足够了
在急着引入新数据库之前，先看看 Postgres 自带的能力能不能满足需求：
| 你的需求 | 你第一时间想到的方案 | 但 Postgres 已有对应能力 |
|---|---|---|
| 缓存 | Redis、Memcached | UNLOGGED 表、物化视图 |
| 任务队列 | Redis + Sidekiq、RabbitMQ | SKIP LOCKED、pgmq、pgflow |
| 全文搜索 | Elasticsearch、Algolia | tsvector、pg_trgm、ParadeDB |
| 文档存储 | MongoDB、CouchDB | JSONB、FerretDB |
| 向量搜索 / AI 场景 | Pinecone、Weaviate | pgvector、pgvectorscale |
| 时序数据 | InfluxDB、TimescaleDB | TimescaleDB、pg_partman |
| 数据分析 / OLAP | Snowflake、BigQuery | pg_analytics、DuckDB 集成 |
| 图数据库 | Neo4j、Neptune | Apache AGE、递归 CTE、SQL/PGQ |
| 地理空间数据 | 专业 GIS 系统 | PostGIS |
什么时候你确实需要额外的系统
这绝非教条主义。有些场景下，你确实需要专用的基础设施。但引入的门槛应当设得足够高：必须是在把 Postgres 的能力压榨到极限、有明确记录证明它确实无法满足需求，并且你也充分接受替代方案带来的运维成本之后，再做选择。
在那之前，你每新增一个系统，都是一场赌注 —— 赌它带来的收益，能抵得上未来数年的维护、监控与排障成本。