Postgres 正在吞噬数据库世界

查询规划器行为与控制

• 一些评论者称赞 Postgres，但抱怨它的非确定性查询规划器。
• 痛点包括：规划器选择顺序扫描或“错误”的索引、因很小的谓词变化导致性能剧烈波动、连接顺序问题，以及连接重排的折叠限制。
• 提到的变通方法有：EXPLAIN ANALYZE、禁用特定计划类型（enable_seqscan = off 等）、调优 random_page_cost、使用 CLUSTER 改善索引/表相关性，以及重写连接。
• 有些人希望有显式的计划提示；另一些人则认为规划器通常是对的，问题往往源于统计信息、vacuum，或模式/查询设计。
• 第三方扩展如 pg_hint_plan 提供了手动影响计划的能力。

物化 / 增量视图

• 大家非常关注增量视图维护，以便让复杂分析“实时保持新鲜”。
• 目前常见的变通方案是物化视图加定时刷新（例如 pg_cron）。
• 像 pg_ivm 这样的扩展已经存在，但限制很多；这或许解释了为什么它没有成为核心功能。
• 对可行性的争论：有人认为这“不过是查询上的索引”，也有人以差分数据流系统（Materialize、Noria、流处理框架）为例，说明这确实可行，但很复杂。

管理、升级与运维体验

• 很多人表示 Postgres 现在已经很容易管理；autovacuum 被认为很有效。
• 就地升级据说表现很好，但有些人仍然会经历令人痛苦的 dump/restore 工作流，尤其是在使用 PostGIS 等扩展时。
• 提到的工具包括 pgAdmin、dBeaver、Web 客户端；对 pgAdmin 的体验褒贬不一。

与 .NET / EF Core 的使用

• 多个反馈称使用 EF Core 和 Npgsql provider 进行生产部署很顺畅。
• 通常被描述为稳定、性能良好，并且更新及时。

比较、局限与替代方案

• Postgres 被广泛称赞为一个多才多艺的默认选择；一些公司把它作为 Oracle/MySQL 之外的标准方案。
• 怀疑者指出技术债务、每连接一个进程的模型、写放大，以及它不适合超高吞吐事务系统或以高可用优先的分布式用例。
• 在某些特定领域，专用系统（TigerBeetle、Cassandra/Dynamo、Kafka、Elastic、ClickHouse、DuckDB、SQLite）仍然被认为是必要的。
• 关于 Postgres 全文搜索也存在争论：内置 FTS 被认为不如 Elasticsearch，但扩展（ParadeDB、PGroonga、pg_trgm、pgvector、混合搜索）显著增强了能力。

生态、兼容性与热潮

• 扩展和协议兼容性被视为主要优势；许多“新数据库”被认为是基于 Postgres 或与 Postgres 相邻的方案。
• 有些人认为对 Postgres 的热情有潮流化的特征；另一些人则指出它有数十年的历史，并且反复经历“热潮周期”，人们在尝试过时髦系统后又回到它。
• 一些新项目旨在实现 Postgres 兼容，而不复用其代码库，以利用现有工具和开发者偏好。