📝

PostgreSQL Conference Japan 2025 参加レポート

に公開
PostgreSQL
PostgreSQL
conference
イベント参加レポート
idea

カンファレンスについて

受付で、当日の講演内容がまとめられた案内本が配布されていました。題目だけでなく、各講演のスライドちょい見せみたいな資料があり、講演内容のイメージがつきやすかったです👍

https://www.postgresql.jp/jpug-pgcon2025

セッション内容

The Rise of PostgreSQL as the Everything Database

https://github.com/Snowflake-Labs/pg_lake

snowflake Inc. が OSS として公開した、PostgreSQL にApache Icebergとデータレイクの機能を統合するためのオープンソース拡張機能

pg_lake integrates Iceberg and data lake files into Postgres. With the pg_lake extensions, you can use Postgres as a stand-alone lakehouse system that supports transactions and fast queries on Iceberg tables, and can directly work with raw data files in object stores like S3.

S3 などに格納されたファイルに対する操作を PostgreSQL を介して分析などを行うことができます。
公演内のデモでは、データベース分析をビジネスチームが LLM を介して行うシナリオが紹介されていました。

セキュリティ対策としての PostgreSQL マイナーバージョンアップ

PostgreSQL の安全な運用を実現するためには、セキュリティ修正やバグ修正が反映されるマイナーバージョンの定期的なアップデートが不可欠です。本セッションでは、マイナーバージョンアップの役割やリリースのタイミング、適用方法など、セキュリティ対策の観点から解説します。 安定したシステム運用のための実践的なポイントをお伝えします。

https://speakerdeck.com/jri_narita/sekiyuriteidui-ce-tositeno-postgresql-mainabaziyonatupu

脆弱性のマイナーアップデートについて、過去の実績から統計的な結果を提示されていました。
統計結果や分析結果が掲載されているので、ぜひ資料をご覧になってみてください

  • 深刻なものは見つかっていないものの、重要な脆弱性対応パッチは年に多くて 10 件ほどリリースされている
  • マイナーバージョンアップで機能変更はわずかに (1~3件) 含まれていることがある
  • 🙄マイナーバージョンの内容次第では、追加手順が推奨されていることがある
    • 統計すると、index の再作成/制約の再設定 が多い

PostgreSQL セキュリティパッチ一覧

脆弱性情報について気になったので、直近の重要な脆弱性対応の内容について調べてみました

https://www.postgresql.org/support/security/CVE-2025-8713/

PostgreSQL optimizer statistics allow a user to read sampled data within a view that the user cannot access. Separately, statistics allow a user to read sampled data that a row security policy intended to hide. PostgreSQL maintains statistics for tables by sampling data available in columns; this data is consulted during the query planning process. Prior to this release, a user could craft a leaky operator that bypassed view access control lists (ACLs) and bypassed row security policies in partitioning or table inheritance hierarchies. Reachable statistics data notably included histograms and most- common-values lists. CVE-2017-7484 and CVE-2019-10130 intended to close this class of vulnerability, but this gap remained. Versions before PostgreSQL 17.6, 16.10, 15.14, 14.19, and 13.22 are affected.

  • 問題点
    • オプティマイザ統計情報（ヒストグラムや最頻値リスト）を通じて、本来保護されているデータが間接的に漏洩する。
  • 技術的影響
    • ビューのアクセス制御リスト（ACLs）や行セキュリティポリシー（RLS）がバイパスされ、非公開データがサンプリング結果として読み取られる。
  • 結果
    • 権限のないユーザーによる機密データの情報漏洩が発生する。

おもしろって思っちゃいました😆
プロジェクトで使っているパッケージの脆弱性について、アップデートを行うかはさておき、まずは脆弱性の内容は把握しないとな、と思いました

PostgreSQL 監視ツールを徹底比較

PostgreSQLの監視ツール、何を選べばいいか迷っていませんか？ 本講演は監視ツール選択の "はじめの一歩"を後押しするため、主要なツール（PEM、pg_statsinfo、Zabbix、PoWA、PMM、pgwatch、Prometheus）の特徴を比較解説します。 自社の運用にぴったりなツールを絞り込むためのポイントを、ユースケース別に分かりやすくお届けします。

比較情報はとても情報量多いので...
ペルソナに沿って、どのツールが適していそうか、で判断します

また、監視ツールの技術選定フレームワークも資料に記載されていました。(嬉しい)

  1. 監視対象と監視粒度の明確化 (What)
    1. まずは「何のために、何を、どこまで見たいのか」を定義します。
  2. 対象システム環境の確認 (Where)
    1. 監視対象のDBがどこで稼働しているかを確認します。
  3. 既存の社内エコシステム (How)
    1. 既存の社内エコシステムへの統合を検討します。
  4. 運用体制とコスト (Who / How much)
    1. 誰が、どのようなコストで運用しますか？

ペルソナ： ISUCON で活用することを想定してみる

(大会で使われる DB は MySQL のことが多いですが, もし PostgreSQL だったら・・・と仮定します)

  1. 監視対象と監視粒度の明確化 (What)
    • 障害検知 : 不要
    • 性能分析・ボトルネック分析 : 最重要
      • スロークエリの特定, クエリ分析
  2. 対象システム環境の確認 (Where)
    • AWS EC2
  3. 既存の社内エコシステム (How)
    • 既存の統合監視基盤はない
  4. 運用体制とコスト (Who / How much)
    • 8時間の大会のみでの利用
    • 運用はない
    • 無償提供が条件
    • 大会の時間が限られるため、いかに短時間で導入できるかは重要

ちと実務要件から離れすぎれるかもですね

消去法で、

  • pg_statsinfo + pg_stats_reporter
  • PMM

が残りました。
ここまで絞られれば、実際に導入してみて検証する範囲内でよいかと思います。

いただいた情報からの判断であれば、PMM は grafana のスキルセットが求められるようですので、エンジニアのスキルセットも判断に入りそうですね。

Change Data Capture 入門：Debezium で PostgreSQL のデータを解放しよう！

PostgreSQL が基幹系 DB などに採用されるケースが増えるとともに、そのデータを外部にニアリアルタイムで取り出して、負荷分散や分析などの用途で利活用したいケースが増えています。このようなニーズに対して、Debezium は PostgreSQL の WAL をデコードし、テーブルの行単位の変更を自動検知・配信できる OSS です。本講演では、その仕組みや構成例、運用上の注意点を紹介します。

Debezium の内部動作について詳しくなれました。
様々な DB ソフトウェアに対応しているようですが、PostgreSQL においては WAL ファイルをデコードして行っているようです。知りませんでした

  • 🔑 CDC : Change Data Capture
    • 異種間のデータベースのレプリケーションが可能
    • CDC の実現方法には 2 パターンある
      1. WAL ファイルをデコード (ロジカルデコーディング) して内容を解釈し、送信する
        • 👍 処理が高速
        • 👍 Trigger の管理が不要で処理が複雑にならない
        • 👎 DDL(CREATE / ...) は CDC 対象外
          • WAL をデコードするアーキテクチャ上の制約
        • 👎 WAL デコードは対象の DB クラスタの WAL 全てに実施される
          • CDC 対象外の DB についてもデコードされる. 負荷が高まる場合がある
        • 👎 PostgreSQL の REPLICA IDENTITY は、論理でコードで「どの列をキーとして行を識別するか」を決めるため、UPDATE/DELETE で一意のキーがないと失敗する
      2. DB に Trigger を作成する
        • 👍 手軽に利用可能
        • 👎 すべてのデータ変更に対して追加の書き込み（トリガーの実行と履歴テーブルへのI/O）が発生する
        • 👎 多数のテーブルを管理する場合、管理が大変

Debezium

  • 基本的に Apache Kafka と連携

Debezium plugin を導入すると勝手に DB にトリガーが作成されるものだと思っていました。WAL をでコーディングしてるんですね 👀

  • トランザクションの commit 時にイベントを送信
    • 大きなトランザクション (100K ~ / xaction) があると、Kafka への反映が遅延する可能性あり
    • PostgreSQL14 で導入された、実行中の大規模トランザクションをストリームする仕組みには対応していない
  • 1トピック1パーティション問題
    • 各トピックはデフォルトでパーティション数1
    • Kafka 側でパーティション数を増やすことは可能だが、非推奨
  • 文字コードが UTF-8 以外だと Debezium エラーが発生する

Debezium の制約・・・というより、CDC のアーキテクチャとして WAL をデコードする方式由来の欠点が多数述べられていた印象です。
とはいえ Debezium による CDC が便利なのは間違いないので、今回で注意点を多数知れたのは嬉しいところです

データベース利用調査報告2025

https://www.postgresql.jp/jpug-pgcon2025

上記 HP に結果を記載する、とアナウンスがあったのでそのうち記載されているんじゃないかと思います。

調査方法が変わったりで、前回の調査から結果が大きく変わったところもありますが、約1000名に尋ねた結果を報告いただきました。

詳細は HP に記載されるのかと思いますので、わかりやすいところで 利用しているDB順位 は下記の結果でした

  1. SQL Server
  2. Oracle
  3. MySQL
  4. PostgreSQL
  5. DB2

Oracle が２位になった、という点で盛り上がっていましたね。

1,2 がベンダー提供, 3,4 は OSS ですが、その間には 1.5 ~ 1.8倍 くらいの壁がありました。
やはり多くの企業はベンダーからのサポートを受けられるシステムを利用することの利益が大きいと判断されるのでしょう。

Discussion