モダン PostgreSQL 2026 — Postgres 17 / 18 / pgvector / pgvectorscale / pgai / TimescaleDB / PostGIS / Citus 徹底ガイド

"PostgreSQL is the world's most advanced open source relational database — and in 2026, it is quietly becoming the world's most advanced open source vector database, time-series database, geospatial database, and search engine, too." — Andrew Kane (pgvector author), PGConf NYC 2024

PostgreSQL は 1986 年の UC Berkeley「POSTGRES」プロジェクトに端を発する、もうすぐ 40 歳のデータベースです。それでも 2026 年 5 月のコミュニティでは「過去 5 年は、それまでの 30 年より大きな変化があった」とよく語られます。pgvector が OpenAI・Anthropic 系 RAG の事実上の標準になり、TimescaleDB が時系列市場を吸収し、PostGIS がほぼすべての GIS スタックのデフォルトになり、Supabase・Neon が「Postgres as a Service」を再定義した結果、PostgreSQL は「リレーショナル DB の一つ」ではなく 一つのプラットフォーム になりました。

本稿では Postgres 17 (2024.9)・Postgres 18 (2025.9) のコア機能、pgvector → pgvectorscale → pgvector.rs → pgai と続くベクター拡張の進化、TimescaleDB・PostGIS・pgRouting といったドメイン拡張、PgBouncer・Pgpool-II によるコネクションプーリング、Citus・Hydra・Tembo・Crunchy Data などの分散/クラウド選択肢、そして pgmustard・Postgres.ai の AI 支援運用ツールまで、まとめて整理します。

1. 2026 年の Postgres — あらゆる DB の代替

2026 年 5 月時点で、PostgreSQL はほぼすべてのデータベース カテゴリにおいて「十分良い」選択肢になっています。DB-Engines Ranking では 2023 年に初めて MySQL を抜き、2024 年の Stack Overflow Developer Survey でも 49.0% の採用率で 1 位に立ち、その流れは 2025 年と 2026 年も継続しています。

この表が言いたいのは「Postgres が全カテゴリの 1 位」ではなく、「5 つの DB を運用する代わりに、1 つの Postgres で 80% の要件を満たせる」ということです。Stripe・Notion・Linear・Vercel・Cloudflare が自社のメイン DB を Postgres に据えて公言している理由でもあります。

PostgreSQL Global Development Group (PGDG) は毎年 9 月に 1 つのメジャー リリースを出し、5 年間のセキュリティ パッチを提供します。2026 年 5 月時点でアクティブにサポートされているのは 14・15・16・17・18 の 5 系統で、13 は 2025 年 11 月に EOL を迎えました。

2. Postgres 17 (2024.9) — Incremental Backup / MERGE / JSON_TABLE

PostgreSQL 17 は 2024 年 9 月 26 日にリリースされました。ユーザから見て最も目立つ 3 つの強化は incremental backup / MERGE 改善 / JSON_TABLE です。

Incremental Backup: pg_basebackup --incremental=manifest_path の形で、前回のフル バックアップ以降に変更されたページのみをバックアップできるようになりました。これまでは pgBackRest や WAL-G のような外部ツールに頼る必要があった機能が、ようやくコアに入ったわけです。TB クラスの DB で日次バックアップ時間が 8 時間から 30 分に短縮されたという報告が複数公開されています。

# フル バックアップ
pg_basebackup -D /backup/full --manifest-checksums=SHA256

# インクリメンタル (前日の manifest を参照)
pg_basebackup -D /backup/incr-2026-05-16 \
  --incremental=/backup/full/backup_manifest

# 復元: pg_combinebackup でフル + インクリメンタルをマージ
pg_combinebackup /backup/full /backup/incr-2026-05-16 -o /restore

MERGE 改善: SQL 2003 標準で 15 から導入された MERGE に、17 では RETURNING 句 と WHEN NOT MATCHED BY SOURCE が追加されました。UPSERT パターンがよりすっきり書け、特にデータ同期や CDC の適用に有用です。

MERGE INTO orders_summary t
USING new_orders s ON t.order_id = s.order_id
WHEN MATCHED THEN UPDATE SET total = s.total
WHEN NOT MATCHED BY TARGET THEN INSERT VALUES (s.order_id, s.total)
WHEN NOT MATCHED BY SOURCE THEN DELETE
RETURNING merge_action(), t.order_id;

JSON_TABLE: SQL/JSON 標準の JSON_TABLE 関数が追加され、JSONB カラムをリレーショナル テーブルのように扱えるようになりました。

SELECT jt.*
FROM events e,
  JSON_TABLE(e.payload, '$.items[*]' COLUMNS (
    sku TEXT PATH '$.sku',
    qty INT  PATH '$.qty',
    price NUMERIC(10,2) PATH '$.price'
  )) jt;

この他に、VACUUM のメモリ使用量を約 20 分の 1 に削減、streaming I/O インターフェース、identity column の OVERRIDING 追加、pg_stat_statements の query_id 正規化改善 などが入りました。Postgres 17 の全体テーマは「性能と運用性の強化」です。

3. Postgres 18 (2025.9) — Virtual Generated Columns / OAuth2

PostgreSQL 18 は 2025 年 9 月 25 日にリリースされました。大きな変更は virtual generated columns と OAuth2 認証 の二つです。

Virtual Generated Columns: これまで generated column は STORED (ディスクに永続化) のみでしたが、18 から VIRTUAL (クエリ時計算) オプションが追加されました。ストレージを消費せずに計算済みカラムをインデックス・ビュー・クエリで使えます。

CREATE TABLE products (
  id BIGSERIAL PRIMARY KEY,
  price_cents INT NOT NULL,
  vat_rate NUMERIC(5,2) NOT NULL DEFAULT 10.0,
  price_with_vat NUMERIC(12,2)
    GENERATED ALWAYS AS (price_cents * (1 + vat_rate/100) / 100) VIRTUAL
);

CREATE INDEX idx_products_price_with_vat ON products(price_with_vat);

OAuth2 / OIDC 認証: 18 から pg_hba.conf で oauth 認証メソッドがサポートされました。Auth0・Okta・Azure AD・Google Workspace などの IdP が発行する JWT で直接 Postgres にログインできます。従来は PgBouncer・CloudNativePG・Crunchy などの外部レイヤが必要でした。

# pg_hba.conf (Postgres 18)
host all all 0.0.0.0/0 oauth issuer="https://auth.example.com" \
  scope="postgres" validator="example_validator"

加えて 非同期 I/O (io_uring ベース、シーケンシャル スキャン・VACUUM の高速化)、B-tree の skip scan (複合インデックスの先頭カラムをスキップ)、UUID v7 サポート、論理レプリケーションでのシーケンス複製、部分的な temporal table 構文、pg_stat_io 列の追加 などが盛り込まれました。18 は 17 以上に「性能寄り」のリリースで、特に SSD/NVMe 環境で io_uring の効果が大きく出ます。

4. pgvector — もっともホットな拡張

pgvector は Andrew Kane が 2021 年に作った拡張で、Postgres に vector データ型・距離演算子 (L2, inner product, cosine)・HNSW / IVFFlat インデックス を追加します。2023 年の OpenAI embeddings API の爆発と RAG パターンの標準化と相まって、pgvector は事実上「Postgres でベクターを扱う標準」になりました。

2026 年 5 月時点の最新版は 0.8.x で、AWS RDS・GCP Cloud SQL・Azure Database for PostgreSQL・Supabase・Neon・Crunchy Bridge のすべてで標準提供されています。

CREATE EXTENSION vector;

CREATE TABLE documents (
  id BIGSERIAL PRIMARY KEY,
  content TEXT NOT NULL,
  embedding vector(1536)  -- OpenAI text-embedding-3-small
);

-- HNSW インデックス (PG 16+, pgvector 0.5+)
CREATE INDEX ON documents
  USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

-- top-K 類似度検索
SELECT id, content, embedding <=> '[0.1, 0.2, ...]'::vector AS distance
FROM documents
ORDER BY embedding <=> '[0.1, 0.2, ...]'::vector
LIMIT 10;

pgvector のインデックス選択肢:

• IVFFlat (Inverted File with Flat compression): データを K クラスタに分け、クエリ時に近いクラスタのみをスキャン。構築は速いが、データ更新が多いと再構築が必要。
• HNSW (Hierarchical Navigable Small World): グラフ ベース インデックス。構築は遅いが動的更新に対応し、一般に再現率が高い。2026 年時点のデフォルト選択肢は HNSW。

pgvector の限界は インデックスがメモリに収まらないと性能が出ない ことです。1 億ベクター (1536 次元 float32) は約 600 GB に達し、単一ノードの RAM を簡単に超えます。この問題を解決するために登場したのが次章の pgvectorscale です。

5. pgvectorscale (Timescale, 2024.4) — ディスクベースのベクター インデックス

Timescale は 2024 年 4 月に pgvectorscale を PostgreSQL License で OSS 公開しました。中核は StreamingDiskANN インデックス — Microsoft Research の DiskANN アルゴリズムを Postgres に移植したもの — と Statistical Binary Quantization (SBQ) です。

DiskANN はインデックスの大半をディスクに置きつつ、SSD への 1 回の read で KNN を解く設計です。Timescale のローンチ時のベンチマークでは、単一の m6i.2xlarge (8 vCPU, 32 GB RAM) で 1 億ベクター・再現率 95%・p95 50 ms を達成したと公表しています。同じワークロードを Pinecone は約 8x s1.x4 pod (約 $1,200/月) で処理するのに対し、pgvectorscale は同一 VM ($230/月程度) で処理できる、という比較が大きな話題になりました。

CREATE EXTENSION vectorscale CASCADE;

CREATE TABLE documents (
  id BIGSERIAL PRIMARY KEY,
  embedding vector(1536)
);

-- StreamingDiskANN インデックス (ディスクベース)
CREATE INDEX ON documents
  USING diskann (embedding vector_cosine_ops)
  WITH (storage_layout = 'memory_optimized', num_neighbors = 50);

-- 検索は pgvector と同じ演算子
SELECT id, embedding <=> $1::vector AS dist
FROM documents
ORDER BY embedding <=> $1::vector
LIMIT 10;

pgvectorscale の本質は「ディスク使用量が少ない」ことではなく、「分散システムを立てずに単一の Postgres でベクター インデックスを運用できる」点にあります。1 億〜10 億ベクター規模を 1 ノードで扱えるようになり、「Pinecone / Weaviate を別途運用する」パターンは急速に減りつつあります。

同カテゴリには lantern (Lantern Cloud) や VectorChord (旧 pgvecto.rs CNPG fork) があり、いずれも「Postgres 内のディスク ベース ベクター インデックス」というビジョンを共有しています。

6. pgvector.rs / pgai — Rust 実装と DB 内埋め込み

pgvector.rs (VectorChord): TensorChord チームが開発した Rust ベースの pgvector 互換拡張です。本家 pgvector が C 実装で単一バックエンド プロセス内で動作するのに対し、pgvector.rs は Rust と pgrx フレームワークで書かれ、より安全で高速なインデックス構築を目指します。2025 年末に VectorChord にリブランドされ、MIT ライセンスで提供されています。

VectorChord の目玉は独自の rabbit hole アルゴリズム — IVF の変種で、構築速度が pgvector HNSW の 5〜10 倍速いと発表されています。毎日数億ベクターを再インデックスする RAG パイプラインに向きます。

CREATE EXTENSION vchord CASCADE;

CREATE INDEX ON documents
  USING vchordrq (embedding vector_l2_ops)
  WITH (options = $$
    residual_quantization = true
    [build.internal]
    lists = []
    spherical_centroids = false
  $$);

pgai (Timescale): pgai は「Postgres の中で埋め込み生成から LLM 呼び出しまで」をまとめる拡張です。2024 年に登場し、2025 年には pgai Vectorizer という大規模ワークフロー ツールへ拡張されました。

-- SQL から OpenAI 埋め込みを直接呼び出す
SELECT ai.openai_embed(
  'text-embedding-3-small',
  'PostgreSQL is the world''s most advanced open source database'
);

-- 自動ベクター化
SELECT ai.create_vectorizer(
  'public.blog_posts'::regclass,
  destination => 'blog_embeddings',
  embedding => ai.embedding_openai('text-embedding-3-small', 1536),
  chunking => ai.chunking_recursive_character_text_splitter('content'),
  scheduling => ai.scheduling_timescaledb()
);

pgai の発想は「データを DB から出して埋め込んで戻すための ETL パイプライン自体を消す」というもの。Anthropic Claude・OpenAI・Cohere・Ollama・Voyage AI・HuggingFace をサポートし、埋め込みは継続的に同期されます。

pgvectorscale と pgai が組み合わさると、「RAG インフラ全体を Postgres の中に置く」というビジョンが現実に動きます。Timescale は 2024〜2025 年でこのメッセージを最も強く押し出している会社です。

7. TimescaleDB — 時系列 + AI ops

TimescaleDB は 2017 年に Timescale Inc. が作った時系列拡張で、中核となる抽象化は ハイパーテーブル (hypertable) という自動パーティショニングです。見た目は通常のテーブルですが、時間や空間に基づいて自動的にチャンク分割され、チャンク単位で圧縮・削除・ロールアップが行われます。

CREATE EXTENSION timescaledb;

CREATE TABLE metrics (
  time TIMESTAMPTZ NOT NULL,
  device_id TEXT NOT NULL,
  cpu DOUBLE PRECISION,
  mem DOUBLE PRECISION
);

SELECT create_hypertable('metrics', 'time', chunk_time_interval => INTERVAL '1 day');

-- カラムナ圧縮
ALTER TABLE metrics SET (
  timescaledb.compress,
  timescaledb.compress_segmentby = 'device_id'
);

SELECT add_compression_policy('metrics', INTERVAL '7 days');

-- 連続集計 (continuous aggregate)
CREATE MATERIALIZED VIEW metrics_hourly
WITH (timescaledb.continuous) AS
SELECT time_bucket('1 hour', time) AS hour,
       device_id,
       avg(cpu) AS avg_cpu
FROM metrics
GROUP BY hour, device_id;

TimescaleDB の魅力は、時系列特化の機能を Postgres SQL でそのまま使えることです。time_bucket, first, last, lag, gap fill といった関数や、2024 年に導入された hypercore (圧縮+行のハイブリッド ストレージ) によって、InfluxDB や Prometheus と直接張り合えます。

2024〜2025 年に Timescale は会社全体を「Postgres + AI ops」へとリポジショニングし、TimescaleDB・pgvector・pgvectorscale・pgai の 4 拡張を束ねて Timescale Cloud として提供しています。日本では楽天・ANA、韓国では SK テレコム・カカオモビリティが事例を公開しています。

ライセンスはコアが Apache 2.0、高機能部分が Timescale License (非 AWS SaaS 利用に制限) と二層構造で、AWS RDS で使うには Timescale Cloud 経由となります。

8. PostGIS / pgRouting — 地理情報

PostGIS は 2001 年に Refractions Research が作った地理情報拡張で、Postgres に GEOMETRY / GEOGRAPHY 型と 3000 を超える空間関数を追加します。2026 年 5 月時点の最新版は 3.5.x で、OpenStreetMap・Esri・MapBox・Google Maps の一部バックエンドも PostGIS 上で動いています。

CREATE EXTENSION postgis;

CREATE TABLE places (
  id BIGSERIAL PRIMARY KEY,
  name TEXT,
  location GEOGRAPHY(POINT, 4326)
);

CREATE INDEX places_location_idx ON places USING GIST(location);

-- 半径 500m 以内を検索
SELECT name, ST_Distance(location, my_point) AS dist
FROM places, (SELECT ST_MakePoint(139.7, 35.7)::geography AS my_point) p
WHERE ST_DWithin(location, my_point, 500)
ORDER BY dist
LIMIT 20;

PostGIS は単なる座標格納ではなく、空間結合、Voronoi、Convex Hull、isochrone、空間クラスタリング (DBSCAN, K-Means)、ラスタ処理、3D メッシュ といった高度な機能をすべて SQL から提供します。不動産・物流・観光・自動運転・気象産業の事実上すべてのデータ基盤です。

pgRouting は PostGIS 上で動作する拡張で、Dijkstra, A*, TSP (巡回セールスマン), bidirectional A*, Yen's K-shortest path といったグラフ アルゴリズムを SQL で提供します。OpenStreetMap データをそのまま取り込んでルーティング サービスを構築できます。

-- OSRM 不要で SQL から最短経路
SELECT * FROM pgr_dijkstra(
  'SELECT id, source, target, cost FROM ways',
  start_node_id, end_node_id, directed => true
);

2024 年から MobilityDB (時空間オブジェクト) と H3-pg (Uber の H3 hex grid インデックス) が PostGIS エコシステムに合流し、「空間 + 時間 + ベクター」の統合分析が 1 つの DB で可能になりました。日本では JR 東日本の運行分析、韓国ではカカオモビリティ・TMAP・クーパン フルフィルメントで活用されています。

9. PgBouncer / Pgpool-II — コネクション プーリング

Postgres はプロセス モデルなので、コネクション 1 本あたり数十 MB のメモリを消費します。Web/API サーバから数千の短いコネクションが押し寄せると Postgres は膝をつくため、ほぼすべての本番 Postgres の前段には PgBouncer か Pgpool-II が置かれます。

PgBouncer は 2007 年に Skype が作った軽量プーラで、単一プロセスのイベント ループで数万のクライアント コネクションを少数の Postgres サーバ コネクションにマップします。プーリング モードは 3 つ:

• session pooling: クライアント セッションの間、同じバックエンドを保持 (デフォルト)
• transaction pooling: トランザクション中だけバックエンドを保持し、終了で返却 (もっとも一般的)
• statement pooling: ステートメント単位で返却 (制限多数)

# pgbouncer.ini
[databases]
mydb = host=postgres.local port=5432 dbname=mydb

[pgbouncer]
listen_port = 6432
pool_mode = transaction
max_client_conn = 10000
default_pool_size = 100
reserve_pool_size = 5

Pgpool-II は PgBouncer より重く、機能も豊富です。プーリング + ロード バランシング + 自動フェイルオーバ + クエリ キャッシュ + パラレル クエリ を提供します。ただし transaction pooling では prepared statement の互換性に難があり、純粋なプーリングなら PgBouncer、HA とルーティングまでまとめたいときは Pgpool-II という棲み分けです。

2024〜2025 年に pgcat (Rust 製、PgBouncer 互換) と Supavisor (Supabase の Elixir 製プーラ、ディスク I/O 分離) が登場しました。pgcat はシャーディングとロード バランシングを一プロセスに統合し、Supavisor は Postgres 18 の OAuth2 を活用したマルチテナント プーリングを実現します。

コネクション プーリングは表面的にはインフラの細部に見えますが、Postgres 運用事故の 60% 以上はプーリング設定ミスから始まる、と言われるほど重要です。

10. Citus / Hydra — シャーディング / カラムナ

Citus は 2016 年に Citus Data が作り、2019 年に Microsoft が買収した分散 Postgres 拡張です。テーブルを複数のワーカ ノードへ自動でシャーディングし、coordinator がクエリをルーティングします。Azure Cosmos DB for PostgreSQL のバックエンドも Citus です。

CREATE EXTENSION citus;

-- ワーカ ノードの登録
SELECT * FROM master_add_node('worker-1', 5432);
SELECT * FROM master_add_node('worker-2', 5432);

-- テーブルをシャード (distribution column 指定)
SELECT create_distributed_table('orders', 'customer_id');

-- 参照テーブル (全ワーカに複製)
SELECT create_reference_table('countries');

Citus は単純な read スケールアウトに留まらず、分散トランザクション、分散 JOIN、分散 Postgres 機能 までを提供します。ただしクロス シャード JOIN の性能は distribution column 設計に大きく依存するため、「Citus が本当に光るのはマルチテナント SaaS」というのが定説です。

2024 年は Citus が 11.x → 12.x → 13.x へと素早く進み、13 では論理レプリケーション ベースのゼロ ダウンタイム シャード リバランスが入りました。2024 年後半に Microsoft が Citus チーム要員を削減した、という報道があり、コミュニティは Hydra Postgres, pgEdge, Spock (pgEdge のマルチマスタ複製) などの代替に注目しています。

Hydra は Postgres に カラムナ ストレージ を追加する拡張です。DuckDB のストレージ エンジンを Postgres に統合した形で、分析ワークロードでは行ストレージより 10〜100 倍速いクエリを示します。

CREATE EXTENSION columnar;

CREATE TABLE events_columnar (
  time TIMESTAMPTZ, user_id BIGINT, event_type TEXT, payload JSONB
) USING columnar;

近接プロジェクトには pg_mooncake (Iceberg ベースの lakehouse Postgres)、pg_lakehouse (ParadeDB)、pg_analytics (Hydra の後継プロジェクト) があり、2025〜2026 年の大きな流れは「OLTP は行ストレージ、OLAP は同じ Postgres のカラムナ テーブル」です。

11. Tembo / Crunchy Data — Postgres クラウド

Tembo は 2023 年にローンチした Postgres 専用クラウドで、「Postgres + 拡張マーケット」を中心メッセージにしています。pgvector・pgvectorscale・pgmq・PostGIS・Hydra Columnar・pg_partman・pg_cron をはじめとする 200 を超える拡張がワン クリックで有効化でき、ワークロード別の事前設定された 「Stack」 (VectorDB Stack, Time-series Stack, OLTP Stack, OLAP Stack) も用意されています。

Tembo の差別化要素は 拡張の信頼性 です。すべての拡張を自動ビルド & テストするレジストリ Trunk (pgt.dev/trunk) を運営し、ABI 互換性・ライセンス・CVE をトラッキングしています。AWS RDS や GCP Cloud SQL が新しい拡張を追加するのに半年〜2 年かかるのとは対照的です。

Crunchy Data は 2012 年から Postgres に注力する会社で、Crunchy Bridge (AWS / Azure / GCP のマネージド Postgres)、Crunchy Postgres for Kubernetes (PGO operator)、Crunchy Postgres for VMware が主力です。政府・金融などコンプライアンス要件が強い市場が主軸で、FedRAMP・HIPAA・PCI-DSS の取得済み Postgres SaaS としては最も歴史があります。

2024 年から Crunchy は CloudNativePG (EDB と共同開発の K8s operator) に大きく投資し、Kubernetes 上で Postgres を運用するデファクト operator になりました。Crunchy Data Warehouse (2025 年提供開始) は Iceberg + Parquet + Postgres を束ねる lakehouse 製品で、Hydra・pg_mooncake と同じカテゴリで競合します。

比較すると — Supabase はフルスタック BaaS、Neon はサーバーレス Postgres + ブランチング、Tembo は拡張中心の PaaS、Crunchy Bridge はエンタープライズ コンプライアンス、AWS RDS / Aurora はクラウド統合。1 社が全部を同時に使うことは少ないですが、ワークロード別に異なる Postgres ホスティングを使う構成はもう一般的です。

12. pglogical / pg_partman / pg_cron / pg_repack / pg_stat_statements — 運用拡張

ここまでが「機能追加」中心の拡張だったとすれば、本章は「運用自動化」中心の 5 拡張です。

pg_stat_statements: Postgres 12 から contrib として同梱されており、事実上すべての本番 Postgres で有効化されている拡張です。クエリ別の呼び出し回数・総時間・平均時間・一時ファイル使用量を集計し、「遅いクエリ TOP 20」を SQL 一発で出せます。

CREATE EXTENSION pg_stat_statements;

SELECT query, calls, mean_exec_time, total_exec_time, rows
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;

pg_partman: 時間や数値範囲でテーブルを 自動パーティショニング する拡張です。Postgres コアは declarative partitioning を備えていますが、パーティションの作成 / 削除自動化は自前スクリプトが必要で、pg_partman はこれを cron 一行に縮約します。

SELECT partman.create_parent(
  p_parent_table => 'public.events',
  p_control => 'created_at',
  p_interval => '1 day',
  p_premake => 7,
  p_start_partition => '2026-05-01'
);

-- pg_cron と組み合わせる
SELECT cron.schedule('partition-maintenance', '0 3 * * *',
  $$ SELECT partman.run_maintenance(p_analyze => true) $$);

pg_cron: PostgreSQL 内で cron ジョブを実行する拡張です。Citus チームが作成し、AWS RDS・GCP Cloud SQL・Azure・Tembo・Supabase・Neon で標準提供されています。VACUUM、REINDEX、パーティション整理、マテビュー リフレッシュを OS の cron なしで DB 内にスケジュール可能です。

pg_repack: 本番テーブルの bloat 除去 とインデックス再構築を ロック なし で行う拡張です。VACUUM FULL はテーブル全体に ACCESS EXCLUSIVE ロックをかけますが、pg_repack は一時テーブルへの複製 + トリガによる同期 + 短いスワップで処理します。本番 DB のディスク回収には不可欠です。

pglogical: Postgres の論理レプリケーションをより柔軟にする拡張です。コアの論理レプリケーションは同一バージョン間でのみ動きますが、pglogical は 9.4 → 16 のような大規模バージョン ジャンプ、双方向レプリケーション、列フィルタリングをサポートします。大規模 Postgres 移行 (ブルー / グリーン) の事実上の標準です。

5 拡張に共通するのは「運用担当が自前で書いていたスクリプトを DB に押し込む」ことで、韓国・日本の大規模 Postgres 運用チームでは、ほぼ常にこの 5 つがセット運用されています。

13. pgmustard / Postgres.ai — クエリ プラン + AI

pgmustard は英国の 2 人の開発者 (Michael Christofides、Nikolay Samokhvalov) が作った EXPLAIN ANALYZE 可視化ツールです。Postgres の EXPLAIN ANALYZE 出力は読みづらさで有名ですが、pgmustard はこれを視覚化し、「どのノードが遅いか」「なぜ遅いか」「どう直すか」を自然言語で示します。

# psql で JSON 形式の EXPLAIN を取得
EXPLAIN (ANALYZE, FORMAT JSON, BUFFERS) SELECT ...;

# pgmustard に貼り付け (または CLI 経由)
pgmustard plan.json

2024 年から pgmustard は インデックス提案 (欠けているインデックスのリコメンド)、書き換え提案 (クエリ リファクタ)、bloat 検出 といった自動診断を追加しました。SQL に自信のない開発者でも EXPLAIN の結果に基づいて行動できることが価値の中心です。

Postgres.ai は Nikolay Samokhvalov の会社で、主力は DB Lab (非本番のシン クローン) と Postgres AI Bot です。DB Lab は ZFS/LVM スナップショットを用いて TB クラスの DB を秒単位で複製し、開発者が自分の PR を本番相当データで検証できるようにします。

Postgres AI Bot は 2024 年追加の LLM ベース アシスタントで、「このクエリをどう高速化するか」「このインデックスは使われているか」「このロックはなぜ取られているか」といった質問に EXPLAIN + pg_stat_statements + pg_locks を自動取得して答えます。SRE の一次トリアージを自動化するのが狙いです。

近接カテゴリには Tigerdata Insights (Timescale)、Datadog Database Monitoring、PgAnalyze (最も歴史の長い Postgres APM) があり、2025〜2026 年の大きな流れは「DBA 1 名を LLM が補佐する」です。

14. バックアップ — pgBackRest / Barman / WAL-G / pg_dump

Postgres のバックアップは 物理 (データ ディレクトリ + WAL) と 論理 (SQL ダンプ) の 2 系統に分かれます。両者は用途がほとんど重なりません。

pg_dump / pg_dumpall: 公式付属ツールで、SQL あるいはカスタム形式でデータを出力します。小規模 DB (数十 GB 程度)、マイグレーション、テスト用フィクスチャ、アーカイブに適しています。メジャー バージョン ジャンプ時にもっとも安全な方法です。

# 並列ダンプ (custom format, jobs=8)
pg_dump -Fd -j 8 -f /backup/mydb.dir mydb

# 復元
pg_restore -d mydb_new -j 8 /backup/mydb.dir

pgBackRest: 最も成熟した物理バックアップ ツールで、2026 年 5 月時点では事実上の標準です。フル + インクリメンタル + 差分バックアップ、S3 / GCS / Azure Blob への直接アップロード、並列圧縮 / 暗号化、PITR (point-in-time recovery)、保存時暗号化、delta restore をすべて備えています。

# pgbackrest.conf
[global]
repo1-path=/var/lib/pgbackrest
repo1-type=s3
repo1-s3-bucket=mybackups
repo1-s3-region=ap-northeast-1
repo1-retention-full=4

[mydb]
pg1-path=/var/lib/postgresql/17/data

# フル バックアップ
pgbackrest --stanza=mydb backup --type=full

# PITR 復元
pgbackrest --stanza=mydb restore --target="2026-05-16 12:00:00" --type=time

Barman: イタリアの 2ndQuadrant (現 EDB) が作ったツールで、pgBackRest より歴史が長く、テレコム / 金融のような保守的市場で広く使われます。Streaming WAL receiver、rsync ベース、多サーバ管理が強みです。

WAL-G: Citus Data が作った Go 実装のツールで、S3 親和性 + 設定の簡潔さ が強みです。delta バックアップ、暗号化、圧縮をサポートし、AWS / GCP / Azure / Yandex など複数のバックエンドに対応します。

# WAL-G の基本プッシュ
WALG_S3_PREFIX=s3://mybackups/mydb wal-g backup-push /var/lib/postgresql/17/data

# 復元
wal-g backup-fetch /restore LATEST

3 ツールとも WAL アーカイブ (archive_command) を前提に動くため、「バックアップはあるが PITR が動かない」事故を避けるには archive_command の設定と archive_status のモニタリングが最重要です。

最後に pgexporter は Prometheus 用の Postgres メトリクス エクスポータで、バックアップと組み合わせて運用可観測性を担います。Grafana ダッシュボードと合わせて、バックアップ成功率・WAL ラグ・archive ラグ・接続数を 1 画面で見る運用が定番です。

15. 韓国 / 日本 — Toss、カカオ、NAVER、メルカリ、NTT

韓国 — Toss: Toss はおよそ 2020 年から、コア取引システムの一部を Oracle から Postgres に移行し始めました。2024 年に Toss Payments エンジニアリング ブログが「10 TB Postgres + Citus 上のマルチテナント SaaS」の運用事例を公開しています。中核取引 DB は Postgres 16 で、pgBackRest + Patroni + PgBouncer + pg_partman + pg_cron 構成で運用されており、pgvector は推奨・検索などの周辺サービスで活用されています。

韓国 — カカオ: 2022 年の SCC 火災を機にカカオは DB マルチリージョン戦略を抜本的に見直し、メッセージング / ペイの一部ワークロードを Postgres + Citus に移しました。2025 年の if(kakao) では Postgres 17 と CloudNativePG と pgvector を束ねた社内 PaaS「Kakao DB Platform」が公開されました。

韓国 — NAVER: NAVER のクローバ・検索・ショッピング基盤では Postgres + pgvector + pgvectorscale が RAG / レコメンド / 検索に積極利用されています。2024〜2025 年の NAVER D2 ブログでは「社内 LLM プラットフォームが Postgres ベース」とする記事が複数公開されています。

日本 — メルカリ: メルカリはマイクロサービスごとに異なる DB を使いつつ、決済・アカウント・在庫の相当部分が Postgres on Cloud SQL に乗っています。2024 年に Mercari Engineering Blog が pgvector ベースの商品レコメンドを公開し、2025 年には pgvectorscale への移行事例も発表されました。

日本 — NTT (Fujii Masao, Amit Langote): PostgreSQL Global Development Group の主要コミッタのうち 2 名が NTT グループ出身です。Fujii Masao (NTT OSS センタ) は streaming replication・pg_basebackup・pg_rewind の主要作者であり、Amit Langote (EDB、元 NTT) は declarative partitioning と JSON_TABLE のキー コントリビュータです。日本は NTT・SRA OSS・富士通が PostgreSQL コア開発に最も多くの人員を投じている国であり、これは 2007 年に NTT が「PostgreSQL を日本の基幹 DB へ」という戦略を打ち出したことに起源があります。

韓国 — PgKR / PostgreSQL Korea User Group: 韓国 PostgreSQL ユーザ会 (PgKR) は毎年 PgDay を開催し、2025 年には Coupang・LINE+・Hyundai AutoEver の Postgres 事例が発表されました。2026 年は 9 月開催予定です。

16. 誰が Postgres を選ぶべきか — ほぼすべての場合 ✓

2026 年 5 月時点の推奨は、驚くほどシンプルです。

Postgres が向かないケースもあります — (1) 超低レイテンシ KV (Redis / DragonflyDB)、(2) グローバルな強整合性 (Spanner)、(3) PB 規模のカラムナ分析 (ClickHouse / Snowflake)、(4) 深さ 10 以上のグラフ トラバーサル (Neo4j)、(5) 全文検索のランキングを深く調整したいケース (Elasticsearch)。この 5 つを除けば、ほぼあらゆる状況で Postgres を第一候補にしても大きな後悔はありません。

最後に — 「Postgres の拡張は強力だが、ホスティングのアロウ リスト (AWS RDS / Cloud SQL / Azure) は必ず先に確認すること」。拡張の自由度が最も高いのは Tembo・Crunchy Bridge・Supabase・Neon・自前運用 (K8s + CloudNativePG) で、RDS は約 50 個ほどに限られます。拡張依存の重いワークロードでは、ホスティング選びがそのまま拡張選びになります。

17. 参考文献 / References

• PostgreSQL 17 release notes — https://www.postgresql.org/docs/17/release-17.html
• PostgreSQL 18 release notes — https://www.postgresql.org/docs/18/release-18.html
• PostgreSQL versioning policy — https://www.postgresql.org/support/versioning/
• pgvector GitHub — https://github.com/pgvector/pgvector
• pgvectorscale GitHub — https://github.com/timescale/pgvectorscale
• pgvectorscale launch blog — https://www.timescale.com/blog/pgvector-is-now-as-fast-as-pinecone-at-75-less-cost/
• pgvector.rs / VectorChord — https://github.com/tensorchord/VectorChord
• pgai (Timescale) — https://github.com/timescale/pgai
• TimescaleDB docs — https://docs.timescale.com/
• PostGIS docs — https://postgis.net/docs/
• pgRouting — https://pgrouting.org/
• H3-pg — https://github.com/zachasme/h3-pg
• PgBouncer — https://www.pgbouncer.org/
• Pgpool-II — https://www.pgpool.net/
• pgcat — https://github.com/postgresml/pgcat
• Supavisor — https://github.com/supabase/supavisor
• Citus Data — https://github.com/citusdata/citus
• Hydra Postgres — https://github.com/hydradatabase/hydra
• pg_mooncake — https://github.com/Mooncake-Labs/pg_mooncake
• Tembo — https://tembo.io/
• Trunk extension registry — https://pgt.dev/
• Crunchy Data — https://www.crunchydata.com/
• CloudNativePG — https://cloudnative-pg.io/
• Crunchy Postgres for Kubernetes (PGO) — https://github.com/CrunchyData/postgres-operator
• pg_stat_statements — https://www.postgresql.org/docs/current/pgstatstatements.html
• pg_partman — https://github.com/pgpartman/pg_partman
• pg_cron — https://github.com/citusdata/pg_cron
• pg_repack — https://github.com/reorg/pg_repack
• pglogical — https://github.com/2ndQuadrant/pglogical
• pgmustard — https://www.pgmustard.com/
• Postgres.ai — https://postgres.ai/
• pgBackRest — https://pgbackrest.org/
• Barman — https://pgbarman.org/
• WAL-G — https://github.com/wal-g/wal-g
• pgexporter — https://pgexporter.github.io/
• Apache AGE (graph) — https://age.apache.org/
• pgmq (Tembo) — https://github.com/tembo-io/pgmq
• DB-Engines Ranking — https://db-engines.com/en/ranking
• Stack Overflow Developer Survey 2024 — https://survey.stackoverflow.co/2024/technology
• Andrew Kane PGConf NYC 2024 talk — https://www.youtube.com/@PostgresConf
• Mercari Engineering Blog — https://engineering.mercari.com/en/blog/
• Toss Tech Blog — https://toss.tech/
• カカオ if(kakao) — https://if.kakao.com/
• NAVER D2 — https://d2.naver.com/
• PgKR / PostgreSQL Korea — https://postgresql.kr/
• Fujii Masao (NTT) — https://www.postgresql.org/community/contributors/
• Amit Langote (EDB, 元 NTT) — https://www.postgresql.org/community/contributors/