> "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 年も継続しています。

| カテゴリ | 伝統的 1 位 | Postgres + 拡張の代替 |

|---|---|---|

| ベクター DB | Pinecone, Weaviate, Qdrant | pgvector + pgvectorscale |

| 時系列 DB | InfluxDB, Prometheus | TimescaleDB |

| 地理情報 DB | Oracle Spatial, Esri SDE | PostGIS + pgRouting |

| 全文検索 | Elasticsearch, OpenSearch | pg_trgm + tsvector + ParadeDB |

| カラムナ / OLAP | ClickHouse, DuckDB | Hydra Columnar + pg_mooncake |

| グラフ DB | Neo4j, ArangoDB | Apache AGE (Postgres 拡張) |

| キュー / イベントバス | Kafka, RabbitMQ | pgmq (Tembo) + NOTIFY/LISTEN |

| キャッシュ | Redis, Memcached | UNLOGGED テーブル + ParadeDB Search |

| 分散 SQL | CockroachDB, Spanner | Citus, pgEdge |

この表が言いたいのは「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 月時点の推奨は、驚くほどシンプルです。

| 状況 | 推奨 |

|---|---|

| 新規プロジェクト — どの DB を使う？ | まずは **Postgres** ✓ |

| 小規模 SaaS — Supabase / Neon / RDS / Tembo / Crunchy のどれ？ | フルスタックは Supabase、ブランチングが必要なら Neon、拡張の自由度が必要なら Tembo / Crunchy |

| ベクター検索 — Pinecone vs pgvector？ | 1 億ベクター以下 + 既存 Postgres あり → **pgvectorscale** |

| 時系列 — InfluxDB vs TimescaleDB？ | SQL で問題なければ → **TimescaleDB** (ほぼ常に) |

| 地理情報 — Esri vs PostGIS？ | OSS で十分 → **PostGIS**、政府 / 防衛認定が必要 → Esri |

| 分散 SQL — CockroachDB vs Citus？ | マルチテナント SaaS → **Citus**、真のグローバル → CockroachDB / Spanner |

| カラムナ OLAP — ClickHouse vs Hydra？ | TB 以下で同じ DB に置きたい → **Hydra / pg_mooncake**、PB 規模 → ClickHouse |

| K8s 上の運用 — operator は？ | **CloudNativePG** か Zalando Postgres Operator |

| バックアップ — どのツール？ | まずは **pgBackRest**、シンプルさ重視なら WAL-G |

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/`