※本ページには広告（アフィリエイトプログラム等）が含まれます。
※本ページには広告（アフィリエイトプログラム等）が含まれます。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 421MariaDB が 75.2MB、使える余力は 421MB。ここに PostgreSQL を足すと、同程度の常駐がもう 1 つ乗ると見積もっておくのが安全です。さらに HNSW インデックスを使うならその上にメモリが必要になります。
判断の順番
| 状況 | 現実的な選択 |
|---|---|
| すでに PostgreSQL を使っている | pgvector を足すだけ。最も自然 |
| MariaDB のみ・メモリ 1GB 前後 | ⚠️ 2 つ目の DB は重い。別サーバーか外部サービスを検討 |
| ベクトル数が数万件以下 | DB を建てず、ファイル + 総当たりでも足りることがある |
| Web サーバーと分離できる | 専用の箱に置くのがいちばん素直 |
pgvector の仕様
次元数の上限
公式に明記されている数値です。インデックスを張れるのは 2,000 次元まで、格納だけなら 16,000 次元まで。
⚠️ この差が実務では効きます。3,072 次元の埋め込みは「保存はできるがインデックスは張れない」ことになり、件数が増えると検索が実用的でなくなります。埋め込みモデルを選ぶ段階で 2,000 次元以下に収まるかを確認してください。
距離演算子
| 演算子 | 距離 |
|---|---|
<-> |
L2 距離（ユークリッド） |
<=> |
コサイン距離 |
<#> |
内積の符号反転 |
<+> |
L1 距離（マンハッタン） |
<~> |
ハミング距離（バイナリベクトル） |
<%> |
ジャッカード距離（バイナリベクトル） |
文書検索で使うのはたいてい <=>（コサイン距離）です。インデックスは演算子ごとに作るので、使う演算子を決めてから張ってください。
インデックスの選択
| 観点 | HNSW | IVFFlat |
|---|---|---|
| 検索性能 | 高い | 劣る |
| 構築時間 | 遅い | 速い |
| メモリ使用量 | 多い | 少ない |
| 空テーブルへの作成 | 可能 | ⛔ 不可（先にデータが必要） |
公式の説明どおり、HNSW は速度と再現率のトレードオフで有利だが、構築が遅くメモリを食う。小さい VPS では IVFFlat から試すのが無難です。
⚠️ IVFFlat は「データを入れてから」作ります。空のテーブルに作ってもリストの学習ができず、意図した性能になりません。ここは順番を間違えやすいところです。
埋め込みをどう作るか
3 つの選択肢
| 方法 | コスト構造 | 注意点 |
|---|---|---|
| 外部の埋め込み API | トークン単位 | データが外に出る |
ローカル（Ollama の /v1/embeddings） |
GPU の起動時間 | ⛔ 一般的な VPS では動かない |
| 軽量モデルを CPU で回す | CPU 時間 | 速度と精度が落ちる |
ローカルは GPU が要る
Ollama は /v1/embeddings を OpenAI 互換で提供していますが、動かすには GPU が必要です。手元の VPS で確認すると GPU デバイスは存在しませんでした。
$ nvidia-smi
bash: nvidia-smi: command not foundGPU を借りる場合の価格感はこちらの記事にまとめています（さくらの高火力 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 のコスト最適化、メモリが足りないときはスワップの追加にまとめています。
