# 未来はPostgresにある（Changelog Interviews #688）

- 番組: [Changelog Master Feed](https://ai-curator.jp/podcasts/shows/cmv3z5c1q00125o1015pp7smg)（Changelog Media）
- 元のタイトル: The future is Postgres (Changelog Interviews #688)
- 配信日: 2026年10月29日
- 長さ: 1時間46分
- 要約作成日: 2026年10月29日
- トピック: [#PostgreSQL](https://ai-curator.jp/topics/PostgreSQL) [#pg_lake](https://ai-curator.jp/topics/pg_lake) [#DuckDB](https://ai-curator.jp/topics/DuckDB) [#Apache Iceberg](https://ai-curator.jp/topics/Apache%20Iceberg) [#ETL](https://ai-curator.jp/topics/ETL) [#オープンソース](https://ai-curator.jp/topics/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9) [#AIとコード生成](https://ai-curator.jp/topics/AI%E3%81%A8%E3%82%B3%E3%83%BC%E3%83%89%E7%94%9F%E6%88%90)
- URL: https://ai-curator.jp/podcasts/cmvshw9je00025m1015m05azy

## 要約

Snowflakeで Postgres 部門を率いるCraig Kerstiensが、Postgresの「退屈なコア」と拡張機能エコシステムの強みを語る。DuckDBとIcebergをPostgresに持ち込むpg_lake、ETLの苦痛、Postgres 19の注目機能、AI生成PRがコミッターに与える負荷や脆弱性開示の難しさまで幅広く議論した。

## ポイント

- Craigは、Postgresが安定したコアと豊富な拡張機能で成り立ち、拡張を通じて実質的にデータプラットフォームやランタイムのように使えると述べている。
- pg_lakeは約12の拡張の集合で、PostgresにIcebergカタログと組み込みDuckDBを載せ、S3上のParquetを通常のSQLで作成・照会できる。
- OLTPとOLAPの分断やETLは大きな痛みの源で、同僚の「ETLのEはevilのE」という冗談が紹介された。
- Postgres 19ではREPACK CONCURRENTLY、クエリプランの固定、GROUP BY ALL、グラフプロパティ対応などが目玉だとCraigは評価している。
- コミッターは約50人と少なく、AIが生成した低品質なPRの流入が負担になっている。Cで書かれ学習データが少ない点も課題とされた。
- セキュリティ脆弱性は、クラウド事業者と連携した責任ある開示とパッチ提供が重要だと語られた。

## 章立て

- [03:14] **Postgres人気とその理由** — 毎年「Postgresの年」と言われる状況や、Herokuで早くから採用した経緯、人気の背景を振り返る。
- [10:24] **拡張機能とpg_lake** — Postgresのコアを退屈に保ち拡張で広げる思想と、IcebergカタログとDuckDBを組み込んだpg_lakeの構造を紹介。
- [14:45] **OLTP/OLAP、ETLの痛みとDuckDB・Iceberg** — 行指向と列指向の違い、ETLの負荷とコスト、DuckDB・Parquet・Icebergの役割を解説する。
- [32:16] **Postgres 19の注目機能** — REPACK CONCURRENTLY、プラン固定、グラフ対応、GROUP BY ALL、UPSERTの改善などを紹介。
- [48:00] **AIとオープンソースの保守負担** — AI生成PRによるコミッターの負担、DBAの不足、CからRustへの移行議論などを話す。
- [1:04:39] **テスト体制と脆弱性の責任ある開示** — ビルドファームやコミットフェスト、Snowflakeの検証、ゼロデイ対応と公開の緊張関係を議論。
- [1:29:41] **Snowflakeの戦略と今後** — データベースミラーリングやpg_lakeの活用例、Postgres学習・貢献の方法を語る。
- [1:40:53] **Supabaseなど新世代とまとめ** — Postgres上に構築する新興企業を評価する観点と、Postgresへの期待で締めくくる。

## 解説記事

Snowflakeで Postgres の取り組みを率いるCraig Kerstiensが、Changelogのインタビューに登場した。Heroku、Citus Data、Microsoft、Crunchy Dataを経て Postgres に関わり続けてきた人物が、拡張機能、pg_lake、次期 Postgres 19、そしてAI時代のオープンソース運営の課題について語った回である。

#### 「退屈なコア」と拡張機能の力

Craigは、毎年のように「今年こそPostgresの年」と書く記者がいると笑いつつ、Herokuで採用した当時は誰も賭けようとしなかったと振り返る。Postgresは課題管理ツールもGitHub上のPRもなく、メーリングリストにパッチを送る運営でありながら、30年以上改善を続けている。その理由は自分にも再現方法が分からないと述べている。

人気の鍵として挙がったのが拡張機能だ。BM25全文検索（ParadeDBやTimescaleのpg_textsearch）やPostGISなどがあり、コアは堅実に保ちつつ周辺で機能が広がる。聞き手は、これをOSやランタイムのようなものだと表現し、Craigも「データプラットフォームだ」と同意した。

#### pg_lake：PostgresにIcebergとDuckDBを入れる

Craigが「芸術作品」と呼ぶpg_lakeは、約12の拡張から成る総合拡張である。出発点はPostgres内にIcebergカタログを置くことで、その上でクエリするためにDuckDBを組み込み、SQL構文や関数の変換、GeoParquet対応、拡張間のバージョン管理までそれぞれ拡張で解決した。

結果として、`create table ... using iceberg` と書くだけでデータがS3上のParquetとして保存され、通常通りinsertやselectができる。クエリ時はDuckDBが高速な分析を担い、SparkやSnowflakeなどIcebergを読めるエンジンからも参照できる。Craigは、Pythonスクリプトを別マシンで動かす代わりにpg_cronで済ませる例も挙げた。実際に、Athenaなどで3か月かけたパイプラインをpg_lakeに置き換えた人の話も紹介されている。

背景として、行指向のOLTPと列指向のOLAPの分断がある。両チームは別世界で、ETLは本番DBに負荷をかけ、遅延やコスト、障害の原因になる。同僚の「ETLのEはevilのE」という冗談を引き、Craigはその苦痛を強調した。DuckDBは分析版SQLite、ParquetはCSVの列指向版、Icebergはその上に更新や削除を重ねるメタデータ層という説明だった。

#### Postgres 19の注目点

CraigはPostgres 19を「JSONB以来、約10年で最大級」と評価する。目玉は次のとおり。

- **REPACK CONCURRENTLY**：pg_repackやpg_squeezeといった外部拡張が担っていたテーブルの肥大（ブロート）解消を、ロックなしでコアに取り込む。
- **クエリプランの固定**：Oracleのヒントに相当する要望に対し、プランナーを回避するのではなく、特定クエリのプランを固定して突然のプラン変更による障害を防げる。
- **グラフプロパティ**（SQL標準に沿ったもの）、**GROUP BY ALL**、UPSERTで既存行を返せる改善なども挙げられた。

また、企業がOracleやSQL Serverのライセンスから離れ、Postgresに賭ける流れも指摘している。

#### AI時代のオープンソースと保守負担

議論はAIの影響に移る。Craigによれば、コミッターは約50人で、AI生成の低品質なPRが押し寄せている。フロントエンドならモデルで形になるが、Cは公開コードが少なく、データ破損のリスクもあるため事情が異なるという。DBAの数が増えない一方で開発者は急増しており、データベース知識のギャップが広がるとも述べた。

セキュリティでは、モデルが数十年残っていたバグ（PostGIS作者が見つけた15年前の小さなメモリリークなど）を見つけている例が紹介された。それでもPostgresは多くの企業や政府が使い、監視の目が多いため安心だというのがCraigの見方だ。CからRustへの書き換えはメーリングリストで定期的に話題になるが、現実的ではないとした。

脆弱性対応では、過去に深刻なゼロデイがあったことに触れ、修正のリリースをクラウド事業者が即日展開できるよう調整する責任ある開示の重要性を語った。Snowflakeも拡張の導入前にAIを使った自動スキャンを行い、メンテナに連絡し、修正パッチ付きで報告する方針だという。

#### Snowflakeの狙いと関わり方

Snowflakeにとってpg_lakeは土台であり、最終形はPostgresとSnowflakeを双方向にリアルタイムで複製するデータベースミラーリングだとCraigは説明する。スマートTV事業者が視聴データをPostgresに取り込み、Snowflakeで分析した広告の判断をPostgresに戻して低遅延で配信する例も紹介された。

関わり方としては、pg_lakeのGitHubで試す、pgsql-hackersメーリングリストで開発を学ぶ、pgsql-usersで質問に答える、コミットフェストでパッチをレビューしテストするといった方法が挙げられた。Postgres 19のベータをテストすることが、最も歓迎される貢献だという。

#### まとめ

今回の対話から見えるのは、Postgresが「単一のデータベース」から、分析やAI用途を取り込む拡張可能な基盤へと広がっている姿だ。日本のエンジニアにとっては、専用システムを増やさず運用を一本化する選択肢としてpg_lakeが注目に値する。Postgres 19の機能は運用負荷の低減に直結しそうだ。一方で、少数のコミッターに依存する体制やAI生成コードの流入、脆弱性開示の調整は、オープンソースを使う企業にとっても他人事ではない。使うだけでなく、テストや報告で貢献する姿勢が問われている。

> この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: Changelog Master Feed「The future is Postgres (Changelog Interviews #688)」