2026年は10月20日から23日にかけてスペイン・バレンシアで開催されます。

本レポートでは、PGConf.EU 2026 Day3で発表された講演のうち、筆者が印象に残ったセッションを紹介します。

Where next for parallel query execution?

Thomas Munro 氏は、PostgreSQL の並列クエリ実行における課題と今後の改善の方向性について解説しました。

重要な課題の1つとして挙げられたのが、メモリ管理です。現在の PostgreSQL では、ソートやハッシュ結合などの処理ごとに、主に work_mem パラメータを上限値としてメモリ使用量を制御しています。
しかしながら、各処理がメモリを確保・解放するタイミングは実行計画や実行時の状況によって異なるため、単純な掛け算ではピーク時の使用量を正確に把握できず、システム全体で実際にメモリがどの程度使用されるのかを予測することは困難です。

work_mem を大きなサイズに設定すると OOM によるプロセス終了などの危険がある一方で、安全性を重視してwork_mem を小さくすると、利用可能なメモリを十分に活用できません。
特にクエリを複数プロセスで並列に実行する場合には、より多くのメモリを消費する可能性があるため、メモリ管理の重要性も高くなります。

この課題に対して、各処理ごとのメモリ管理ではなく、クエリ単位、さらにはシステム全体でメモリを管理する方向性が示されました。まず、クエリ実行時のピークメモリ使用量を計測し、EXPLAIN (ANALYZE) で表示できるようにしたり、共有メモリを通じて参照可能にすることが提案されました。さらに、プランニング時にはピークメモリ使用量を推定して EXPLAIN で表示できるようにする案も紹介されました。

また、クエリの実行開始を制御する Admission Control のアイデアも紹介されました。システム全体で利用可能なメモリ量を管理し、クエリごとに推定される使用量を事前に予約しておく仕組みです。メモリが不足する場合には、実行を待機させるか、work_mem を小さくして実行する方法が考えられています。

これらの改善は今後の検討課題ですが、もし実現すれば、並列クエリ実行において、安全性とリソース利用効率を両立した、より適切なメモリ管理につながる可能性があります。今後の動向に注目です。

The process of RPM packaging in the PostgreSQL ecosystem

Devrim Gündüz 氏は、PostgreSQL エコシステムにおける RPM パッケージの作成・保守プロセスと、その運用上の課題について解説しました。

PostgreSQL の RPM リポジトリでは、膨大な数のパッケージを管理しており、PostgreSQL 本体だけでなく、拡張機能やバックアップツールなども提供しています。

RPM パッケージの作成には、ビルド手順や依存関係、インストールするファイルなどを定義した Spec ファイルを使用します。パッケージングでは、Spec ファイルの作成に加え、依存関係の確認、セキュリティ検査、各 OS や PostgreSQL のバージョンとの互換性確認など、多くの作業が必要です。また、PostgreSQL が依存するライブラリなどのパッケージ名は Linux ディストリビューションによって異なるため、Spec ファイルには複雑な条件分岐が必要になるなど、多彩なディストリビューションにパッケージを提供しているPostgreSQLならではの苦労も語られました。

こうした作業を効率化するため、Claude などの AI を活用し、自動化ツールやテストコードの作成など、日常的なメンテナンス作業の効率化にも取り組んでいることが紹介されました。

特に印象的だったのは、RHEL の OpenSSL 更新に伴う互換性問題です。(参考: https://www.postgresql.org/about/news/postgresql-rpm-repository-now-supports-multiple-rhel-minor-versions-3202/)
2025年にリリースされた RHEL 9.7 および 10.1 では、OpenSSL のバージョン更新によって、以前のマイナーバージョン向けの RPM との間で依存関係の問題が発生しました。これを受けて、PostgreSQL の RPM リポジトリでは、RHEL 9 と 10 のそれぞれについて最新 2 つのマイナーバージョンをサポートし、マイナーバージョンごとに RPM をビルドする方針に変更しました。この対応に伴う作業負担は大きく、「ストレスの多い1月を過ごした」と語られたことが印象に残っています。

講演を通じて、RPM パッケージの提供は単なるビルド作業ではなく、OS の変更への対応や、セキュリティと品質の継続的な確保など、多くの保守作業によって支えられていることが実感できました。

Can We Skip Recovery? The Architecture of On-Demand WAL Replay

Srinath Reddy Sadipiralla 氏は、PostgreSQL のクラッシュリカバリを高速化する「On-Demand WAL Replay」の実験的なアーキテクチャについて解説しました。

現在の PostgreSQL では、クラッシュ後の起動時にリカバリが実行され、チェックポイント以降の WAL をすべて再生する必要があります。これが完了するまでクライアントは接続できないため、WAL の量が多いほどサービス停止時間が長くなる問題があります。

これを解決するために提案されている「On-Demand WAL Replay」では、起動時のリカバリで WAL すべてをスキャンする一方、テーブルやインデックスなどのデータページを変更する WAL レコードの適用を遅延させます。未適用の WAL レコードはページごとに共有メモリ上で管理し、ページへの初回アクセス時や、バックグラウンド処理によって適用されます。これにより、すべてのページの復旧を待たずにクライアントからの接続を受け付けられるようになります。

性能評価では、接続可能になるまでの時間が最大 5.5 倍高速化しました。一方で、初回アクセス時の遅延や、未復旧ページが存在する間のチェックポイントの制限、共有メモリの消費などが課題として挙げられました。今後はリプレイ処理の並列化や、管理情報のディスクへの退避などが検討されています。

講演の終わりには、本機能のバグ報告など、開発への協力が呼びかけられました。このように、開発中の機能についてフィードバックを募れることも、カンファレンスを開催する重要な意義であると感じました。

まとめ

以上、PGConf.EU 3日目の講演レポートでした。
本日最後に行われたクロージングセッションによると、今回の参加者は 747 名、講演数は 101 講演だったとのことです。改めて、規模の大きいイベントであると感じました。

3日間を通して、PostgreSQL の内部構造や新機能、運用上の課題など、幅広いテーマの講演を聴くことができました。また、講演後の活発な質疑応答や参加者同士の交流からも、PostgreSQL コミュニティの活気を感じました。技術的な知見だけでなく、今後の PostgreSQL の発展に向けた取り組みを知ることができた、有意義な 3日間でした。

2026年は10月20日から23日にかけてスペイン・バレンシアで開催されます。

本レポートでは、PGConf.EU 2026 Day2で発表された講演のうち、筆者が印象に残ったセッションを紹介します。

Autovacuum Is Running. Is It Actually Working?

Teresa Lopes 氏は、PostgreSQL の autovacuum が適切に動作しているかを確認する方法と、効果的なチューニングについて解説しました。

PostgreSQL の MVCC の仕組みでは更新前の行がテーブルに残るため、不要になった行（dead tuple）を VACUUM で回収する必要があります。autovacuum はこの処理を自動化しますが、デフォルト設定が必ずしも最適とは限りません。
講演では、autovacuum の起動条件を決めるしきい値とスケールファクターの影響を実験で比較しました。小規模テーブルではautovacuum_vacuum_threshold、大規模テーブルではautovacuum_vacuum_scale_factorの調整が重要です。また、コスト上限やコスト遅延、ワーカー数を調整することで、システム負荷と処理時間のバランスを改善できることを示しました。

一方、長時間トランザクションや放置されたレプリケーションスロットなどが VACUUM の処理を妨げる場合があります。さらに、通常の VACUUM ではテーブルやインデックスの肥大化を完全には解消できず、REPACK や REINDEX などが必要になることも説明しました。

最後に、PostgreSQL 19 に向けた改善にも触れ、autovacuumが適切に動作しているかを監視可能になる機能改善が多数あることが紹介されました。
PostgreSQLを運用する上でautovacuumは重要な役割を果たしていますが、適切に動作させることは難しい印象です。弊社のサポートでもautovacuumについての問い合わせは数多くあります。講演者がautovacuumのチューニングに対する苦労を語っていた点に共感しました。

How to Contribute to the PostgreSQL Documentation

David E. Wheeler 氏は、PostgreSQL の公式ドキュメントを改善し、コミュニティに貢献する方法を紹介しました。

PostgreSQL のドキュメントは XMLベースのマークアップ言語である DocBook で管理されており、Emacs や Vim などのテキストエディタで編集できます。章や段落、リンク、表、コマンドの実行例などは専用のタグで記述されます。修正後は make check で構文を検証し、HTML や PDF を生成して内容を確認できます。
変更を提出する際は、git diff で差分を確認し、git format-patch でパッチを作成します。PostgreSQL では GitHub の Pull Request ではなく、メーリングリストにパッチを投稿する方法が基本です。投稿後は CommitFest に登録することで、レビュー状況を追跡できます。
講演者は、機能の開発者でなくても、利用者として疑問に感じた点や分かりにくい説明を改善することで、PostgreSQL の発展に貢献できると強調しました。

講演内では、ドキュメントを改善してコミュニティにパッチを投稿するまでの一連の流れが紹介されており、この講演を聞けば今にでもパッチ投稿できそうなところが良かったです。また、PostgreSQLのドキュメント内で使用されている DocBook のタグについても丁寧な解説があり、非常に参考になりました。

Security Strategies for your database backups

Priyanka Chatterjee 氏は、PostgreSQL のバックアップを安全に保護するための戦略について解説しました。

データベース本体ではロールや権限、パスワード、SSL/TLS などのセキュリティ対策が重視されますが、バックアップについては取得や復元の成否、処理時間に注目が集まり、セキュリティ対策が後回しになりがちです。

バックアップの保管先が適切に保護されていないと、攻撃者に機密データを読み取られたり、バックアップファイルを改ざんされたりする可能性があります。改ざんされたバックアップを使用すると、不正なデータや設定が復元先に持ち込まれ、復旧後のシステムに新たな問題が発生する恐れもあります。また、ランサムウェア攻撃では、データベース本体だけでなくバックアップも標的となり、復旧手段を奪われる可能性があります。そのため、バックアップをデータベース本体と同じ権限やネットワークの中だけで管理することには注意が必要です。

バックアップの保管方法として、元データを含めて 3 つのコピーを保持し、2 種類の異なる媒体に保存し、少なくとも 1 つのコピーをオフサイトに保管する「3-2-1 戦略」が紹介されました。さらに、定期的な復元テストを実施し、バックアップから正常にデータベースを復旧できることを確認することも重要です。

セキュリティ対策としては、バックアップの暗号化とアクセス制御が挙げられました。クラウドストレージでは、KMS（Key Management Service）を利用した暗号鍵の管理に加え、ストレージへのアクセス制御やパブリックアクセスの制限が有効です。また、VPC やプライベートエンドポイントなどを活用したネットワーク経由のアクセス制限や、転送時の暗号化によって、バックアップへの不正アクセスや情報漏えいのリスクを低減できます。

近年、個人情報の流出事故が相次いでおり、データベースのセキュリティ対策はますます重要になっています。今回の講演を通じて、データベース本体だけでなく、バックアップの保管方法や暗号化、アクセス制御まで含めて適切に設計することの重要性を改めて感じました。

まとめ

以上、PGConf.EU 2 日目の講演レポートでした。
PostgreSQL本体の開発に参加するための方法や、開発を行ってみての知見を発表するセッションが複数あることが、本イベントの特色のうちの1つであると感じます。PostgreSQL開発コミュニティへ貢献することへの関心の高さを感じました。

2026年は10月20日から23日にかけてスペイン・バレンシアで開催されます。

本レポートでは、PGConf.EU 2026 Day1で発表された講演のうち、筆者が印象に残ったセッションを紹介します。

オープニングセッション

オープニングセッションでは、イベントの説明がされたのち、PostgreSQLとPostgres Europeの30年にわたる歴史を振り返りました。1996年頃のPostgreSQL 6.0から始まり、2008年のPostgres Europe設立、2014年のマドリード開催、コロナ禍を経たカンファレンスの復活などの紹介がありました。一番重大なトピックとして、PostgreSQL EUのマスコットとしてSlonikというマスコットキャラクターがいるのですが、今年その着ぐるみが代替わりしたそうです。新しいSlonikマスコットのお披露目や旧着ぐるみの抽選企画も発表され、会場は笑いに包まれました。

 REPACK in Core

Robert Treat 氏による、PostgreSQL 19 に導入予定の REPACK コマンドについての解説です。
PostgreSQL では、MVCC によってテーブルやインデックスが肥大化することがあります。いったん肥大化したテーブルは通常のVACUUMでは縮小できず、強いロックが必要なVACUUM FULLを実行する必要があります。

PostgreSQL 19では、VACUUM FULLの名前がREPACKに変更されました。このことにより、通常のVACUUMとの区別がしやすくなるという利点があります。
また、REPACK CONCURRENTLY機能が追加され、通常のデータベース操作への影響を抑えながら再編成できます。

REPACK CONCURRENTLY は、論理デコードを利用して更新を追跡しながら、新しいテーブルへデータをコピーします。最後に短時間の排他ロックを取得してファイルを切り替える仕組みです。

ただし、長時間トランザクションとの競合や MVCC 安全性、REPACK実行中の更新行数の上限、メモリ消費など、運用上の制約が残っています。また、実行できないテーブルもあり、複数のREPACK CONCURRENTLYを同時に実行することも推奨されていません。

講演者は、現時点では既存の pg_repack を完全に置き換えるものではないと説明しました。特に、多数のテーブルを定期的に再編成する用途では、引き続き pg_repack が有用です。

制約が多数あり、PostgreSQL 19時点では本番環境で実行することは難しい機能だと感じました。しかし、テーブルへの更新や参照をブロックしないテーブル再編成機能はニーズの高い機能であり、PostgreSQL 本体にREPACK CONCURRENTLY機能が導入されることは大きな進歩です。今後の改善が期待されます。

pg_ivm の最近の改善と方向性

弊社の長田からは、PostgreSQL のマテリアライズドビューを高速に更新するための拡張モジュール pg_ivm の最近の改善と今後の方向性について紹介されました。

pg_ivm は、Incremental View Maintenance（増分ビューメンテナンス）を PostgreSQL 上で実現する拡張機能です。通常のマテリアライズドビューでは、基となるテーブルの更新内容を反映するために REFRESH MATERIALIZED VIEW を実行してビュー全体を再計算する必要がありますが、pg_ivm は変更差分のみを計算して適用することで、自動的かつ効率的に更新されるマテリアライズドビュー（IMMV, Incrementally Maintainable Materialized View）を作成することができます。

講演では、増分メンテナンスによってビュー更新を高速化できる一方、元テーブルの更新時には差分計算やビュー更新が発生するため、一定のオーバーヘッドや同時実行性への影響があることも説明されました。

最近の機能改善としては、Outer Join（外部結合）のサポート、pg_dump および pg_upgrade への対応強化、PostgreSQL 19 への対応などが紹介されました。特に Outer Join のサポートが大きな技術的成果として取り上げられました。Outer Join では、結合相手が存在しない場合に生成される NULL で補完された行（dangling tuple）が存在するため、単純な増分メンテナンスでは適切に対応できません。pg_ivm では、Outer Join の結果を 通常の内部結合で得られる部分と、結合相手を持たない行に影響する部分に分けて扱うことで対応しています。また、以前は pg_dump によるダンプデータのリストア時やpg_upgrade によるアップグレード後にpg_ivmのメタデータが正しく復元されない問題がありました。これらについても、メタデータを復元する関数を実装することなどにより、適切にデータ移行できるように改善されました。

今後の開発では、Deferred Maintenance（遅延メンテナンス）が大きな候補として挙げられました。テーブル差分の収集とビューの更新を分離し、後からまとめてメンテナンスできるようにすることで、テーブル更新性能への影響を軽減しながら、増分メンテナンスの利点を活用できるようになることが期待されます。

Community Moments That Shaped 30 Years of PostgreSQL

Valeria Kaplan 氏による、イベントを通じて発展してきた PostgreSQL コミュニティの歴史を振り返るセッションです。 PostgreSQL は、1990 年代の開発者同士の交流から成長し、現在では世界各地でカンファレンスやミートアップが開かれています。

PostgreSQLの開発はメーリングリスト上で行われていると思われていますが、実はこのようなコミュニティイベントによる交流の力も大きいです。メーリングリストだけでは生まれにくい信頼関係や協力関係を育むことで、新機能の開発につながっています。

コミュニティイベントの開催は主に企業、登壇者、運営者によって支えられています。企業はイベント協賛の形で資金提供を行いますが、イベントへの協賛は、人材採用や認知度向上、開発動向の把握に役立ちます。一方、登壇者は講演を準備する労力を支払う一方で、知識の共有や成長の機会を得られます。運営者は多くの時間と労力を費やしますが、コミュニティに貢献する誇りや仲間とのつながりが活動を支えています。

今後の課題として、新しい登壇者や運営ボランティアの参加を増やしていくこと、多様性を向上させること、学生や他の技術コミュニティとの交流を拡大することが挙げられました。講演者氏は、小さな貢献でも大きな変化につながる可能性があるとして、積極的な参加を呼びかけています。PostgreSQLの発展にはコミュニティへの貢献が不可欠ですので、筆者も何らかの形で貢献したいと考えています。

まとめ

以上、PGConf.EU 1 日目の講演レポートでした。
初日に参加した感想としては、多くの参加者が集まり、質疑応答も活発に行われるなど、非常に活気のあるイベントだと感じました。休憩時間や昼食時には、軽食を片手に参加者同士が交流する姿も見られました。講演内容も、PostgreSQL の内部構造に踏み込んだ技術的な話から、ユーザー視点での実践的な Tips の紹介まで多岐にわたり、様々な観点からPostgreSQLについての情報収集ができるイベントだと感じます。

概要

YugabyteDB Voyagerは、無料かつオープンソースのYugabyteDB移行ツールです。PostgreSQL、Oracle、MySQLといった主要なデータベースを移行元としてサポートしており、オンプレミス環境・クラウド環境のどちらでも使用可能なため、さまざまなシステム構成からの移行に対応できます。また、すべてのYugabyteDB製品を移行対象としてサポートしています。

YugabyteDB Voyagerは、YugabyteDBに移行するにあたりどの程度修正が必要な箇所があるかをリストアップし、移行可能かどうかのアセスメントを支援します。また、実際に移行すると決定した際には、テーブル定義やインデックス定義については自動で変換を行い、移行に必要な労力を最小限に抑えます。データ移行の際にはチューニングを行い、インポートパフォーマンスの向上を自動で行います。

さらに、ソースデータベースとしてPostgreSQLを使用する場合、データベース停止が必要なオフラインマイグレーションの他に、ダウンタイムを最小限に抑えるライブマイグレーションが利用可能です。ビジネスクリティカルなアプリケーションにおいて、YugabyteDBへの移行を強力に支援します。

移行方式

YugabyteDB Voyagerで利用可能な移行方式は以下の通りです。

オフラインマイグレーション

今回は、PostgreSQLからYugabyteDBへのオフラインマイグレーションを実行してみます。
環境は以下の通りです。

今回は移行元データベースとしてPostgreSQLサーバ1台、移行先データベースとしてYugabyteDB3台のクラスタ構成を構築しています。
各サーバの情報は以下の通りです。

今回はPostgreSQLサーバ、YugabyteDBクラスタの構築手順については記載を省略します。YugabyteDBクラスタの構築についてはYugabyteDB OSS版の使い方、YugabyteDB Aeon Self-Managed (旧 YugabyteDB Anywhere) の使い方も参考にしてください。

YugabyteDB Voyagerのインストール

まず、YugabyteDB Voyagerをインストールします。
公式ドキュメントの手順に従って、インストールしてください。
本稿ではPostgreSQLサーバにYugabyteDB Voyagerをインストールしています。

ソースデータベースに対する事前準備

まず、ソースデータベース(PostgreSQL)にマイグレーション用のユーザを作成します。マイグレーション用ユーザは移行対象のすべてのリソースに対してREAD権限を持っている必要があります。

今回はybvoyagerユーザを作成します。
ソースデータベースに接続し、以下のSQLを実行しました。

CREATE USER ybvoyager PASSWORD 'password';

次に、必要な権限を与えます。移行対象のデータベースに接続し、/opt/yb-voyager/guardrails-scripts/以下にある yb-voyager-pg-grant-migration-permissions.sql を実行します。

psql -h 172.20.0.15 \
     -d db1 \
     -U postgres \
     -v voyager_user='ybvoyager' \
     -v schema_list='public' \
     -v is_live_migration=0 \
     -v is_live_migration_fall_back=0 \
     -f /opt/yb-voyager/guardrails-scripts/yb-voyager-pg-grant-migration-permissions.sql

これで、ソースデータベースに対する準備は完了しました。

ターゲットデータベースに対する事前準備

ターゲットデータベース(YugabyteDB)に移行先のデータベースを用意します。
移行先のデータベース名はソースデータベースと同じ名前でも異なる名前でも問題ありません。(以降のyb-voyagerコマンド実行時に、データベース名を指定しない場合、yb-voyagerは移行先データベースを yugabyte データベースとみなします。)
移行先データベース名をyugabyteから変更したい場合は、YugabyteDB クラスタにデータベースを作成してください。

CREATE DATABASE db1 WITH COLOCATION = true;

次に、ターゲットデータベースについてもマイグレーション用ユーザを作成します。スーパーユーザとして作成する必要があります。
今回はybvoyagerユーザを作成しました。

CREATE USER ybvoyager SUPERUSER PASSWORD 'password';

エクスポートディレクトリの設定

yb-voyagerはすべてのマイグレーションの状態をエクスポートディレクトリに書き出します。これは、Voyagerが使用するメタデータに加えて、スキーマやデータのダンプも含まれます。そのため、ソースデータベース全体を格納できる、十分な空き容量のあるファイルシステム上にエクスポートディレクトリを作成してください。

mkdir -p $HOME/yb-migrate/export-dir

マイグレーションを実行すると、yb-voyagerによって、以下のディレクトリが作成されます。

assessment: アセスメント時のメタデータと、アセスメント結果を格納します。
schema: ソースデータベースのスキーマがCSV形式で格納されます。
data: ソースデータベースのデータがCSV形式で格納されます。
metainfo/temp yb-voyagerが内部予約しているディレクトリです。
logs: コマンド実行時のログファイルが格納されます。

設定ファイルの用意

yb-voyagerコマンドには、設定値を一括で記載する設定ファイルが用意されています。設定ファイルを使用すると、コマンド実行時に逐一パラメータを指定する必要がないため便利です。(v2025.6.2以降に導入された機能です。)

/opt/yb-voyager/config-templates以下にテンプレートファイルが提供されているので、このテンプレートファイルをコピーして使用します。今回はオフラインマイグレーション用のファイル(offline-migration.yaml)を使用します。

cp /opt/yb-voyager/config-templates/offline-migration.yaml ~

ファイル内の、エクスポートディレクトリに関する項目、ソースデータベースの接続情報、ターゲットデータベースへの接続情報を編集する必要があります。以下は設定例です。

export-dir: /voyager/export-dir
yugabyted-control-plane:
  db-conn-string: postgresql://yugabyte:yugabyte@172.20.0.11:5433  
source:
  db-type: postgresql
  db-host: 172.20.0.15
  db-port: 5432
  db-name: db1
  db-schema: public
  db-user: ybvoyager
  db-password: password
target:
  db-host: 172.20.0.11
  db-port: 5433
  db-name: db1
  db-user: ybvoyager
  db-password: password

マイグレーションのアセスメント

以下のコマンドを実行して、マイグレーションのアセスメントを実施します。
このとき、先ほど作成したYAMLファイルのパスを–config-fileに指定します。
今回は、~/offline-migration.yamlを指定しています。

yb-voyager assess-migration --config-file ~/offline-migration.yaml

実行すると、評価レポートのパスがコンソールに出力されます。
評価レポートはJSON形式とHTML形式で出力されます。以下はhtml形式の評価レポートです。

移行の難易度や、非互換のオブジェクトが存在しているかを確認することができます。

スキーマのエクスポート

アセスメントが完了したら、次はソースデータベースからスキーマをエクスポートします。
以下のコマンドを実行してください。

yb-voyager export schema --config-file ~/offline-migration.yaml

実行すると、エクスポートディレクトリのschemaディレクトリに、結果が保存されます。

スキーマのエクスポートの際に、yb-voyagerはスキーマ定義の調整を自動で行います。

スキーマの分析

スキーマのエクスポート時に、yb-voyagerはスキーマ定義の調整を自動で行います。しかし、自動調整だけではYugabyteDBへのインポートが失敗する可能性があります。YugabyteDBはPostgreSQLと互換性がありますが、分散システムであるため、スキーマに若干の手動変更が必要になります。

以下コマンドを実行し、スキーマを分析してください。

yb-voyager analyze-schema --config-file ~/offline-migration.yaml

手動変更が必要なDDLステートメント一覧を表示するレポートを出力します。

スキーマの手動修正

生成されたレポートに記載のあるすべての問題について、EXPORT_DIR/schema/以下にある、対象のDDLを修正してください。手動で修正を加えたら、yb-voyager analyze-schema コマンドを再実行してください。変更内容を反映した新しいレポートが生成されます。生成されたレポートに問題がなくなるまで、この手順を繰り返す必要があります。

スキーマのインポート

スキーマの修正が完了したら、ターゲットデータベースにスキーマをインポートします。

yb-voyager import schema --config-file ~/offline-migration.yaml

yb-voyagerコマンドは、エクスポートディレクトリのschemaサブディレクトリにあるDDL を、ターゲットのYugabyteDBデータベースに適用します。もし、スキーマのインポートが途中で異常終了してしまった場合は、設定ファイルのignore-existパラメータをtrueに変更してから再実行してください。すでに作成に成功したオブジェクトは無視するようになります。

データのエクスポート

スキーマ移行が完了したら、次はデータ移行を行います。まずは、ソースデータベースからデータをエクスポートします。

yb-voyager export data --config-file ~/offline-migration.yaml

このコマンドは、EXPORT_DIR/data以下にCSV形式でデータをダンプします。

注意事項

データエクスポートの際は、以下の点に注意してください。

• PostgreSQLの場合、ソースデータベース上でロックを獲得しようとしている他のプロセスが存在しないことを確認してください。並列ジョブが複数ある場合、データをダンプすることはできません。
• シーケンスの移行は、シーケンスの作成とレジューム値の設定という2つのステップで構成されています。レジューム値はデータのエクスポート時に生成されます。また、すべてのテーブルデータがインポートされた直後に、ターゲットのYugabyteDBデータベースにこれらのレジューム値は設定されます。PostgreSQLの場合、移行対象テーブルに紐づけられている、または、テーブルが所有するシーケンスのみが移行時に復元されます。
• ソースデータベース上のテーブルの行サイズが大きすぎて、デフォルトのRPCメッセージサイズを超えている場合、インポートデータは「ERROR: Sending too long RPC message…」というエラーで失敗します。そのため、行サイズが大きいテーブルは、該当箇所を削除してから個別に移行する必要があります。

データのインポート

データをエクスポートできたら、次はターゲットデータベースにデータをインポートします。

yb-voyager import data --config-file ~/offline-migration.yaml

進行状況を確認したい場合は、yb-voyager import data statusを実行してください。

デフォルトでは、yb-voyagerは複数の接続を使用して並列にデータをインポートします。並列度はクラスタのリソース使用状況に基づいて判断されます。

yb-voyagerは、データダンプファイル(EXPORT_DIR/data)をより小さなバッチに分割します。yb-voyagerは、ターゲットのYugabyteDBデータベースクラスタのすべてのノードが使用されるように、バッチを同時に取り込みます。このフェーズは、データインポート中にyb-voyagerが終了した場合でも再開できるように設計されています。再開後、データのインポートは処理が中断された地点から続行されます。

注意事項

データインポートの際は、以下の点に注意してください。

• 大規模データセットをインポートする場合は、ターミナルセッションが終了してもインポート処理が中断されないように、screenセッションでimport dataを実行してください。
• yb-voyagerのimport dataコマンドがデータ取り込み完了前に終了した場合は、同じ引数で再度実行すれば、データインポート処理が再開されます。

データインポート後のスキーマ調整

ソースデータベースにNOT VALID制約がある場合は、データインポート後に制約を作成するコマンドを実行する必要があります。

yb-voyager finalize-schema-post-data-import --config-file ~/offline-migration.yaml

マイグレーションの検証

スキーマとデータのインポートが完了したら、データが正しく移行されていることを確認します。
ソースデータベースとターゲットデータベース(YugabyteDB)の両方で検証用クエリを手動で実行して確認を行います。
例えば、各テーブルの行数を確認するクエリを実行して行数がそろっているかどうかの確認を行ってください。

マイグレーションの終了

データが正しく移行されていることを確認できたら、移行する際に作成されたディレクトリ・データをクリーンアップします。
yb-voyager end migration コマンドで、クリーンアップを実行します。

yb-voyager end migration --config-file ~/offline-migration.yaml

必要であれば、移行に使用したybvoyagerユーザの削除も行ってください。
yb-voyagerで移行を実施すると、移行されたすべてのオブジェクトはybvoyagerユーザが所有している状態となります。
オブジェクトの所有者を別のユーザに変更してから、ybvoyagerユーザを削除してください。

終わりに

本稿ではYugabyteDBへのマイグレーション支援ツール YugabyteDB Voyagerの使用方法を紹介しました。
YugabyteDBはPostgreSQL互換データベースであるとはいえ、アーキテクチャが異なりますので、移行する際はスキーマ定義の修正が必要になります。
YugabyteDB Voyagerは、スキーマ定義の互換性の評価から実施できますので、マイグレーションを行う際の強力なツールとなります。
YugabyteDBへの移行を検討している方は、ぜひYugabyteDB Voyagerをご活用ください。

参考

YugabyteDB Voyager 公式ドキュメント

PostgreSQLを使用している方は、トランザクションIDの周回問題という言葉を聞いたことがあるかと思います。トランザクションIDの周回問題は、発生する頻度が少ない一方で、一度発生するとサービスの提供に重大な悪影響を及ぼします。本記事では、PostgreSQLを使用する方にぜひ押さえていただきたい、トランザクションIDの周回問題について解説します。

トランザクションIDとは？

そもそも、トランザクションIDとはどのような場面で使用されているものでしょうか？
前提として、PostgreSQLは追記型のMVCC(多版型同時実行制御)を採用しており、1つの論理的なデータに対して複数の物理的なバージョンの行を持っています。例えば、UPDATEで行が更新されたとき、更新前の行を残しておきつつ、新しく行を追加します。

これは、トランザクションの開始タイミングや分離レベルによって、見えるべきデータのバージョンが違うためです。
(更新前の物理行は不要となった段階でVACUUMにより回収されます。)

可視性判断

テーブルにはバージョン違いの行が複数格納されているため、参照処理の実行時には、トランザクションごとに、どのバージョンの行を見せるべきかの可視性判断を行っています。

可視性判断の簡単な例を示します。

トランザクションID 101のトランザクションまでコミット済みの状態から、トランザクションA, トランザクションBが開始しました。トランザクションAがtest2というデータをINSERTし、未コミットの状態です。 この時、トランザクションAからはtest2というデータを見ることができますが、トランザクションBからはtest2というデータは見えてはいけません。

このような可視性判断を行うため、PostgreSQLは、各行のメタデータに、どのトランザクションがその行を追加したかを格納しています。PostgreSQLは内部的に、各トランザクション固有のIDを払い出しています(トランザクションID)。その行を作成したトランザクションのIDをxmin, その行を無効にしたトランザクションのIDをxmaxに格納しています。

=# BEGIN;
BEGIN

-- 現在のトランザクションIDを確認
=*# SELECT pg_current_xact_id();
pg_current_xact_id
765
(1 row)

-- テーブルにデータをINSERT
=*# INSERT INTO members VALUES (1, '佐藤', 'sato@example.com');
INSERT 0 1

-- xmin に現在のトランザクションIDが格納されている
=*# SELECT xmin, xmax, * FROM members;
 xmin | xmax | id | name |      email
------+------+----+------+------------------
765   |    0 |  1 | 佐藤 | sato@example.com
(1 row)

トランザクションIDの周回問題

このように、可視性判断において重要な役割を担っているトランザクションIDですが、こちらは32bitの非負数であり、約42億で循環します。また、トランザクションIDは、約21億で分割され、基準点より新しい値を未来、古い値を過去として扱います。ですので、約21億を超えてトランザクションIDが払い出されると問題が発生します。

ここで具体的な例を考えてみます。
あるテーブルに対し、トランザクションIDが103のトランザクションが行をINSERTし、COMMITしました。
その後、データの変更処理が行われ、トランザクションIDが払い出されてゆきます。
トランザクションIDが進むと、どの値が未来/過去かの判定が変化していきます。
しばらくの間、トランザクションIDが103という値は過去として扱われます。つまり、トランザクションID 103のトランザクションがINSERTした行は過去のものとして扱うことができます。
しかし、トランザクションIDが約21億消費されると、トランザクションIDが103という値は未来として扱われるようになります。
こうなると、いままで過去のトランザクションが作成したものとして認識されていた行は、未来のトランザクションが作成したものとして認識されるようになってしまいます。

このような状態になってしまうと、今まで取り出されていた行が取り出せなくなってしまいます。

これが、トランザクションIDの周回問題です。

長期間運用するようなシステムや、更新量が多いようなシステムであればこの周回問題が発生する危険性は現実的なものです。ただし、PostgreSQLはトランザクションIDが約21億を超えても使用し続けるための仕組み(FREEZE)を用意しています。

FREEZE

トランザクションIDによって未来の行と判断される可能性があるのは、その行を作成したトランザクションより古いトランザクションがまだ実行中の場合です。逆に言うと、その行を作成したトランザクションより古いトランザクションがすでに終了している場合、その行は可視性判断の結果が常に可視となります。そこで、比較するトランザクションIDがどのような値であっても、それより過去に更新された行として扱うようにフラグを立てる処理を行っています。これがFREEZE(凍結)です。

FREEZEはVACUUM実行時に行われています。問題なくFREEZEが行われていれば、周回問題は回避できます。

FREEZEのタイミング

FREEZEのタイミングは以下のパラメータにより制御されています。

• vacuum_freeze_min_age(デフォルト5000万)
  • 行に記録されているxminの年代がこの値を超えたらFREEZEを行うようになる
• vacuum_freeze_table_age(デフォルト1.5億)
  • pg_class.relfrozenxid(※)がこの年代に達すると、VACUUM時に積極的にFREEZEを行う
  • 通常は無効行が存在しているページのみをスキャンするところ、未凍結の行が存在するすべてのページをスキャンして未凍結の行をFREEZEする
• autovacuum_freeze_max_age(デフォルト2億)
  • pg_class.relfrozenxidがこのパラメータで指定した年代に達したら、凍結状態でない行を含む可能性のあるテーブルに対し自動VACUUMを開始する
  • autovacuum = offでも発生
• vacuum_failsafe_age(デフォルト16億)
  • pg_class.relfrozenxidがこの年代に達すると、トランザクションID周回回避のために全力でVACUUMを行うようになる
  • コストベースの遅延を行わず、インデックスのバキュームなど緊急でない作業はスキップする
  • バッファアクセスストラテジは無効になり、VACUUMが共有バッファのすべてを自由に使用するようになる

※pg_classには、そのテーブル内ですでにFREEZEが完了したトランザクションIDを格納するrelfrozenxidという列が存在します。relfrozenxidに格納されているものより古いトランザクションIDはすべてFREEZEが完了しています。pg_databaseにもdatfrozenxidという列が同様に存在しています。

周回問題発生時の動作

しかしながら、FREEZEを阻害するような要因があると、やはり周回問題が発生してしまいます。実行中のトランザクション以後のトランザクションIDはFREEZEすることができないので、ロングトランザクションは典型的な阻害要因になります。その他、孤児となったプリペアドトランザクション(2相コミット)や、使用されていないレプリケーションスロットも阻害要因になります。

周回問題が近づくと、PostgreSQLはどのような動作になるのでしょうか？

まず、使用可能なトランザクション数が残り4000万を切ると、データ変更処理を行った際にWARNINGメッセージが出力されるようになります。これはWARNINGですので、データ変更処理自体は行われます。


WARNING: database "mydb" must be vacuumed within 39985967 transactions
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.


WARNINGメッセージが発生した後もFREEZEを阻害する要因を排除できず、周回までのトランザクション数が残り300万未満になると、PostgreSQLは新しいトランザクションIDの割り当てを拒否するようになります。
実は、トランザクションIDはそのトランザクションで初めてデータ変更処理が行われたときに割り当てられるものですので、つまりはデータの変更処理が不可能になります。


ERROR: database is not accepting commands that assign new XIDs to avoid wraparound data loss in database "mydb"
HINT: Execute a database-wide VACUUM in that database.


補足

以前のドキュメントでは、周回問題が発生したときの挙動として、以下のように記述されていました。

システムは停止し、新しいトランザクションの起動を拒絶します。

しかしながら、実際にはデータベースは停止することはありません。参照処理のみであれば実行することができます。(もっとも、更新処理は不可能になる以上サービスの提供に重大な悪影響を及ぼすことには違いありません)

周回問題発生時の対処法

周回問題が発生し、データが更新できないような状態になってしまったらどうしたらよいのでしょうか？

まずは、FREEZEを阻害する要因を特定する必要があります。

--ロングトランザクション
SELECT * FROM pg_stat_activity ORDER BY xact_start LIMIT 10;
-- 古いプリペアドトランザクション
SELECT * FROM pg_prepared_xacts ORDER BY prepared LIMIT 10;
--使用されていないレプリケーションスロット
SELECT * FROM pg_replication_slots;

FREEZEを阻害する要因を特定したら、それを取り除いてください。

--ロングトランザクション
SELECT pg_terminate_backend(《PID》);
--古いプリペアドトランザクション
ROLLBACK PREPARED '《transactionid》';
--使用されていないレプリケーションスロット
SELECT pg_drop_replication_slot('《スロット名》');

次に、通常のVACUUMを実行します。データベース全体に行っても良いですし、最も古いトランザクションIDを持つテーブル(relfrozenxidが最も古いテーブル)に対して個別に実行してもよいです。注意点として、VACUUM FULLは実行してはいけません。VACUUM FULLはトランザクションIDが必要な処理のため、周回問題発生時には失敗します。また、VACUUM FREEZEも実行しないでください。「通常の操作を回復するために必要な最小限の作業以上の作業を行う」ためです。

補足

以前のバージョンでは、「postmasterを停止してVACUUMをシングルユーザーモードで実行する」ように指示がありました。
PostgreSQLを使い慣れている方であれば、見覚えのある方も多いのではないかと思います。
しかしながら、少なくともVACUUMにフェイルセーフモードが導入されたPostgreSQL 14以降では、シングルユーザーモードにすることは不要です。
シングルユーザーモードにするとVACUUMに時間がかかるうえ、VACUUMのモニタリングも難しいことから、PostgreSQL 14以降をお使いの場合はシステムは停止せずに通常のVACUUMを行ってください。

モニタリング

周回問題が発生すると重大な影響を及ぼすことから、PostgreSQLを使用する場合は周回問題が発生していないか、モニタリングすることが重要です。
pg_database, pg_classのdatfrozenxid,relfrozenxid列に対し、age関数(現在のトランザクションIDと引数として与えたトランザクションIDとの差を求める関数)を使用して、FREEZEが完了していないトランザクションIDがどの程度あるかを監視します。

SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY age DESC;
SELECT relname, age(relfrozenxid) FROM pg_class WHERE relkind IN ('r', 'm') ORDER BY age DESC;

上記SQLを定期的に実行し、ageが増加傾向にあれば、FREEZEが阻害されている可能性を疑ってください。FREEZEが阻害されている要因を探して、対処してください。

まとめ

本記事では、PostgreSQLの周回問題についての解説を行いました。FREEZE処理が上手くいっている場合は、周回問題は発生しませんが、FREEZEを阻害するような要因(ロングトランザクション、孤児となったプリペアドトランザクション、使用していないレプリケーションスロット)が存在していると最終的にデータの変更処理が不可能になります。そうならないように、定期的にモニタリングを行うことが重要です。

はじめに

COSCUPはConference for Open Source Coders, Users, and Promotersの略で、ヨーロッパ最大のオープンソースイベントであるFOSDEMを参考に2006年から開催されている、オープンソースコミュニティが主催するカンファレンスです。

会場となったのは国立台湾科技大学で、常時20以上のトラックが並行して開催される大規模なイベントでした。講演のほかにも、BoF(Birds of a Feather, コミュニティや参加者が主催する非公式のミートアップ)や、Hacking Corner(開発者向けの交流用オープンスペース)、各OSSコミュニティのブースなどが設けられていました。

参加者人数は延べ3000人を超えており、参加していて非常に活気のあるイベントだと感じました。また、日本のOSS関連のイベントと比べると、参加者の年齢が若いと感じます。

本レポートでは、筆者が参加したセッションの中から特に印象に残ったものをいくつか紹介します。

[Prime Session] Programming Language for AI age

Rubyの開発者、まつもとゆきひろ氏による講演です。Ruby固有の話ではなく、生成AIと付き合ってプログラミングすることについて語られました。

AIを使用するのはペアプログラミングするようなもので、人間と違い、気を遣う必要がないのがメリットです。しかし、AIを使用してプログラミングするには不完全な自然言語を使う必要があります。そうすると、逆アルファ症候群(ある技術が登場すると、その技術が登場する前よりも忙しくなるにもかかわらず、それをありがたがって使用してしまう)を引き起こしてしまいます。今のところ、AIエージェントはドキュメントの生成やリファクタリングには優れている一方、大規模なプロダクトベースのプログラミングには向いていません。(使うとしても、例えばメモリ管理の部分などではAIよりもその分野に詳しくないといけないです。)

人間の言語はプログラミングに向いていないので、AIとやり取りする専用の言語が必要です。それは、簡潔で、理解しやすく、堅牢な表現力と拡張可能な語彙を持つような言語です。そして、そのような特徴を持った言語はすでに存在しています。――それはRubyである、と締めくくられました。

2025年現在のAIの能力に対する感想については、筆者が生成AIを使用した感じと似通っていました。一方で、AIとプログラミングする専用の言語が必要、という認識については思い浮かばなかった発想で、感銘を受けました。

From MongoDB to PostgreSQL

この講演では、ドキュメントデータベースのオープンソース標準を策定するプロジェクトおよびMongoDB互換のオープンソースデータベースFerretDBが紹介されました。MongoDBのライセンス変更に伴い、ドキュメントデータベースにもリレーショナルデータベースのような標準を策定必要がある、という問題意識によりプロジェクトが発足しました。

単にJSONを格納できる、という観点ではPostgreSQLも使用できますが、ドキュメントデータベースの世界ではフレームワークや開発者がMongoDBに依存しており、PostgreSQLをそのまま使用することは困難です。FerretDBは、バックエンドでPostgreSQLを動作させつつも、クライアント側ではMQLというMongoDBの問い合わせ言語を受け取ります。MQLとPostgreSQLの仲立ちをするのがFerretDBです。

また、バックエンドで動作させるデータベースはPostgreSQL互換であればよいので、例えばより高い可用性を求めるのであればバックエンドのデータベースとしてYugabyteDBを動作させることもできるようです。

Japanese Food Knowledge Graph for Taiwanese

日本でOSCを開催している、OSPN(Open Source People Network)による講演です。
日本食を例にあげて、ナレッジグラフの紹介がなされました。ナレッジグラフとは、知識を表現するグラフです。各概念を表すノードがあり、それぞれのノードはプロパティを持っています。ノード間の関係性はエッジ(線)によって示されます。例えば、カツカレーは以下のように表現されます。

Curry - CONTAINS -> Onion
Curry - CONTAINS -> Meat
Curry - IS_SERVED_WITH -> Rice
Katsu Curry - IS_COMPOSED_OF -> Curry
Katsu Curry - IS_COMPOSED_OF -> Tonkatsu

このナレッジグラフは、後述するRAG(検索拡張生成)の情報源としても使用することができます。

講演は英語で行われていましたが、日本語のできる台湾の参加者が、他の参加者の質問を日本語に通訳しやり取りするなど、和気あいあいとした雰囲気での交流がされていました。

Hot Topics in Global PGConf

この講演では、世界各地で開催されているPostgreSQLカンファレンス（PGConf）で話題のトピックについて紹介されました。PGConfで近年話題になっているものを紹介することで、最新技術トレンドや地域ごとの特色、あるいは地域に関係なく役立つ知見を共有することを目的とした講演でした。

技術トピックとしては、AI×pgvectorによるベクトル検索、pg_hint_planやVACUUMを中心としたパフォーマンス最適化、論理レプリケーションやActive-Active構成による高可用性、EDB Postgresのセキュリティ強化、RDSやAuroraなどクラウド移行の事例が紹介されました。PostgreSQL 18の新機能にも触れられていました。

台湾のPostgreSQLコミュニティに技術トレンドを紹介する目的の講演でしたが、紹介された技術トピックは日本のPostgreSQL Conferenceでもよく選ばれているトピックであり、親近感を覚えました。

Community-Driven Edge AI or Building Offline AI Agents with Open Models

この講演では、オープンモデルを活用したオフラインAIエージェントについて紹介されていました。従来のAIはネットワーク接続が前提でしたが、モバイル端末上で動作する「AI Driven Device」への進化が進んでおり、オフラインでも動作可能なAIエージェントのニーズが高まっています。

まず、生成AIが備えておくべき機能として、マルチモーダル(複数の種類の情報、例えばテキストデータのほかに画像や音声、動画を入力として受け取れる)、Function Calling(AIが外部の関数やAPIを呼び出す機能、例えばユーザから写真を受け取って位置を推測し、Google Mapを呼び出す)といった概念が紹介されました。

次に、Googleが開発したオープンモデルであるGemma 3、Gemma 3 Nanoについて紹介されました。
どちらのモデルもマルチモーダル、Function Callingといった機能を兼ね備えています。特にGemma 3 Nanoはサイズが小さく、モバイル端末にも組み込み可能なうえ、完全オフラインで動作する点が特徴的です。

生成AI分野が主題の講演も1つは参加してみようと思い聴講した講演でしたが、図や写真が多くスライドに掲載されており、事前知識が薄くともわかりやすい講演でした。

打開 AI 模型的任意門：用 PostgreSQL 撐起AI

こちらの講演では、PostgreSQLを生成AIの長期的な文脈保持に活用するための方法が紹介されました。
生成AIの既存のモデルを使用して独自チャットボットを作成する際、RAGという手法が使われます。これは、生成AIに参考にさせたい情報をあらかじめデータベースに保存しておき、問い合わせが来たら「関連がありそうな」情報をデータベースから探し出してAIに渡すことで、より求めている回答に近づける手法です。

RAGが登場した際はテキストデータを単にベクトル化し、ベクトルデータベースに保存することが考案されていましたが、このベクトルデータベースには欠点があります。それは、「関連がありそうな」情報をベクトル間の距離により算出するため、チャットの参考にさせるには望ましくないテキストが算出されてしまうという問題です。
本講演ではナレッジグラフを作成しておき活用する方法について紹介されました(Graph RAGといいます)。
ナレッジグラフは知識が構造化されていますので、場合によってはベクトルデータベースを使用するよりも望ましいテキストを抽出することができ、生成AIの精度向上に役立ちます。

筆者が参加したPostgreSQL関連の講演では一番参加者が多く、生成AIへの関心の高さが肌で感じられました。

監控與告警設計：打造適合團隊使用的 PostgreSQL 觀測儀表板

この講演では、金融業の大規模なデータベース環境におけるPostgreSQLの監視・可視化の取り組みが紹介されました。クレジットカード業務を例に、822万枚以上の流通カードを扱う高負荷なシステムにおいて、DB管理者がどのようにサービス性能を向上させているかが語られました。

DBAとデータ分析チームの視点の違いを踏まえた監視設計をしていました。DBAはCPU、メモリ、IO、WALサイズなどのリソース管理を重視し、分析チームはクエリの待機状態やブロックされたプロセスなど、ユーザーの行動に着目するためです。講演では、PrometheusとGrafanaを用いて、両者のニーズを満たす観測ダッシュボードを構築する方法が実例とともに紹介されました。

紹介された監視項目はpg_stat_activityやpg_locks、VACUUの進捗状況などで、一般的にPostgreSQLの状態を把握するのにつかわれるビューやテーブルが網羅的に紹介されていました。また、観測ダッシュボードは視覚的にわかりやすくて良いと感じました。

20 週年論壇：總召視角下的開源精神

COSCUP 開催 20周年を記念した対談です。COSCUP 歴代の代表者が参加し、オープンソースの精神についてをメインに対談が行われました。
対談中に、特に印象に残った点をいくつかあげます。

まず、ソフトウェアをオープンソースとすることのメリットは、コミュニティによる議論によってソフトウェアを改善していくことができる点です。多くの人がそのソフトウェアについて議論をすることで、単独で開発していた時には起こらなかった発想が生まれ、より洗練されたものにできます。

次に印象に残ったのは、「オープンソースに貢献することは、コミュニティに善意を共有している」という考え方です。
オープンソースコミュニティにおいては、善意で誰かに助けてもらうことがあります。ソフトウェアのエラーについて質問すると、誰かにこたえてもらった、というようなことです。この助けてくれた人は、何らかの利益を求めて貢献しているのではなく、質問者が今後コミュニティに何らかの貢献をすることを期待しているのです。

そして、オープンソースの精神を維持するには、オープンソースの考え方を発信し続けていく必要がある、という考え方にも感銘を受けました。時代は変化し続けており、オープンソースの精神を脅かすような技術が台頭してきています。例えば、ブロックチェーンはデフォルトでオープンである一方、ブロックチェーンのユーザがオープンソースの考えに関心があるかは微妙です。また、生成AIやクラウドコンピューティングは構成が複雑なため、オープンであることを要求することは難しいです。このような時代の変化の中で、COSCUPを通じてオープンソースの精神を広めていく必要がある、と述べられていました。

筆者は入社して以来PostgreSQLに関連する業務を行ってきましたが、本対談に参加することによりコミュニティへ貢献することの重要性を再認識しました。

終わりに

COSCUP 2025 へ参加し、聴講してきた講演から印象に残ったものを紹介しました。COSCUPにおいても、AIに関する関心は非常に高く感じられました。講演のタイトルにもAIという単語が含まれているものが多く、またAI関連の講演は他のものと比べ参加者が多い傾向にありました。一方で、AIが目まぐるしく進歩し、変化していく時代の中で、オープンソースコミュニティをどのように維持していくか、が重要だと感じました。今後、筆者も業務で主に使用しているPostgreSQLコミュニティについて、何らかの貢献ができればと思います。