PostgreSQL Performance Work Should Happen Where You Code

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

オリジナルソース: The performance dividend: Optimizing PostgreSQL on Azure directly in Visual Studio Code

私はこの Azure アップデートの中心的な主張に同意する: パフォーマンス作業が失敗するのはツールの不足からではなく、断片化されたコンテキストからである。ほとんどのチームはすでにモニタリング、クエリエディタ、運用ダッシュボードを持っている。彼らに欠けているのは、シグナルからアクションへの継続性である。

VS Code における PostgreSQL 拡張の方向性が重要なのは、そのパスを短縮するからである。サーバーメトリクス、クエリプラン、アドバイザー推奨が、開発者がすでに SQL を編集している同じ場所に表示されると、チームは診断から修正へとより速く移行できる。それは明白に聞こえるが、実際の組織では構造的シフトである。コンテキストスイッチは、所有権が失われる場所である。

エンジニアリングリーダーにとっての実用的な部分は次のとおりである。測定可能な改善を望むなら、これらの機能をオプションのあったらいいなではなく、レビューワークフローの一部にせよ:

重要ではないクエリ変更には、クエリプランのスクリーンショットまたは要約を必須にする。
トップアドバイザー推奨を毎週追跡し、単なるアラートではなく所有者を割り当てる。
スキーマ認識 IntelliSense と search_path の正確性を、便利機能ではなく予防ツールとして扱う。

記事はまた、Azure HorizonDB を将来志向として位置づけ、Azure Database for PostgreSQL を今日の本番デフォルトとして維持している。それはまったく正しいフレーミングである。チームがプレビュー時代のテクノロジー excitement を早すぎる運用コミットメントに変えるときに問題が発生する。安定性が第一で、その後に選択的な実験である。

私の強い見解:パフォーマンス文化は、クラウドの問題である前にエディタの問題である。チューニングがファイトクラブやウォールームでしか行われないなら、あなたはパフォーマンスエンジニアリングをしているのではなく、パフォーマンスインシデント対応をしていることになる。VS Code 統合ストーリーは、より安価な修正が存在する場所へのシフトレフトをチームに支援する。

ひとつの注意点がある。統合された推奨は、チームがワークロード動作に対する仮定の検証をやめると、過信を生み出す可能性がある。AI 支援チューニングとアドバイザーヒントはアクセラレーターであり、ベンチマーク規律の代替ではない。ベースライン、反復可能なロードテスト、リグレッションゲートが依然として必要である。

組織が Azure 上で PostgreSQL を大規模に実行しているなら、今行うべき正しい動きは、この統合ワークフローを標準化し、問題検出から緩和までのサイクルタイムを計装することである。パフォーマンス配当は現実のものだが、それを運用化して初めて価値が出る。そうでなければ、それは単なる別の機能デモである。

結論: より多くの可観測性を購入するな。洞察と変更の間の距離を縮めよ。

Database-Performance | The .NET Blog

PostgreSQL Performance Work Should Happen Where You Code