VPSでRAG（検索拡張生成）を自作する：pgvector + Embeddingでドキュメント検索

※本ページには広告（アフィリエイトプログラム等）が含まれます。pgvector の仕様は 2026年8月16日時点の公式リポジトリの記載、サーバーの出力は同日に運用中の VPS（Debian 12・メモリ 958MB）から採取した実測値です。

本当のコストは pgvector ではなく「2 つ目の DB を建てること」

pgvector 自体は PostgreSQL の拡張なので、導入そのものは難しくありません。効いてくるのは、Web サイト用の VPS にはたいてい PostgreSQL が入っていないという点です。

手元の環境を確認したところ、PostgreSQL は未導入で、MariaDB が 75.2MB を使いながら動いていました。空きメモリは 421MB。ここに 2 つ目の DB エンジンを常駐させる判断になります。

• pgvector は PostgreSQL 13 以降に対応しています。拡張として入れます
• インデックスは 2,000 次元まで。格納だけなら 16,000 次元までです
• HNSW はメモリを食うので、小さい VPS では IVFFlat から検討してください
• IVFFlat はデータを入れてから作ります。空テーブルに作っても効きません
• 既存の MariaDB とは別に常駐するので、メモリの見積もりを先にやってください

RAG の全体の流れ

3 つの工程に分かれる

やることは ①文書を分割して埋め込みベクトルにする → ②ベクトルを DB に入れる → ③質問文のベクトルで近いものを引く の 3 つです。pgvector が担当するのは ②と③だけで、①は別に用意する必要があります。

pgvector が解くのは「近傍検索」だけ

誤解しやすいのがここです。pgvector はベクトルを保存して近いものを高速に引くための拡張であって、埋め込みそのものは作りません。埋め込みの生成手段は自分で決めます。

既存の DB に相乗りできない

pgvector は PostgreSQL の拡張です。MySQL / MariaDB では使えません。すでに MariaDB でサイトを運用している環境に入れる場合、DB エンジンがもう 1 つ増えることになります。

VPS に置くときの本当のコスト

PostgreSQL は入っていない

Web サーバー用途の VPS で確認するとこうなります。

$ which psql postgres
（何も表示されない）

$ systemctl is-active postgresql
inactive

すでに動いている DB のメモリ

$ systemctl show mariadb -p MemoryCurrent --value
（約 75.2 MB）

$ free -m
               total        used        free      shared  buff/cache   available
Mem:             958         537          87          60         562         421

MariaDB が 75.2MB、使える余力は 421MB。ここに PostgreSQL を足すと、同程度の常駐がもう 1 つ乗ると見積もっておくのが安全です。さらに HNSW インデックスを使うならその上にメモリが必要になります。

判断の順番

pgvector の仕様

次元数の上限

公式に明記されている数値です。インデックスを張れるのは 2,000 次元まで、格納だけなら 16,000 次元までです。

この差が実務では効きます。3,072 次元の埋め込みは保存はできるがインデックスは張れないことになり、件数が増えると検索が実用的でなくなります。埋め込みモデルを選ぶ段階で 2,000 次元以下に収まるかを確認してください。

距離演算子

文書検索で使うのはたいてい <=>（コサイン距離）です。インデックスは演算子ごとに作るので、使う演算子を決めてから張ってください。

インデックスの選択

公式の説明どおり、HNSW は速度と再現率のトレードオフで有利ですが、構築が遅くメモリを食います。小さい VPS では IVFFlat から試すのが無難です。

IVFFlat はデータを入れてから作ります。空のテーブルに作ってもリストの学習ができず、意図した性能になりません。ここは順番を間違えやすいところです。

埋め込みをどう作るか

3 つの選択肢

ローカルは GPU が要る

Ollama は /v1/embeddings を OpenAI 互換で提供していますが、動かすには GPU が必要です。手元の VPS で確認すると GPU デバイスは存在しませんでした。

$ nvidia-smi
bash: nvidia-smi: command not found

GPU を借りる場合の価格感はこちらの記事にまとめています（さくらの高火力 DOK で V100 が 1 時間 57.6 円）。埋め込みの生成は初回にまとめて走るバッチ処理なので、秒課金の GPU とは相性が良い部類です。

次元数は最初に決める

後から埋め込みモデルを変えると、すべてのベクトルを作り直すことになります。前述のインデックス上限（2,000 次元）も含めて、最初に決めておくのが結果的にいちばん安く済みます。

専用のベクトル DB と比べる

pgvector が有利な場面

すでに PostgreSQL を運用しているなら、ほぼ pgvector 一択です。既存のテーブルと JOIN できる、トランザクションが効く、バックアップの仕組みを流用できる——運用上の利点がそのまま乗ります。

専用 DB が有利な場面

ベクトルが数千万件を超える規模や、分散が前提の構成では専用のベクトル DB が向きます。ただしそこに至る前に、まず pgvector で足りるかを確かめるほうが早いです。

そもそも DB が要らない場合もある

ベクトルが数千件程度なら、ファイルに置いて総当たりで計算しても実用的な速度が出ます。DB を建てる判断は、件数が増えて困ってからで遅くありません。

よくある質問

Q1. pgvector は MySQL や MariaDB でも使えますか？

使えません。PostgreSQL の拡張です。対応バージョンは PostgreSQL 13 以降。すでに MariaDB でサイトを運用している環境なら、DB エンジンをもう 1 つ常駐させる判断になります。

Q2. メモリ 1GB の VPS で動きますか？

厳しいです。手元の環境は MariaDB が 75.2MB を使い、空きは 421MB でした。ここに PostgreSQL を足すと同程度の常駐がもう 1 つ乗り、さらに HNSW インデックスのメモリが必要になります。Web サーバーと分離できるなら、そのほうが確実です。

Q3. 次元数の上限はいくつですか？

インデックスを張れるのは 2,000 次元まで、格納だけなら 16,000 次元までです。3,072 次元の埋め込みは保存できてもインデックスが張れないため、件数が増えると検索が実用的でなくなります。埋め込みモデルを選ぶ段階で確認してください。

Q4. HNSW と IVFFlat はどちらを選ぶべきですか？

メモリに余裕がなければ IVFFlat から試してください。HNSW は検索性能で有利ですが、構築が遅くメモリを多く使います。IVFFlat はデータを入れてから作る必要がある点に注意してください（空テーブルに作っても効きません）。

Q5. 文書検索ではどの距離を使いますか？

多くの場合コサイン距離（<=>）です。インデックスは演算子ごとに作るので、使う距離を決めてからインデックスを張ってください。後から変えるとインデックスを作り直すことになります。

Q6. 埋め込みはローカルで作れますか？

GPU があれば作れます。Ollama は /v1/embeddings を OpenAI 互換で提供していますが、一般的な VPS には GPU が無いため動きません（手元の環境でも nvidia-smi は未インストールでした）。埋め込みの生成は初回にまとめて走るバッチ処理なので、秒課金の GPU と相性が良い部類です。

まとめ

pgvector の導入で本当に効いてくるのは、拡張の入れ方ではなく、2 つ目の DB エンジンを常駐させられるかという一点です。

すでに PostgreSQL があるなら迷わず pgvector で構いません。MariaDB のみで 1GB の VPS なら分離を検討してください（MariaDB 75.2MB / 空き 421MB）。設計で最初に決めるのは次元数（2,000 以下）と距離演算子です。

仕様は変わります。この記事の数値は 2026年8月16日時点のもので、サーバーの出力は同日に採取したものです。GPU の価格感は画像生成を VPS でやる話、API 費用はLLM API のコスト最適化、メモリが足りないときはスワップの追加にまとめています。