PostgreSQL

PostgreSQL とは

PostgreSQL は、カリフォルニア大学バークレー校で書かれた POSTGRES を源流とするオープンソースの RDBMS で、SQL 標準への高い準拠度と豊富な拡張機能が特徴である。1996 年に Postgres95 から現在の名称へ改称し、あわせてバージョン番号を 6.0 から振り直した。2026 年 8 月時点でサポート対象は 14 から 18 までの 5 系列で、最新のマイナーリリースは同年 8 月 13 日に公開された 18.6 である。メジャーバージョンは年 1 回のペースで公開され、各系列は初回リリースから 5 年間サポートされる。Amazon Aurora PostgreSQL 互換エディションや RDS for PostgreSQL として AWS でも広く使われている。

PostgreSQL の強み

拡張機構と検索機能の幅が PostgreSQL の中心的な価値で、標準 SQL の外側にある要件を追加モジュールで吸収できる。インデックスも既定の B-tree だけでなく、全文検索や jsonb の包含判定に効く GIN、範囲や幾何データ向けの GiST、物理的な並び順と値の順序がそろった巨大テーブルを小さな索引で絞り込む BRIN を用途に応じて選べる。主な特徴は次の 6 点である。

特徴	説明
拡張性	カスタム型、関数、インデックス、拡張モジュールを追加可能
JSON サポート	jsonb 型でドキュメント DB 的な使い方も可能
全文検索	tsvector / tsquery による転置索引。日本語は標準のパーサーが単語を切り出せないため pg_bigm や PGroonga などの拡張を併用する
ベクトル検索	pgvector 拡張で埋め込みベクトルの類似検索
パーティショニング	宣言的パーティショニングで大規模テーブルを分割
レプリケーション	ストリーミングレプリケーションで読み取りをスケールし、論理レプリケーションではテーブル単位の配信もできる

MySQL との比較

同じオープンソースの RDBMS でも、SQL 標準への追従度と同時実行制御の実装が両者で大きく異なる。設計判断に直結する 6 観点で並べる。

観点	PostgreSQL	MySQL
SQL 準拠	高い (Window 関数、CTE、LATERAL)	中程度 (8.0 で改善)
JSON	jsonb (バイナリ、インデックス可)	JSON 型
拡張性	拡張モジュール (PostGIS, pgvector)	プラグイン (限定的)
MVCC	追記型 (VACUUM が必要)	undo ログ型
デフォルト分離レベル	Read Committed	Repeatable Read
AWS サービス	Aurora PostgreSQL, RDS	Aurora MySQL, RDS

PostgreSQL は複雑なクエリや拡張機能が必要な場合に強く、MySQL はシンプルな読み取り中心のワークロードで高速。

Aurora PostgreSQL

Aurora PostgreSQL 互換エディションは、PostgreSQL のエンジンを AWS の分散ストレージ層に載せ替えたサービスである。AWS は 2026 年 8 月時点の公式ドキュメントで、SysBench のような標準ベンチマークにおいて同等ハードウェア上の PostgreSQL に対し最大 6 倍のスループットが観測されたと説明している。差が開くのは同時接続数の多い高並列のワークロードで、ストレージ層への書き込み増幅と I/O のボトルネックを抑える構造が効くためであり、単一接続の単純なクエリでは差はほとんど出ない。

• ストレージは 3 つのアベイラビリティーゾーンに各 2 コピー、合計 6 コピーを自動で保持
• 読み取り用のレプリカは 1 クラスターあたり最大 15 台 (プライマリと合わせて最大 16 インスタンス)。レプリカはプライマリと同じクラスターボリュームを共有するため、複製のためのデータコピーが発生しない
• Serverless v2 でオートスケーリング
• PITR (ポイントインタイムリカバリ) で任意の時点に復元

pgvector と RAG

pgvector 拡張を使えば、PostgreSQL をベクトル DB として利用できる。Aurora PostgreSQL も pgvector をサポートしており、既存の RDB に埋め込みベクトルを格納して RAG の検索基盤にできる。

CREATE EXTENSION vector;
CREATE TABLE documents (
  id serial PRIMARY KEY,
  content text,
  embedding vector(1536)  -- 1536 次元のベクトル
);

-- 類似検索 (コサイン距離)
SELECT content
FROM documents
ORDER BY embedding <=> '[0.1, 0.2, ...]'::vector
LIMIT 5;

Amazon OpenSearch Serverless のようなベクトル検索に特化したサービスと比べると、既存の PostgreSQL の運用・バックアップ・権限設計をそのまま流用でき、業務データと埋め込みベクトルを同じトランザクションで更新できる点が利点になる。反面、インデックス構築時のメモリ消費や再インデックスの負荷は自分で見る必要がある。

よくある落とし穴

• VACUUM の放置: PostgreSQL の MVCC は行を上書きしない。更新は新しいバージョンの行を書き足し、古い行に不可視の印を付けるだけなので、削除でも領域は即座には空かない。この不要行を回収するのが VACUUM で、放置するとテーブルとインデックスが肥大化し、統計情報も古びて実行プランが劣化する。更新の多いテーブルでは autovacuum の発動しきい値を既定より下げて追随させる
• コネクション枯渇: PostgreSQL はプロセスベースで、接続ごとにプロセスを生成する。Lambda のような大量同時接続には RDS Proxy を併用する

関連書籍も参考になる。