事情始于一个要点和一个热烈的Hacker News讨论。前提很简单：Postgres并不是在所有方面都是最好的，但对于大多数事情来说，它足够好。在实践中，大多数团队正在运行过多的微服务和数据库。这一切都是过早的优化。更多的运营开销，更多的维护负担，更多的监控复杂性，更高的成本，更难的追踪和更长的调试时间。典型模式你需要缓存，于是你添加了Redis。全文搜索？附加Elasticsearch。后台工作？另一个Redis，或者可能是Sidekiq。具有灵活模式的文档？默认使用MongoDB。分析？Snowflake。事件？扳手Kafka。不久，你的“简单”应用程序就与七个不同的数据存储和微服务进行了交互，每个系统都有其自己的部署、备份策略、故障模式以及当它们彼此停止通信时的凌晨3点页面。每个系统都增加了运营表面：监控、警报、故障转移测试、安全修补、版本升级。“Web规模™”堆栈应用程序Redis Postgres Elastic MongoDB Snowflake Kafka Pinecone Sidekiq InfluxDB 多个系统进行操作和监控 与Postgres应用程序PostgreSQL 同一个数据库。一个备份策略。一组故障模式。“但是Postgres并不是Web规模™！”我们总是听到这个论点。但是，实际达到所谓“网络规模”的软件项目的百分比是多少？大约0.3%？对于你的隐秘初创公司或SaaS，你真的应该将创新代币花费在多个微服务和数据库上，而不是实际面临的问题上吗？如果像Notion、Netflix、Instagram等公司能够信任“无聊”的技术，你的初创公司大概可以在没有七个数据库架构的情况下生存。此外，如果你真的达到了网络规模并耗尽了Postgres的能力，你可以在真正需要时带来额外的组件。也许Postgres就足够了 在寻找另一个数据库之前，看看能否用Postgres已经提供的解决方案来完成：你需要... 你寻求... 但Postgres有... 缓存 Redis，Memcached UNLOGGED表，物化视图→工作队列 Redis + Sidekiq，RabbitMQ SKIP LOCKED，pgmq，pgflow→全文搜索 Elasticsearch，Algolia tsvector，pg_trgm，ParadeDB→文档存储 MongoDB，CouchDB JSONB，FerretDB→向量搜索/人工智能 Pinecone，Weaviate pgvector，pgvectorscale→时间序列数据 InfluxDB，TimescaleDB TimescaleDB，pg_partman→分析/OLAP Snowflake，BigQuery pg_analytics，DuckDB集成→图形数据库 Neo4j，Neptune Apache AGE，递归CTEs→地理空间 专业GIS系统 PostGIS→当你真正需要其他东西时，这并不是关于教条。有时你确实需要专业基础设施。但标准应该很高：只有在将Postgres推到极限、记录下为何它不足并接受替代方案的运营成本后。 在那之前，你添加的每个系统都是一个赌注，看这个好处是否能够超越多年的维护、监控和调试。