pgvector が本格化 ── RDB に AI のベクトル検索を載せる

2023年5月、 PostgreSQL の拡張機能 pgvector が一気に主流になった。 同月 3 日、 AWS が Amazon RDS for PostgreSQL での pgvector サポート を発表。 Azure、 Supabase、 Google Cloud SQL も相次いで対応し、 主要マネージド PostgreSQL のほぼすべてが pgvector を公式機能として取り扱う体制が、 数週間で完成した。

ChatGPT 公開（2022 年 11 月） から半年。 LLM 時代の 「ベクトル DB は専用品か、 PostgreSQL の拡張か」 という業界論争に、 pgvector は明確な解答を示し始めた。

ベクトル DB とは何か ── RAG 時代の必須インフラ

LLM はテキストを embedding（埋め込み） と呼ばれる高次元ベクトル（典型的には 768〜3072 次元の浮動小数点配列） に変換できる。 例えば OpenAI の text-embedding-3-small モデルは 1536 次元、 text-embedding-3-large は 3072 次元。 意味的に近いテキストは、 高次元空間で近い座標にマッピングされる。

LLM アプリケーション、 特に RAG（Retrieval-Augmented Generation） では、 こうした embedding を大量に保存し、 ユーザの質問を embedding 化してから「近いベクトル」を検索する。 検索した文書を LLM のプロンプトに含めることで、 LLM の知識の範囲外にある最新情報・社内文書・専門知識を回答に反映できる。

ここで必要なのが 近傍検索（Approximate Nearest Neighbor、 ANN） ── 数百万〜数十億のベクトルから、 クエリベクトルに最も近いものを高速に取り出す技術である。 距離関数は コサイン類似度、 L2 距離（ユークリッド）、 内積 の三種が標準。 ANN アルゴリズムとしては HNSW（Hierarchical Navigable Small World） と IVFFlat（Inverted File with Flat lists） が主流。

pgvector の起源 ── 2021 年、 Andrew Kane

pgvector は 2021 年 4 月、 カナダのエンジニア Andrew Kane が GitHub に公開した PostgreSQL 拡張である。 Kane は Ruby on Rails コミュニティで有名な OSS 作者で、 機械学習関連の Ruby ライブラリ群を整備してきた人物。

公開当初の pgvector は素朴な実装で、 全件スキャン（IVFFlat なし、 HNSW なし） を行う「Flat インデックス」のみ ── つまり 10 万件程度までしか実用にならない小規模ツールだった。 2022 年に IVFFlat が追加され、 数百万件規模が現実的になる。

潮目が完全に変わったのは 2023 年 11 月、 pgvector 0.5.0 で HNSW が実装 された時である。 HNSW はベクトル DB のデファクト アルゴリズムで、 Pinecone・Weaviate・Milvus・Qdrant など主要な専用ベクトル DB のすべてが採用している。 これを pgvector が取り込んだことで、 性能面で専用品との差が大きく縮まった。

2023 年の業界状況 ── 専用 vs 拡張

ChatGPT のショック以降、 ベクトル DB の市場は急成長した。 専用ベクトル DB として：

• Pinecone（2019 年-、 マネージド SaaS のみ） ── 2023 年 4 月に評価額 7.5 億ドルで資金調達。 「RAG = Pinecone」のイメージを作った先駆者。
• Weaviate（2019 年-、 OSS + マネージド） ── オランダ発、 GraphQL ベース API、 ハイブリッド検索が強み。
• Milvus（2019 年-、 LF AI & Data 寄贈、 Zilliz が商用化） ── 中国発、 大規模ベクトル処理に強い。
• Qdrant（2021 年-、 Rust 製、 OSS + クラウド） ── ベルリン発、 速度重視の新興。
• Chroma（2022 年-、 OSS） ── 開発者体験重視、 LangChain との連携。

これら専用ベクトル DB に対し、 pgvector は「追加のシステムを増やしたくない」という運用ニーズを直撃した。 アプリケーションが既に PostgreSQL を使っているなら、 ベクトル検索のためだけに別の DB を運用するのは負担。 トランザクションも結合クエリも一貫した型システムも、 PostgreSQL 内で完結する方が楽 ── この実務的な判断が、 pgvector を急速に押し上げた。

2023 年 5 月の連鎖採用 ── マネージド PostgreSQL の合意

2023 年 5 月 3 日、 AWS が Amazon RDS for PostgreSQL での pgvector 公式サポート を発表。 これが連鎖の起点となった。

• 2023 年 5 月: AWS RDS for PostgreSQL
• 2023 年 5 月: Supabase（事実上の標準サポート、 ホームページで「Vector Embeddings」を主力機能として打ち出し）
• 2023 年 5 月-6 月: Microsoft Azure Database for PostgreSQL の preview
• 2023 年 7 月: Google Cloud SQL for PostgreSQL
• 2023 年 10 月: AWS Aurora PostgreSQL（HNSW を含む新バージョン対応）
• 2024 年: Neon、 PlanetScale、 CockroachDB（PostgreSQL 互換系の OLTP 各社） も次々と追加

「マネージド PostgreSQL を使うなら、 ベクトル検索のためにわざわざ別の DB を契約する必要はない」 ── これが 2023 年後半の業界の合意事項となった。

「データベースに AI 機能を載せる」というアプローチ

pgvector の成功は、 単なる一拡張の話を超えて、 「既存の RDB に AI 機能を追加する」というアーキテクチャ選択肢 を確立した。 これは「AI のために新しい DB を作る」という Pinecone 型のアプローチと対立する。

同じ流れで、 2024 年以降は以下のような動きが続く ── MySQL も VECTOR 型を 9.0 で追加（2024 年）、 SQL Server は VECTOR データ型と DiskANN サポートを 2024 年発表、 Oracle Database 23ai は「AI Vector Search」を主力機能の一つに据える、 Snowflake は Cortex Search でベクトル検索を SQL から呼べる ── すべての主要 DBMS が「自分のところでベクトル検索ができる」状態に向かいつつある。

それでも Pinecone・Weaviate などの専用品が消えるわけではない。 数十億規模のベクトル、 多テナント分離、 特殊な距離関数、 GPU アクセラレーションなどの要件では専用品が優位を保つ。 とはいえ「ふつうの RAG アプリケーション」の大多数は、 PostgreSQL + pgvector で十分という結論に落ち着きつつある。

2023 年 5 月が意味するもの

pgvector の本格化は、 LLM の波が既存のデータ基盤を作り変えた最初の具体例 である。 ChatGPT 公開後、 業界は「AI 専用の新しいインフラを構築するのか、 既存のインフラを拡張するのか」という選択に直面した。 pgvector はその選択に対して「拡張で十分対応できる」という答えを、 ベクトル DB という具体的な領域で示した。

そして PostgreSQL は、 1996 年の 6.0 リリース以来「拡張可能性」を中核に据えてきた設計が、 AI 時代に強烈なアドバンテージとなって返ってきた ── という稀有な事例でもある。 Stonebraker が Berkeley Postgres でユーザ定義型システムを設計したのは 1986 年。 その 37 年後、 LLM 時代の標準データ型としてベクトルが PostgreSQL に追加された。 「拡張可能性に賭けた DB は、 知らない未来にも対応できる」 ── pgvector はその実例である。