システムや機能の「非推奨」と「廃止」について議論します。PostgreSQLに20年以上前から残る古いCOPY構文を削除したいという課題意識から出発し、様々なプロダクトの機能廃止ポリシーを比較します。O'Reilly『Googleのソフトウェアエンジニアリング』で語られる「コードは資産ではなく債務である」という考え方や、廃止を難しくする3つの要因、そして勧告的廃止と強制的廃止の違いについて解説します。さらに、Kubernetesにおける厳格なAPI・メトリクスの廃止ルールとそれを活用したGKEの自動アップグレードの仕組み、SQL Serverの非推奨機能のトラッキング機能などを紹介します。最後に、明確な廃止ルールのないPostgreSQLの現状に触れ、今後の「非推奨機能の使用統計を取る機能」の提案に向けた展望について語ります。

システム・機能の非推奨と廃止 / Googleのソフトウェアエンジニアリング / コードは資産ではなく債務 / 勧告的廃止と強制的廃止 / KubernetesのAPI Deprecation Policy / GKEの自動アップグレード機能 / SQL Serverの非推奨機能メトリクス / PostgreSQLの廃止ポリシー

参考リンク

• Googleのソフトウェアエンジニアリング
• Kubernetes Deprecation Policy
• Google Kubernetes Engine (GKE) | Feature and API deprecations
• SQL Server, Deprecated Features object
• PostgreSQL: A deprecation policy

Y Combinator CEO の Garry Tan が公開した Claude Code 向けスキルパック「gstack」について紹介します。gstack は think, plan, build, review, test, ship, reflect というスプリントを回すためのプロセスを定義したものです。ETHOS.md に書かれた「Boil the Lake」「Search Before Building」「User Sovereignty」という3つの哲学や、CEO レビュー・エンジニアレビューなど様々な役割を持つスキルの設計思想について深掘りしました。

gstack / ETHOS.md / Boil the Lake / Claude Code スキルパック / Y Combinator / Garry Tan / AI エージェント / User Sovereignty

参考リンク

• gstack GitHub リポジトリ: https://github.com/garrytan/gstack/tree/main

• Boil the Ocean (Garry Tan のブログ記事): https://garryslist.org/posts/boil-the-ocean

データベース向けMCP (Model Context Protocol)サーバーについて読み解く2回エピソードの後編となる今回は、PostgreSQLエンジニアのShinyaが自作した「PostgreSQL開発補助用MCPサーバー」のアーキテクチャや設計思想について深掘りします。

PostgreSQLの開発はメーリングリスト（pgsql-hackers）で行われており、情報の検索性やAIエージェントからのアクセスに課題がありました。この課題を解決するため、Claudeと壁打ちしながら設計を進めたプロセスを紹介します。

pg_trgm（3文字区切り）やtsvector（単語区切り）といったPostgreSQLの組み込み・拡張機能を用いた強力な全文検索インデックスの活用方法について、データベースエンジニアの視点から解説します。また、長大な引用メールによるトークン消費問題などの課題や、MCPサーバー実装での学びについても議論します。

PostgreSQL開発とメーリングリスト / 自作MCPサーバー / Claudeとの壁打ち設計 / FastMCP / pg_trgmとtsvectorによる全文検索 / 長大な引用とトークン消費問題

DBHub が公開したテックブログを元に、PostgreSQL 向け MCP (Model Context Protocol) サーバーの現状について読み解きます。2回に分けたエピソードの前編となる今回は、Google のToolBox for Databases、Supabase、そして DBHub の3つの MCP サーバーの実装と特徴を比較します。各サーバーにおけるコンテキストウィンドウ（トークン消費量）節約の工夫や、OIDC 認証と RLS (Row-Level Security) を連携させたアクセス制御について解説します。さらに、MCP を経由した SQL インジェクションやプロンプトインジェクションの実例を挙げ、AI エージェントにおける最小権限の原則などセキュリティ対策の重要性について議論します。

なお、冒頭では番組の隔週配信化とクオリティ向上への取り組みについても報告しています。

番組の隔週配信化 / MCP (Model Context Protocol) とデータベース / Google ToolBox for Databases / OIDC 認証と RLS (Row-Level Security) / Supabase MCP サーバー / DBHub とトークン消費の最適化 / MCP 経由の SQL インジェクション / プロンプトインジェクションと AI エージェントの権限管理

参考リンク

• The State of Postgres MCP Servers in 2025
• googleapis/genai-toolbox
• supabase-community/supabase-mcp
• MCP vulnerability case study: SQL injection in the Postgres MCP server
• Supabase MCP can leak your entire SQL database

今回も引き続きポッドキャストバー「雑談」での対面収録。対面での収録はリモートと比べて話しやすく、アイコンタクトや目配せができるなど、コミュニケーションの違いを実感しました。キャリアの深掘りとして、お互いが情報系・物理系に進んだきっかけや、 Shinya がデータベースを選んだ理由について語り合いました。また、開発環境やガジェット、エディター、便利ツール、仕事での英語使用、最近ハマっていることなど、幅広いトピックについて雑談しました。

対面収録の感想 / キャリアの原点(情報系・物理系を選んだ理由) / ガジェット紹介(キーボード・ディスプレイ・椅子) / VS CodeとVim / Coding agent (Claude Code・Gemini CLI・CodeX) / 仕事での英語 / 最近ハマっているもの

今回は初の対面収録をポッドキャストバー「雑談」から配信。広木大地さんの著書『AIエージェント 人類と協働する機械』を紹介し、AIがソフトウェア開発に与える影響について3つの視点から議論しました。ソフトウェアエンジニアの需要は増えるのか減るのか、解くべき課題がどう変わるのか、そしてマクロとミクロの視点をどう持つべきかを深掘りしています。

初の対面収録 / ポッドキャストバー「雑談」 / 25回収録の振り返り / AIエージェント書籍紹介 / ジェヴォンズのパラドックス / System of Knowledge Generation (SOK) / Forward Deployed Engineer (FDE) / 暗黙知の結晶化 / マクロとミクロの視点

参考リンク

• 「AIエージェント 人類と協働する機械」: https://amzn.asia/d/0btG9SKJ

今回はSQLiteの公式ドキュメント「Why is SQLite coded in C」を紹介。2000年に誕生したSQLiteがなぜC言語で書かれているのか、その理由を3つの観点から深掘りしました。パフォーマンス、互換性、安定性などC言語のメリットから、オブジェクト指向言語や新しい言語（Rust、Go）を採用しない理由まで、データベース開発における言語選択の考え方を議論しています。

リスナーコメント紹介 / SQLiteの概要と特徴 / Small, Fast, Reliableの設計思想 / C言語がベストな理由 / オブジェクト指向への見解 / RustやGoで書き直さない理由 / 100%ブランチカバレッジテスト / パブリックドメインライセンス

訂正

• エピソード内で「CREATE DATABASE コマンドを打つとデータベースファイルが作成される」と説明していますが、正しくは CREATE TABLE コマンドです。

参考リンク

• Why Is SQLite Coded In C: https://sqlite.org/whyc.html

OpenAI が公開したテックブログ「Scaling PostgreSQL to Power 800 Million ChatGPT Users」を、大規模サービス開発経験のある Lon と PostgreSQL エンジニアの Shinya の2人で読み解きます。後編となる今回は、Azure PostgreSQL のコネクション上限に対処するための PgBouncer の活用、キャッシュミス時の DB 負荷急増（Thundering Herd）を防ぐロック機構、50台のリードレプリカ運用におけるネットワーク負荷とカスケーディングレプリケーション、ORM レベルでのレートリミット、そしてサービス停止を防ぐための慎重なスキーマ管理とデータバックフィル戦略 など、ブログ後半の具体的な技術トピックについて議論します。

PgBouncer とコネクションプーリング / キャッシュミス対策とロック機構 / カスケーディングレプリケーション / ネットワーク帯域とプライマリー負荷 / アプリケーション・ORM層でのレートリミット / スキーマ管理とフルテーブルリライト回避 / データのバックフィル戦略 / 基本的な設計の重要性

参考リンク

• Scaling PostgreSQL to power 800 million ChatGPT users: ⁠https://openai.com/index/scaling-postgresql/