当你已经有了 Postgres，还需要单独的系统吗？

# Postgres 已经足够了 来源：https://postgresisenough.dev/ 这一切始于一个[Gist](https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f06dbb)和一条热闹的[Hacker News 讨论帖](https://news.ycombinator.com/item?id=39273954)。前提很简单：Postgres 并非一切领域的佼佼者，但对于大多数场景来说，它已经足够好了。实际上，大多数团队运行了过多的微服务和数据库。这都是过早优化。更多的运维开销、更高的维护负担、更复杂的监控、更高的成本、更难的跟踪，以及更长的调试时间。 ### 典型模式 你需要缓存，于是加了 Redis。全文搜索？加上 Elasticsearch。后台任务？又一个 Redis，或者 Sidekiq。灵活模式文档？默认为 MongoDB。分析？Snowflake。事件处理？上 Kafka。没过多久，你的“简单”应用就要跟七个不同的数据存储和微服务打交道，每个都有自己的部署方式、备份策略、故障模式，以及在它们之间停止通信时凌晨三点的告警。每个系统都增加了运维表面积：监控、告警、故障切换测试、安全补丁、版本升级。 ### “Webscale™” 架构 应用 Redis Postgres Elastic MongoDB Snowflake Kafka Pinecone Sidekiq InfluxDB 多个系统需要运维和监控 ### 使用 Postgres 应用 PostgreSQL 一个数据库。一套备份策略。一组故障模式。 ### “但 Postgres 不是 Webscale™ 的！” 我们经常听到这个论点。但真正能到达所谓“webscale”的软件项目占比有多少？大概 0.3%？对于你的隐形创业公司或 SaaS，你真的应该把[创新代币](https://mattrickard.com/innovation-tokens)浪费在多个微服务和数据库上，而不是专注于手头的实际问题吗？ 如果像 Notion、Netflix、Instagram 这样服务数百万用户的公司都信任“无聊”的技术，那么你的创业公司大概也可以在没有七数据库架构的情况下运作。此外，如果你真的达到了 webscale 并且用尽了 Postgres 的能力，你完全可以在真正需要的时候再引入额外的组件。 ### 也许 Postgres 已经足够 在引入另一个数据库之前，先看看 Postgres 已经提供了什么： 你需要…… | 你通常会用…… | 但 Postgres 有…… --- | --- | --- 缓存 | Redis, Memcached | UNLOGGED 表、物化视图 → (https://postgresisenough.dev/tools?category=caching) 任务队列 | Redis + Sidekiq, RabbitMQ | SKIP LOCKED, pgmq, pgflow → (https://postgresisenough.dev/tools?category=queues) 全文搜索 | Elasticsearch, Algolia | tsvector, pg_trgm, ParadeDB → (https://postgresisenough.dev/tools?category=search) 文档存储 | MongoDB, CouchDB | JSONB, FerretDB → (https://postgresisenough.dev/tools?category=documents) 向量搜索 / AI | Pinecone, Weaviate | pgvector, pgvectorscale → (https://postgresisenough.dev/tools?category=vectors) 时序数据 | InfluxDB, TimescaleDB | TimescaleDB, pg_partman → (https://postgresisenough.dev/tools?category=time-series) 分析 / OLAP | Snowflake, BigQuery | pg_analytics, DuckDB 集成 → (https://postgresisenough.dev/tools?category=analytics) 图数据库 | Neo4j, Neptune | Apache AGE, 递归 CTE → (https://postgresisenough.dev/tools?category=graphs) 地理空间 | 专门的 GIS 系统 | PostGIS → (https://postgresisenough.dev/tools?category=geo) ### 什么时候你真的需要别的选择 这并非教条。有时候你确实需要专门的架构。但这个门槛应该很高：只有在将 Postgres 推到极限、记录下它为何不够用、并且接受了替代方案运维成本之后，才应考虑。在那之前，你每增加一个系统，就是在赌它的收益能抵过多年来的维护、监控和调试成本。