PostgreSQL Conference Japan 2026

イベント名	PostgreSQL Conference Japan 2026 （日本語略称： PostgreSQL カンファレンス 2026）
日時	2026 年 11 月 27 日（金）10:00 - 18:10 （開場 9:30、18:30 から懇親会あり）
場所	AP東京八重洲（中央区） 7F（東京駅より徒歩 6 分）
イベント URL	https://www.postgresql.jp/jpug-pgcon2026 (English page by Google Translate)
E-Mail	jpug-pgcon @ ml.postgresql.jp
主催	特定非営利活動法人日本PostgreSQLユーザ会（JPUG）
内容	午前 2 講演、午後 3 トラックにて 14 講演、クロージングセッション (18:30 から懇親会)
予定参観人数	200 名程度
参加費用	有償（事前チケット購入、発売開始は 9月27日です）

昨年の PostgreSQL Conference Japan 2025 に続きまして、2026 年もカンファレンスを開催いたします。PostgreSQL Conference Japan 2026（PostgreSQLカンファレンス2026）は、日本における PostgreSQL に関する総合カンファレンスイベントです。

■ イベント協賛

協賛いただける企業・団体を募集中です。詳しくはイベント説明資料をご参照のうえ、jpug-pgcon @ ml.postgresql.jp「JPUG カンファレンス担当」までお問い合わせください。

■ プログラム

	Room A	Room B	Room C
10:00 - 10:10	オープニング
10:10 - 11:10	【K1】 Agent State Is a Database Problem: Memory, Traces, and Replay on PostgreSQL （英語／通訳あり） Yugabyte, Inc. Nasiullha Chaudhari
11:10 - 12:10	【K2】 Per-Backend Statistics: See What Every Connection Is Actually Doing （英語／通訳あり） Amazon Web Services, Inc. Bertrand Drouvot
12:10 - 13:10	昼食休憩（60 分）
	【一般トラック： A】	【一般トラック： B】	【チュートリアルトラック】
13:10 - 14:00	【A1】スマートに性能改善！PostgreSQL 19の「pg_plan_advice / pg_stash_advice」による実行計画の制御株式会社アシスト丸岡茜、田中梨沙	【B1】製造業IoT/M2Mデータと戦うYDC SONAR/PG-Stromの挑戦フューチャーアーティザン株式会社瀧本淳史ヘテロＤＢ株式会社海外浩平	【T1】実例で学ぶ！AIエディタを活用したPostgreSQL内部実装の読み解き方～ソースコードレベルでPostgreSQLを理解するエンジニアになる！～ NTT OSS センタ石井愛弓
14:10 - 15:00	【A2】 Zabbixだけでここまでできる PostgreSQL監視株式会社SRA OSS 越野太基	【B2】 22TB・19万テーブルのPostgreSQLを17→18へ ― サービス停止約2時間で実現したメジャーアップグレード手法株式会社日本経営大島祐未	【T2】オプティマイザ統計解説日本ヒューレット・パッカード合同会社篠田典良
15:00 - 15:20	休憩（20 分）
15:20 - 16:10	【A3】コミット成功を返したデータを失わない冗長構成を求めて - PostgreSQL3台+Patroni quorum構成の保証と限界大塚知亮	【B3】 PostgreSQLをAmazon EC2で自前運用するということ ― 巨大メモリ・冗長化の設計と課題 Sansan株式会社岡本晴人	【T3】事例で学ぶVacuumの可観測性株式会社NTTデータ加藤慎也
16:20 - 17:10	【A4】意味で検索することで表記揺れは解決できるのでしょうか？堀本泰弘	【B4】 11万枚の胸部X線に挑む - pgvectorとCitusで作るマルチモーダルRAG- 三谷篤	【T4】 PostGISの上流から下流まで～現代の地図アプリケーション開発の勘所株式会社MIERUNE 井口奏大
17:10 - 17:30	休憩（20 分）
17:30 - 18:10	【クロージングセッション】
18:30 - 20:20	懇親会

■ チケット購入

参加チケットは 2026年 9月 27日からイベントレジストで販売開始いたします。チケット種別は以下の通りです。

チケット種別
	通常価格	早割価格 (10 月 27 日終了)
講演（チュートリアル含む）	￥8,000.	￥4,000.
講演（チュートリアル含まず）	￥5,000.	￥2,500.
懇親会	￥5,000.	-

＜お申込み情報について＞
本カンファレンスにお申込みいただいた皆様の氏名やメールアドレス、オプション入力の地域、所属を、本カンファレンスのプラチナスポンサー、ゴールドスポンサー企業に情報配信の目的で提供させていただきます。主催団体ではリストの維持管理はしておりませんので、登録の解除は配信元企業に要請ください。
住所欄がございますが地域を知りたい目的でございますので都道府県まで記載いただければ十分でございます。

＜チケット代金と領収書、消費税について＞
主催団体の日本 PostgreSQL ユーザ会は適格請求書発行事業者ではございません。チケット領収書にインボイス交付はできません。領収書はイベントレジストから取得いただけます。

■ 講演募集

通常講演の募集は終了いたしました。多数のご応募、ありがとうございました。クロージングセッション内でのライトニングトークは募集中です。

本カンファレンスでの講演を募集いたします。午後からの 12 セッションの内、通常セッション（50分）6 枠の講演を一般募集いたします。

募集要項

テーマは、PostgreSQL に関連する話題一般とします。
講演者氏名、連絡先、タイトル、アブストラクト（200 文字以内程度の文面にて講演内容の概略）を記載のうえ、jpug-pgcon @ ml.postgresql.jp 「JPUG カンファレンス担当」まで電子メールにてお送りください。
募集締め切りは 2026 年 9 月 9日です。
募集講演につきましては講演料のご用意はございません。懇親会にはご招待させていただきます。
登壇者のカンファレンス参加費用は不要です。他の講演の聴講もできます。
国内で、開催地から 100Km を超える所在の講演者様には出張費用を当会規定に基づきお支払いたします。
時間は 50 分間です。質疑時間を含めますので 5 分程度を差し引いて構成ください。
当日配布資料の原稿は 2026 年 10 月 27日までに作成、お送りいただきます（希望により配布する紙面の冊子に含めないことも可能です）。

ライトニングトーク募集

クロージングセッション内でのライトニングトークを募集しています。

チケット購入、招待参加、当日スタッフなど、何らかの形で入場資格を得ている方が対象となります。時間は 3分～5分で設定させていただきます。ハンドルネームでのエントリも可能です。jpug-pgcon @ ml.postgresql.jp まで「LT応募」を含む表題で電子メールにてお申込みください。

■ 実行委員／スタッフの募集

本イベントの実行委員や当日スタッフも募集しております。

① 実行委員募集

実行委員につきましては募集終了いたしました。

本イベントの実行委員として参画いただける方を下記の条件にて募集いたします。お問い合わせ先メールアドレス宛に氏名、PostgreSQL やイベント運営に関する略歴、意気込みを記載してお申し込みください。

ハンドルネーム、匿名での参加はできません。
必要経費を支給いたしますが、委員の報酬はございません。
本カンファレンスに関係者として参加できます。
担当いただく役割は決まっておりません。事前準備の様々な仕事の一部を担当いただきます。

② 当日スタッフ募集

本イベント当日にスタッフとして参加いただける方を下記の条件にて若干名募集いたします。お問い合わせ先メールアドレス宛に氏名、意気込みを記載してお申し込みください。

基本的には当日 8:00 前に現地に集合いただきます。
参加チケット購入は不要です。ただし、懇親会に参加するのに懇親会チケットは必要です。
日当、交通費の支給はございません。Tシャツとお弁当が支給されます。
配布物準備、会場設営／撤収、受付、セッション司会や副司会の作業を実施いただきます。
（座席はお客様優先として）業務が無いときにセッションを聴講できます。
ハンドルネーム、匿名でのスタッフ参加はできません。

■プログラム詳細

【K1】Agent State Is a Database Problem: Memory, Traces, and Replay on PostgreSQL

Yugabyte
Nasiullha Chaudhari

Everyone building AI agents eventually hits the same wall. The agent works in the demo. In production, it retries a failed step and produces a duplicate result. It forgets context from the previous session. A trace goes missing and nobody can explain what the agent actually did.

These are not model problems. They are database problems, and PostgreSQL already knows how to solve them.

AI agents generate three distinct data patterns that map directly to PostgreSQL strengths. Episodic memory, the record of what an agent did in a session, is a time-ordered, high-write workload with short read windows. Semantic memory, the distilled knowledge an agent carries across sessions, is lower-write with trust-scored retrieval and cross-session aggregation. Execution traces, the audit trail of every tool call, decision, and result, are append-only with point-in-time replay requirements.

This talk shows how to model all three on PostgreSQL using familiar primitives: partitioned tables for episodic memory, materialized views and pgvector for semantic retrieval, and WAL-backed append-only tables for trace replay. We will also cover the schema patterns that break under agent workloads and why, and what idempotency design at the database layer means for agents that retry under failure.

The session includes a live demo of an agent workflow backed by a PostgreSQL-compatible distributed database, showing memory writes, semantic retrieval, and trace replay end to end. Attendees will leave with concrete schema patterns and a mental model for treating the database as the foundation of agent correctness, not just agent storage.

▲

【K2】Per-Backend Statistics: See What Every Connection Is Actually Doing

Amazon Web Services
Bertrand Drouvot

PostgreSQL has traditionally offered cluster-wide or database-wide statistics. But when you have hundreds of connections and something goes sideways due to excessive I/O, WAL generation, or lock contention, the question is always: which backend? Answering that has meant polling pg_stat_activity, parsing logs, or guesswork.

The new per-backend statistics infrastructure changes that. Per-backend I/O and WAL statistics are already committed, with transaction counters, relation access patterns, and lock statistics proposed. Together, they give you direct, real-time visibility into what each connection is actually doing.

We’ll cover what’s landed, what’s coming, and the design behind it. Then in a live demo, we’ll run a mixed workload and identify the misbehaving backend on the spot — no log grep, no polling loops, just direct observation.

▲

【A1】スマートに性能改善！PostgreSQL 19の「pg_plan_advice / pg_stash_advice」による実行計画の制御

株式会社アシスト
丸岡茜、田中梨沙

データ量や条件の変化で実行計画が揺らぎ、処理速度が遅くなることはありませんか？ PostgreSQL 19 の pg_plan_advice／pg_stash_adviceを使えば、実行計画に対する推奨事項を可視化し、特定のSQLに適用することで実行計画を安定させることができます。本講演では、機能の概要から実装・適用方法、運用のポイントまでをデモを交えて紹介します。

▲

【A2】Zabbixだけでここまでできる PostgreSQL監視

株式会社SRA OSS
越野太基

PostgreSQLの安定した運用には、適切な監視が欠かせません。 ZabbixにはPostgreSQLを監視するための機能が標準で用意されており、基本的な監視を手軽に行うことができます。本セッションでは、ZabbixによるPostgreSQL監視の基本から、標準で用意されている監視項目、さらに標準にはないPostgreSQL固有の監視項目を追加する方法まで紹介します。また、PostgreSQLのモニタリングビューから取得した情報をZabbixで継続的に蓄積・可視化する例を通じて、ZabbixでPostgreSQLをどこまで監視できるのかを解説します。 PostgreSQLの監視をこれから始める方から、既存の監視を改善したい方まで、実際の設定・検証例を交えて実運用に役立つ監視手法を紹介します。

▲

【A3】コミット成功を返したデータを失わない冗長構成を求めて - PostgreSQL3台+Patroni quorum構成の保証と限界

大塚知亮

PostgreSQLの同期レプリケーションは「何台のスタンバイにWALを書けたか」は制御できますが、「次のPrimaryをどれにするか」と「そのノードにコミット成功済みのWALがあるか」は決めません。この2つをPatroniと3台中2台のflushを待つquorum同期(ANY 1)で解決し、可用性を高めつつも、コミット成功を返したデータをフェイルオーバで失わない構成とその限界を紹介します。

▲

【A4】意味で検索することで表記揺れは解決できるのでしょうか？

堀本泰弘

検索語には、同義語・類義語・異体字・同音異義語など、さまざまな表記揺れが生じます。セマンティックサーチなら、こうした表記の違いを意識せず検索できるはずです。字面ではなく意味によって検索するためです。

しかし、本当にそうなのでしょうか？
本講演では、以下の3つを比較し検索結果を検証します。

正規化・辞書を用いた従来のキーワード検索
PGroongaを用いたセマンティックサーチ
pgvectorを用いたセマンティックサーチ

セマンティックサーチという同じアプローチでも、検索エンジンや実装の違いによって結果は変わるのでしょうか？実際の検索結果を通して、表記揺れに対する各方式の違いを明らかにします。

▲

【B1】製造業IoT/M2Mデータと戦うYDC SONAR/PG-Stromの挑戦

フューチャーアーティザン株式会社
瀧本淳史
ヘテロＤＢ株式会社
海外浩平

製造現場では、IoT/M2M機器から大量の時系列データが継続的に生成されます。一方、エッジ環境ではストレージ容量やI/O帯域、CPU資源に制約があり、収集したデータをそのまま蓄積・分析するだけでは性能や運用コストが課題になります。

本講演では、フューチャーアーティザンが提供する製造業向けBI「YDC SONAR」と、HeteroDBの「PG-Strom」を組み合わせた共同検証について紹介します。データ形式の変換や事前集計、Parquet形式による効率的なデータ保存に加え、Parquet CacheやGPU-Direct SQLを活用し、製造業の現場で生成される大量のセンサデータをエッジ環境で効率よく蓄積・分析するための取り組みと検証結果を解説します。

▲

【B2】22TB・19万テーブルのPostgreSQLを17→18へ ― サービス停止約2時間で実現したメジャーアップグレード手法

株式会社日本経営
大島祐未

22TB、約19万テーブル、24時間365日稼働――このPostgreSQLを、どうすれば約2時間の停止でメジャーアップグレードできるのか。

pg_upgradeだけでは遅く、論理レプリケーションだけでは差分に追いつかない。そこで、複製環境をpg_upgradeしてPostgreSQL 18環境を構築し、本番環境の変更ログを収集・リプレイする「物理＋論理」のハイブリッド方式を採用しました。 PostgreSQL 17→18移行で実際に直面したボトルネック、カットオーバー、中止判断まで、巨大ITサービスを短い停止時間で移行するための実践手法を紹介します。

▲

【B3】PostgreSQLをAmazon EC2で自前運用するということ ― 巨大メモリ・冗長化の設計と課題

Sansan株式会社
岡本晴人

Sansanは、データセットのほぼ全体をOSキャッシュに載せるPostgreSQLを、複数シャードに分け複数AZで冗長化している。なぜマネージドではなくEC2で自前運用するのか。巨大メモリの機種選定、Pacemakerによる仮想IPフェイルオーバー、Terraform/Ansibleでの構成管理に加え、巨大メモリの代償だった不均一メモリアクセスによる性能劣化と、今後の展望を話す。

▲

【B4】11万枚の胸部X線に挑む - pgvectorとCitusで作るマルチモーダルRAG-

三谷篤

NIHCCが公開する11万枚超の胸部X線画像を題材に、画像とテキストを共通のEmbeddingへ変換し、PostgreSQLとpgvectorで類似検索するローカルRAGを紹介します。検索精度を上げる為、肺野を左右・上下の部位に分け、部位別のベクトルデータを Citusを使って15台のWorkerへ負荷分散しました。システム構成や処理フローを解説します。

▲

【T1】実例で学ぶ！AIエディタを活用したPostgreSQL内部実装の読み解き方～ソースコードレベルでPostgreSQLを理解するエンジニアになる！～

NTT OSS センタ
石井愛弓

PostgreSQLのトラブルシューティングでは、「ソースコードに答えがある」ケースが少なくありません。AIの登場によりコードリーディングは飛躍的に効率化されましたが、一方でAIの回答を鵜呑みにすると誤った結論に至る危険もあります。本講演では、AIを「答えを聞くツール」ではなく「正しい理解へ導くナビゲータ」として活用し、PostgreSQLの内部実装を読み解く具体的な手法を実例を交えて解説します。

▲

【T2】オプティマイザ統計解説

日本ヒューレット・パッカード合同会社
篠田典良

SQL文の実行計画を作成するために参照される情報がオプティマイザ統計です。オプティマイザ統計の実体はテーブルやインデックスに格納されるデータのサマリー情報であり、パフォーマンス・チューニングでは重要な意味を持ちます。本講演ではオプティマイザ統計の基本的な構造と、取得方法、パーティションテーブルにおける例外やサンプリング量の計算等の内部構造、チューニング時の注意点等を説明します。

▲

【T3】事例で学ぶVacuumの可観測性

株式会社NTTデータ
加藤慎也

「autovacuumは有効にしているのに、テーブルの肥大化が止まらない」。Vacuumに関するトラブルは、同じように見える症状でも原因はさまざまです。しかし原因を調べようとすると、手がかりはサーバログ、稼働統計情報、pg_stat_progress_vacuumのような進捗レポートなどに散らばっており、どの場面でどれを見ればよいか迷いがちです。

本講演では、Vacuumに関する各情報源から何が分かるのかを整理したうえで、「Vacuumは毎日走っているのにdead tupleが減らない」、「特定のテーブルだけいつまでもVacuumされない」といった実際のトラブル事例をもとに、原因を切り分けるために確認すべき情報とその読み解き方を解説します。PostgreSQL 19で追加された新機能が事例のどこで役立つのかも取り上げ、依然として不足している可観測性についてはPostgreSQL 20に向けたコミュニティでの議論を紹介します。

▲

【T4】PostGISの上流から下流まで～現代の地図アプリケーション開発の勘所

株式会社MIERUNE
井口奏大

地図アプリケーションのバックエンドとしてPostGISをどう使うか、上流から下流まで一本の流れで解説します。拡張の有効化、GDAL/QGISでのデータ投入・加工、空間インデックスを効かせた空間クエリ、そして地図タイル配信まで。あわせて、事前生成した静的タイルなど他の手段とも比較しながら、PostGISを選定すべき場面を整理します。GIS未経験でも、DB選定時にGEOMETRYの扱いを判断材料にできる状態を目指します。

▲