Postgres 并不慢，慢的是你的存储
许多工程师把 PostgreSQL 的慢归因于数据库本身，但评论者认为，云时代的选择，如网络挂载存储（例如 EBS）以及不够理想的模式或查询，往往才是真正的瓶颈。他们将本地 NVMe 和精心调优的索引，与托管式、带复制的块存储进行对比，强调延迟、运维简便性、可靠性和成本之间的权衡。讨论还延伸到更广泛的话题：云抽象如何掩盖硬件现实、何时专门化数据库甚至是运行在快速本地磁盘上的 SQLite 能胜过重量级方案，以及人们对 AI 生成技术内容日益增长的厌烦。
感知到的 AI 生成“垃圾”内容
- 一些评论者觉得，博客标题和行文越来越像 LLM 生成的，这让他们即使主题相关也更不愿意读。
- 也有人反驳，指出“X 并不慢，Y 才慢”这种模式早在 LLM 出现之前就有了。
- 大家反复抱怨总是有人指控作者是 AI；有些人觉得这种元层面的抱怨比可能的 AI 内容本身还烦。
- 提出的想法包括：给 HN 链接自动加 AI 检测标签，或者自愿标注“AI 辅助”，这样读者想的话可以自行过滤。
Postgres 到底为什么“慢”？
- 一派观点认为：存储往往是瓶颈，尤其是云上的网络挂载卷与本地 NVMe 相比；有人报告迁移到本地 NVMe 后，真实场景延迟从 1.0ms 降到 0.1ms。
- 另一派则认为：比起存储，模式设计和查询往往才是更常见的真正问题——糟糕的索引、“可移植”的模式，以及缺乏针对数据库的调优。
- 也有人强调一些 Postgres 的具体技巧：仅索引扫描 / 覆盖索引、索引布局（“列式俄罗斯方块”）、索引膨胀管理，以及在生产环境中使用真实统计信息。
- 共识是：存储和模式 / 查询设计都很重要；任何一方都无法单独弥补另一方的严重短板。
云存储 vs 本地磁盘
- 许多人批评云块存储（例如 EBS）相较于本地 NVMe 又慢又贵，认为云计算掩盖了现代硬件真正的速度。
- 支持者强调运维上的好处：易于复制、故障切换、扩容、快照，以及无需自己管理 RAID、备用盘和凌晨 3 点的紧急状况。
- 关于成本的争论很多：有人说云相比租用裸金属“贵得离谱”；也有人指出本地部署硬件价格在上涨，而云能节省人力和时间。
- 还有人指出，在本地 NVMe 上做应用层复制可能比网络存储更快，但这需要严肃的工程投入和运维纪律。
替代方案、专门化与硬件加速
- 在单节点场景（网页应用、游戏服务器）中，SQLite 配合本地 NVMe 因超低延迟而受到称赞，主要担忧集中在持久性和备份上。
- DuckDB + NVMe 被认为非常适合分析场景，但会受并发限制。
- 有人猜测会出现由 LLM 生成的、高度专门化的数据库；但大多数回复强调可靠性、生态系统，以及构建一个 DBMS 的巨大复杂性。
- 也有人对用于连接和扫描的硬件加速（FPGA、SmartSSD、GPU）感兴趣，不过评论者指出商业和运维上的障碍。