这篇文章的核心观点是，PostgreSQL虽非全能，但足以满足大多数应用需求。许多团队过度使用微服务和多种数据库（如Redis、Elasticsearch等），导致运维复杂、成本高昂。文章主张简化架构，仅用PostgreSQL即可应对缓存、搜索、任务等常见场景。

文章核心观点：PostgreSQL 足够胜任大多数场景

文章源于一篇技术讨论，核心观点是：PostgreSQL 虽非全能，但对绝大多数项目而言已足够。现实中，许多团队过早引入过多微服务和数据库，导致运维负担加重、维护成本上升、监控复杂化、故障排查困难，这本质上是过度优化。

常见误区：为简单需求引入复杂架构

典型场景是：需要缓存就加Redis，全文搜索就上Elasticsearch，后台任务用Sidekiq，灵活文档存MongoDB，分析用Snowflake，事件流用Kafka。最终一个简单应用依赖七种数据存储和微服务，每种都有独立部署、备份策略、故障模式，运维面急剧扩大。

对比方案：多系统 vs 单一PostgreSQL

传统"Webscale™"架构需要Redis、Postgres、Elastic、MongoDB、Snowflake、Kafka等多个系统协同。而PostgreSQL方案只需一个数据库、一套备份策略、一组故障模式，大幅简化运维。

反驳"PostgreSQL不够Webscale™"论调

真正达到"Webscale"规模的项目不足0.3%。对于初创公司或SaaS产品，不应将创新资源浪费在多个微服务和数据库上，而应聚焦核心问题。像Notion、Netflix、Instagram等服务百万级用户的企业仍信赖"平凡"技术，你的初创项目完全无需七数据库架构。若真遇到PostgreSQL瓶颈，再按需引入其他组件也不迟。

功能替代方案：PostgreSQL内置能力

| 需求场景 | 常用方案 | PostgreSQL替代方案 | |---------|---------|------------------| | 缓存 | Redis, Memcached | UNLOGGED表、物化视图 | | 任务队列 | Redis+Sidekiq, RabbitMQ | SKIP LOCKED、pgmq、pgflow | | 全文搜索 | Elasticsearch, Algolia | tsvector、pgtrgm、ParadeDB | | 文档存储 | MongoDB, CouchDB | JSONB、FerretDB | | 向量搜索/AI | Pinecone, Weaviate | pgvector、pgvectorscale | | 时序数据 | InfluxDB, TimescaleDB | TimescaleDB、pgpartman | | 分析/OLAP | Snowflake, BigQuery | pg_analytics、DuckDB集成 | | 图数据库 | Neo4j, Neptune | Apache AGE、递归CTE | | 地理空间 | 专业GIS系统 | PostGIS |

何时真正需要其他方案

文章并非教条主义。当PostgreSQL确实无法满足需求时，可以引入专业基础设施。但门槛应足够高：只有在充分挖掘PostgreSQL潜力、记录其不足、并接受替代方案运维成本后，才应考虑引入新系统。每增加一个系统，都是在赌其收益能覆盖未来多年的维护、监控和调试成本。

根据评论内容，总结主要观点如下：

支持“用Postgres处理一切”的观点： - Postgres许可证友好，避免被云厂商锁定（PaulHoule: "unlike all the new databases, Postgres has a decent license... Everybody else is so afraid of being co-opted by AWS"） - 结合服务端渲染框架和htmx，可大幅降低复杂度（simonbarker87: "90% of the stack with 10% of the complexity"） - 对原型和MVP项目，简化基础设施可节省成本（wuliwong: "completely removing a infrastructure piece is a nice money saver"）

反对或谨慎的观点： - 专用工具（如Redis）更简单可靠（dpc10: "Redis... trivial to set up and it ~never crashes or requires maintenance"） - 将所有功能塞进Postgres会增加运维复杂度（ubercore: "the complexity of using it for everything starts to get pretty high"） - 不同工作负载对同一数据库的调优需求冲突（valentynkit: "two workloads that want opposite tuning on the same box"） - 扩展可能带来依赖和升级风险（ComputerGuru: "if using Postgres for non-essentials complicates your db backup workflow"） - 应学习专用工具而非强行统一（JsonDemWitOster: "invest in learning the right tool for the problem from the start"）

中立/技术细节讨论： - 对FerretDB能否替代MongoDB GridFS存疑（polycancel: "doesn't really replace MongoDB's GridFS"） - 建议对非核心功能使用独立Postgres实例（ComputerGuru: "use a different Postgres server/install/container for these ancillary services"） - 指出Postgres作为队列的局限性（DarkCrusader2: 引用Brandur博客说明高吞吐队列问题） - 提醒迁移到CockroachDB时需重写查询（stickfigure: "SELECT FOR UPDATE SKIP LOCKED... does not work the same way on CRDB"）

极端观点： - 认为Postgres“样样通样样松”（otabdeveloper4: "Postgres sucks. It does a little bit of everything, but badly"） - 有人转向SQLite（bitbasher: "fell in love with Sqlite and have been using it for everything"）

总结： 评论呈现明显分歧。支持者强调许可证优势、简化运维和成本节约；反对者指出运维复杂度、性能瓶颈和工具适用性。多数评论认可Postgres作为数据库的优秀性，但反对将其作为万能解决方案。