RIZAPエンジニアがPostgreSQL Conference Japan 2025に初参戦！
こんにちは！ RIZAPテクノロジーズでバックエンドエンジニアを担当している佐藤と梅田です。
2025年11月21日、PostgreSQLの最新トピックや開発現場のナレッジを得られる、国内最大級の PostgreSQL カンファレンス「PostgreSQL Conference Japan 2025」に参加してきました！ RIZAPとしては今回が初めての参加となります。
カンファレンスに参加した経緯
RIZAPテクノロジーズが発足した当初は、どのデータベースを使うべきかが明確に議論されていませんでした。
しかし、chocoZAP の事業が拡大し、全国の多くの方にご利用いただけるようになったことで、より複雑で多様な要件に応えられる基盤が必要になり、PostgreSQL を採用するに至った経緯があります。
PostgreSQLは長年多くのユーザーに使われていて安心感があるだけでなく、豊富な機能が備わっている点も大きな特徴です。今回のカンファレンスのキーノートが「The Rise of PostgreSQL as the Everything Database（あらゆる用途に対応するデータベースとしてのPostgreSQLの躍進）」と題されていたように、まさに「なんでもあり」なデータベースだと実感しています。標準機能が充実しており、痒いところに手が届く──そんな点も PostgreSQL を選んだ理由の一つです。
実際、私たちは chocoZAP の予約システム開発で PostgreSQL の「多重範囲型（multirange）」を活用しました。この取り組みは Kaigi on Rails 2025 でも発表していますので、ぜひこちらもご覧ください。
多重範囲型については、今回のカンファレンスでも活用事例が紹介されており、まさに同じテーマが取り上げられていたことに驚きました！
ここからは、今回参加したセッションの中でも、特に印象に残った内容を紹介していきます。
1：2025 年版 トランザクションID 関連の問題の傾向と対策（梅田）
このセッションでは、PostgreSQL の内部動作を理解するうえで重要となる トランザクションID（XID） の仕組みと、それにまつわる問題、そして対処法が丁寧に解説されていました。
PostgreSQL は追記型の MVCC（多版型同時実行制御）を採用しており、1つの論理的なデータに対して複数の物理的なバージョン行を持ちます。たとえば、usersテーブルのnameカラムを「山田」から「林」に更新する場合、トランザクションが完了するまでは、外部からの参照では「山田」を返しつつ、トランザクション内部では「林」を参照できる必要があります。
このようにトランザクションごとに参照すべきデータが異なるため、PostgreSQL ではトランザクションごとに トランザクションID（XID） を割り当て、その値によってどの行バージョンが見えるべきか（可視性）を判断しています。
この ID は 32bit の非負整数で管理されており、約 42 億で値が循環します。この循環によって起こるのが、いわゆる XID の周回問題 です。通常は自身より ID が大きいものを「未来」、小さいものを「過去」とみなしますが、値が循環すると本来は未来のはずのデータが、過去のデータと誤解される危険があります。
この問題を防ぐために備わっているのが FREEZE?という仕組みです。PostgreSQL は古い行に “どのトランザクションから見ても過去の行” というフラグを付与することで XID の比較を省略し、周回の影響を回避します。
しかし、FREEZE が正常に進まない状況、たとえば長時間トランザクションやロックが残り続けてしまうケースでは、FREEZE の遅れが積み重なり、周回が近づく危険が高まります。実際、周回が迫ると、
周回地点の 4000 万手前で WARNING
300 万を切ると新規トランザクションを受け付けなくなる
という、深刻な状況になります。
そのため、pg_class や pg_database に記録されている FREEZE の進捗情報を監視することが重要であり、FREEZE を妨げている長寿命トランザクションを早期に検知して終了させるオペレーションも欠かせないと説明されていました。
後半では、行ロックを複数のトランザクションで共有するための仕組みであるマルチトランザクションについても紹介がありました。マルチトランザクションにも独自の周回問題が存在し、メンバースペースの枯渇やキャッシュの入れ替えで性能劣化が起こることがあるなど、運用における注意点が多い領域です。
トランザクションID関連の問題は、普段のアプリケーション開発では忘れられがちな領域ですが、問題が発生するとサービス停止にもつながりかねない重大なテーマです。今回のセッションを通じて、内部動作の理解と運用上のリスクをあらためて意識する良い機会となりました。
続いてのセッションでは、PostgreSQL における性能監視の考え方や、ボトルネックを特定するためにどのような指標を見ていくべきかについて、非常にわかりやすく解説されていました。
まず、性能監視をすることで、想定通りのレイテンシで動作しているかの確認や、問題発生時に原因を切り分けるための情報収集などができます。しかし、膨大なメトリクスを見ただけでは、どこが問題の原因なのか判断するのは難しい場合が多いです。
そこで例として紹介されていたのが、“お医者さんの問診” にたとえるアプローチでした。
どこに症状が出ているのか（特定クエリか全体か）
いつから発症したのか（時間帯、イベントの有無）
症状の悪化ペース（特定のイベントが原因なのか、テーブルの肥大化などの徐々に発生する問題なのか）
前兆や持病はあったか（表面的な問題とは別な要因の有無）
といった観点を整理することで、問題の切り分けがしやすくなります。
こうした問題を正確に特定するためには、あらかじめ適切なメトリクスを収集しておくことが重要です。
特に収集しておくべきメトリクスとして、待機イベントが紹介されていました。 待機イベントは、プロセスが「何を待っているのか」を示す指標で、pg_stat_activity から確認できます。CPU、IO、ロックなど、どこで待ちが発生しているかを把握することで、ボトルネックの特定に非常に役立ちます。
また、性能分析で使われる pg_stat_statements についても触れられていました。PostgreSQL公式のプラグインであり、クエリID、クエリ、実行回数、実行時間などを、同型のクエリでまとめて集計してくれます。監視ソフトはpg_stat_statements?を利用して累計データを定期的に取得し、前回値との差分を追跡しているという、監視ソフトの仕組みについても話されていました。
性能監視では、CPU やメモリの使用率だけを見ていても、必ずしも問題の本質にたどり着けないことが多いと感じています。今回のセッションを通じて、待機イベントや差分観測といった指標に着目するアプローチの重要性を再認識しました。
特に、ボトルネックの特定においては、プロセスが「何を待っているか」を示す待機イベントを観察することで、より的確な原因の特定につながるという新たな視点を得ることができました。基本から実践まで丁寧に解説されており、非常に学びの多いセッションでした。
2：PostgreSQL レプリケーション徹底解説（佐藤）
このセッションでは、富士通株式会社の黒田隼人さんより、PostgreSQLのレプリケーション機能について解説されていました。
レプリケーションの基盤となるのが、WAL（Write-Ahead Log）です。データ変更時、その内容を即座にテーブルファイルに反映するのではなく、まずWALにログとして記録し、その後適切なタイミングでテーブルファイルに反映します。これにより、ディスク書き込み回数の削減、データの一貫性保証、そしてレプリケーションの実現という3つのメリットが得られます。
セッション後、他のデータベースとの違いについて気になり調べてみたところ、MySQLでは「Redo Log」（クラッシュリカバリ用）と「Binlog」（レプリケーション用）という2つの異なるログを使用するのに対し、PostgreSQLではWALという統一されたログで全ての役割を一本化していることがわかりました。この設計の違いは、運用の複雑さにも影響を与えていることを知り、PostgreSQLの設計思想の一貫性を改めて実感しました。
PostgreSQLには2つの主要なレプリケーション方式があります。ストリーミングレプリケーションは、WALをバイナリデータとしてそのまま転送し、インスタンス全体を複製する仕組みです。構成が容易で処理が高速ですが、特定のテーブルだけを選択的にレプリケーションすることはできません。一方、論理レプリケーションは、WALを解析して必要な変更情報だけを抽出して転送します。テーブル単位で複製対象を選択でき、異なるPostgreSQLバージョン間でのレプリケーションも可能ですが、DDLは自動複製されず、処理のオーバーヘッドが大きくなります。
実務では、システム全体の冗長化や高可用性が求められる場面ではストリーミングレプリケーション、柔軟なデータ統合や分散が必要な場面では論理レプリケーションが適しています。WALという統一された仕組みの上に2つの異なるアプローチが構築されているという設計思想が、PostgreSQLの柔軟性を支えていることを実感しました。
PostgreSQL 18 の統計情報と pgstats の豆知識
このセッションでは、PostgreSQL Major Contributorのミカエル・パキエさんより、PostgreSQL 18で強化された統計情報の機能について解説されていました。
現代のデータベース運用において、統計情報の監視はシステムの安定稼働に不可欠です。数値化されたデータがあれば、パフォーマンスのボトルネックを客観的に特定でき、的確な改善策を講じることができます。
PostgreSQL 18では、pg_stat_ioビューが大幅に強化されました。バイト単位のI/O統計（read_bytes、write_bytes、extend_bytes）が追加され、I/O操作の実際のデータ量を正確に認識可能です。さらに、WALのI/O操作がpg_stat_ioで追跡できるようになり、WAL関連のI/O負荷を詳細に把握できます。
PostgreSQL 18の最大の変更点の一つが、非同期I/O（AIO）サブシステムの導入です。従来の同期I/Oではデータの読み書きが完了するまでプロセスが待機する必要がありましたが、非同期I/Oでは複数のI/O要求を同時に発行できます。実際のベンチマークでは、最大2～3倍のパフォーマンス向上が確認されています。
また、EXPLAIN ANALYZEコマンドも強化され、自動的にBUFFERSオプションが含まれるようになりました。さらに、特定のバックエンドプロセスごとにI/OとWAL統計を確認できる新しい関数（pg_stat_get_backend_io、pg_stat_get_backend_wal）が追加され、「どのセッションがシステムに負荷をかけているか」を特定できます。
実務で役立つツールとして、pg_activityが紹介されていました。PostgreSQLのパフォーマンスをリアルタイムで視覚的に監視でき、PostgreSQL 18の新機能にも対応しています。また、PostgreSQL 18では、pg_upgradeによるメジャーバージョンアップグレード時に統計情報が保持されるようになり、アップグレード直後から最適なパフォーマンスが得られるようになりました。
今回のセッションを通じて、PostgreSQL 18の新機能を積極的に活用することで、数値に基づいた的確なチューニングを行い、システムの安定性とパフォーマンスを継続的に向上させることができると感じました。
懇親会の様子
カンファレンスの終了後に開催された懇親会では、スピーカーの方々と直接対話する貴重な機会に恵まれました。
特に印象に残ったのは、富士通株式会社の黒田隼人さんとの交流です。セッションで理解が及ばなかった点について直接質問することができた上、時間の都合で触れられなかった技術的背景や実務での注意点を丁寧に教えていただきました。
PostgreSQL特有の拡張機能の豊富さについても話が及び、安心して使える拡張機能の見極め方や、PGXN（PostgreSQL Extension Network）の活用など、実践的なアドバイスは目からうろこでした。
初参加で初心者である私たちに対して、黒田さんをはじめ多くの方々が献身的に教えてくださる姿勢から、PostgreSQLコミュニティの温かさと強さを実感しました。RIZAPではまだPostgreSQLを使い始めて日が浅く、社内でのナレッジが十分に形成されていない状況ですが、このような強いコミュニティの存在は大きな支えとなります。
今回のカンファレンスと懇親会を通じて、PostgreSQLコミュニティの一員として迎え入れていただいたことを実感し、これからはRIZAPとしてもPostgreSQLのさらなる発展に貢献していきたいと思います。
まとめ
冒頭のキーノート「The Rise of PostgreSQL as the Everything Database」では、データベースにおける複雑性の課題に対する PostgreSQL のアプローチが紹介されました。一つのサービス内で複数の種類のデータベースを扱うケースが増えている中で、それらを PostgreSQL に集約・統一しようという動きが語られていました。
近年、AI をはじめとする技術の進化が急速に進む中で、それを支えるための「データの蓄積と活用」がますます重要になってきています。生成AIでは数兆規模のデータが学習に活用されるとも言われています。今後も扱う情報の種類や量は多様化・膨大化していくでしょうし、アプリケーション開発でも AI活用を見据えたデータ基盤の整備が欠かせません。
こうした背景を踏まえると、多様なデータ要件を PostgreSQL ひとつで支えられるようにする取り組みは、今後さらに必要性が高まっていくと感じました。
RIZAPとしても、より良いプロダクト開発をするために、PostgreSQL の技術的な進化やコミュニティの動向に引き続き注目していきます！
関連する求人情報
