PostgreSQL 性能工作应该在你写代码的地方进行

Emiliano Montesdeoca — Mon, 20 Jul 2026 00:00:00 +0000

我同意这个 Azure 更新的核心论点：性能工作失败更少是因为缺少工具，更多是因为上下文碎片化。大多数团队已经有监控、查询编辑器和运维仪表盘。他们缺乏的是从信号到行动的连续性。

VS Code 中的 PostgreSQL 扩展方向之所以重要，是因为它缩短了那条路径。当服务器指标、查询计划和顾问建议出现在开发者已经编辑 SQL 的同一个地方时，团队从诊断到修复的速度就会加快。这听起来很明显，但在真实组织中这是一个结构性转变。上下文切换正是所有权丢失的地方。

以下是对工程负责人的实用部分。如果你想要可衡量的提升，不要把这几项功能作为可选的锦上添花来引入。让它们成为你审查工作流的一部分：

文章还将 Azure HorizonDB 定位为前瞻选择，同时让 Azure Database for PostgreSQL 保持为当前的生产默认。这正是正确的框架。团队在过早将预览期技术兴奋转化为运维承诺时会遇到麻烦。先稳定，再有选择地实验。

我强烈的观点：性能文化在成为云问题之前首先是编辑器问题。如果调优只在火线和作战室中进行，你做的不是性能工程，而是性能事件响应。VS Code 集成故事帮助团队左移，在那里修复成本更低。

有一个注意事项。集成的建议可能会导致过度自信，如果团队停止基于工作负载行为验证假设。AI 辅助调优和顾问提示是加速器，而非基准纪律的替代品。你仍然需要基线、可重复的负载测试和回归门控。

如果你的组织在 Azure 上大规模运行 PostgreSQL，现在正确的做法是标准化这个集成工作流，然后检测从问题检测到缓解的周期时间。性能红利是真实的，但前提是你把它运维化。否则，它只是另一个功能演示。

核心观点： 不要购买更多的可观测性。缩短从洞察到变更的距离。

VS Code 里的 Azure PostgreSQL 说到底是在缩紧性能闭环

Emiliano Montesdeoca — Mon, 29 Jun 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

数据库性能工作之所以昂贵，主要是因为反馈闭环是碎片化的。

指标在一处，查询计划在另一处，调优建议又在别处。编辑器则和这一切脱节。

这也是为什么 VS Code 中更新后的 PostgreSQL on Azure 体验，比乍看之下更有意思。

这次更新最强的主题，是诊断和行动正在彼此靠近：

这让性能工作不那么碎片化，而真正的生产力提升通常就来自这里。

这不只是 PostgreSQL 功能的问题。

它是在缩短“看到问题”和“采取行动”之间的操作距离。这类工具改进会随着时间不断兑现价值。