クラウドキャリアフリーランス
技術記事 2026/7/6

本番RAGのベクトルストアをどう選ぶか — S3 Vectors / OpenSearch Serverless / pgvector をコスト×性能×運用×スケールで判断する

本番RAGのベクトルストアは S3 Vectors / OpenSearch Serverless / pgvector の3択です。違いの本質は機能でなくコスト構造（クエリ従量か容量課金かDB内包か）と運用・スケールの収まりにあります。規模・クエリ頻度・運用体制・連携の4軸から判断木で選ぶ考え方を整理します。額は2026年6月時点の参考値で、構成全体の費用試算は関連記事へ送ります。

  • #RAG
  • #AWS
  • #ベクトルストア
  • #S3 Vectors
  • #OpenSearch Serverless
  • #pgvector
  • #Bedrock Knowledge Bases
  • #ベクトルDB

Amazon S3 Vectors が一般提供（GA）で1クエリあたり最大1万件まで返せるようになり、大規模なベクトル検索の現実的な選択肢に育ちました。ただ、本番のRAG（検索拡張生成）を設計するうえで効いてくるのは「どの新機能が出たか」よりも、「自分のワークロードでどのベクトルストアを選べば後悔しないか」です。本記事は、本番RAGのベクトルストアを Amazon S3 Vectors / Amazon OpenSearch Serverless / pgvector（Aurora/RDS PostgreSQL）の3択として捉え、コスト構造・性能・運用・スケールの観点から判断木で選び分ける考え方を整理します。対象は本番RAGを設計・運用する実務者で、各サービスの基礎説明は最小限にとどめます。なお料金・上限値は2026年6月時点の参考値であり、変動するため適用前に公式の最新情報をあわせてご確認ください。

ベクトルストアに「1つの正解」はない

2026-06-17、AWS はフルマネージド RAG の Amazon Bedrock Managed Knowledge Base を一般提供開始しました（東京を含む8リージョン対応）。ベクトルストアを自分で選定・運用せず委ねる選択肢が広がっています。本記事の比較は「自前でベクトルストアを持つ場合」の判断であり、運用を委ねたい・低スイッチングコストで始めたい場合は Managed Knowledge Base（既存 Knowledge Bases と同一 API・KB ID の差し替えのみでコード変更なしに移行可）も有力な候補になります。コスト最適化やスケール特性、特殊な検索要件を自分で握りたい場合に、以下の選定軸へ進むとよいでしょう。

ベクトルストアの選定でつまずくのは、「いちばん速いものはどれか」「いちばん安いものはどれか」という単一軸で順位を付けようとするときです。検索のレイテンシ、保存できる規模、クエリ頻度に対する課金の効き方、既存システムとの統合のしやすさは、サービスごとにトレードオフの形が異なります。あるワークロードで最適な選択が、別のワークロードでは過剰にも不足にもなります。

そのため、選定は「最強を1つ選ぶ」問題ではなく、ワークロード特性に当てはめる問題になります。判断材料になる軸は、おおまかに次の4つです。データの規模、クエリの頻度とレイテンシ要件、運用体制（専用基盤を増やせるか、既存DBに寄せたいか）、そしてコスト感です。以降では、まず3択の素性を横並びで確認し、違いの本質であるコスト構造を掘り下げたうえで、要件から3択へ振り分ける判断木に落とします。

3つの選択肢の素性 — S3 Vectors / OpenSearch Serverless / pgvector を横並びで

最初に、3択がそれぞれどういう素性のサービスかを並べて把握します。スケール上限・次元数・メタデータ・運用形態を一覧にすると、得意な領域の輪郭が見えてきます。

観点S3 VectorsOpenSearch Serverless（ベクトル検索）pgvector（Aurora/RDS PostgreSQL）
位置づけベクトルをネイティブ保存するオブジェクトストレージk-NN検索のマネージドサーバレス既存PostgreSQLに載せるin-DB拡張
スケール上限1インデックス最大20億・1バケット最大20兆ベクトル1インデックス最大1 TiBDBインスタンス／Aurora容量に依存
次元1〜4096最大16,000拡張・インデックス設定に依存
検索方式近傍検索（フィルタ可能メタデータで絞り込み）k-NN（ユークリッド／コサイン／内積）HNSW／IVFFlat
メタデータ1ベクトル最大50キー（うち最大10キーを非フィルタ指定可）数値・真偽・日付・keyword・geopoint・text を同居可テーブルの列として自由に同居
運用形態サーバレス（運用軽）マネージド（OCUで容量管理）DB運用に内包
主な連携Bedrock Knowledge Bases のベクトルストアに選択可Bedrock KB／LangChain等に選択可アプリ・既存DBと統合

S3 Vectors は桁外れのスケール上限とサーバレスの運用の軽さが持ち味です。OpenSearch Serverless は次元数の上限が広く、k-NN による検索の柔軟性があります。pgvector は専用のベクタ基盤を増やさず、既存のPostgreSQLにベクトル列として相乗りできる点が特徴です。なお、レイテンシやスループット（QPS）の定量的な優劣は、3者を同条件で並べた公式の横並び値が存在しないため、本記事では断定せず、用途特性として扱います。

コスト構造の違い — クエリ従量 vs OCU容量課金 vs DB内包

3択を分ける最大のポイントは、機能差ではなく「何に対して課金されるか」というコスト構造の違いです。ここが選定の核になります。

S3 Vectorsはクエリ従量、OpenSearch ServerlessはOCU容量課金（NextGenはアイドル0・Classicは常駐下限）、pgvectorはDB内包という3択のコスト構造を横並びで示した図
図1: ベクトルストア3択のコスト構造マップ（何に課金されるか）

S3 Vectors はクエリ従量型です。ストレージ単価が安く、検索のたびに課金が発生します。課金はアップロード時のPUT、論理ストレージ、そしてクエリの3つに分かれ、クエリはAPI呼び出し（参考値で $2.50/100万クエリ）に加えて、処理データ量に応じた料金とデータ返却（参考値で $0.01/GB）で構成されます。処理データ量の単価は規模が大きいほど逓減し、先頭10万ベクトルが $0.004/TB、10万〜1000万で $0.002/TB、1000万超で $0.0004/TB という形です。非フィルタに指定したメタデータはクエリの処理サイズ計算から除外されます。クエリ頻度が低〜中程度であれば、検索のたびに課金される構造でも総額を抑えやすくなります。

OpenSearch Serverless はOCU容量課金型です。確保した計算容量（OCU＝OpenSearch Compute Unit、6 GiBメモリ相当）の時間に対して課金され、インデックス処理（indexing）と検索（search）でOCUを別々に確保します。従来この方式は「クエリが少なくてもOCUが常駐して課金が積み上がる」点が弱点でした。ここが新しいコレクション形態（NextGen）で変わっています。NextGenのベクトルコレクションは、10分間アイドルが続くと indexing・search ともに0 OCUまで縮退し、最低OCUの常時課金が発生しません。これにより、低頻度クエリでの常時課金という弱点が縮小し、S3 Vectors との差が縮まっています。一方、従来型（Classic）のコレクションは冗長（Multi-AZ standby）を有効にすると最低2 OCUが常駐します。参考値（2026年6月時点・us-east-1）で $0.24/OCU-hour とすると、2 OCUの常駐はクエリが0でも概算で月 $350 級になります。東京リージョンのOCU単価は us-east-1 とは異なるため、料金ページで必ず確認してください。

pgvector はDB内包型です。ベクトル検索のための独立した課金項目はなく、コストは既存のDBインスタンス費（Aurora/RDS）に内包されます。専用のベクタ基盤を別建てしない分、課金の見通しはDBのサイジングに集約されます。

このように、同じ「ベクトルを検索する」用途でも、クエリ従量・容量課金・DB内包という3つの異なる課金の形があります。どれが有利かはクエリ頻度・データ量・常駐の要否で変わるため、額の優劣を一律に比較するのではなく、自分のワークロードがどの課金構造と相性が良いかで考えるのが実務的です。なお、各サービスを組み合わせたRAG構成全体の費用試算は本記事の範囲を超えるため、構成全体のTCOは関連記事に譲ります。

選定の判断木 — 要件からどれに寄せるか

コスト構造を理解したうえで、要件から3択へ振り分けます。順序立てて分岐させると、迷いどころが整理できます。

規模・クエリ頻度・レイテンシ・運用体制・連携の各軸からS3 Vectors・OpenSearch Serverless・pgvectorの3択へ振り分ける判断木を示した図
図2: ベクトルストア選定の判断木（要件からどれに寄せるか）

第一に規模です。インデックスが数十億・数兆ベクトルに達するような大規模で、かつクエリが低〜中頻度であれば、スケール上限が桁違いに大きく、クエリ従量で常時課金を避けられる S3 Vectors が寄せ先になります。1クエリで最大1万件を返せるようになったことで、大規模な検索の現実性も上がりました。

第二にクエリ頻度・レイテンシです。リアルタイムに近い応答や高いQPS、低レイテンシが要件で、k-NNによる柔軟な検索や高い次元数が必要であれば、OpenSearch Serverless が寄せ先です。NextGenを選べば、アイドル時の常時課金を抑えつつ容量課金型のメリットを取れます。

第三に運用体制と連携です。すでにPostgreSQLを運用しており、ベクトル検索を既存DBに統合してトランザクションと同居させたい、専用のベクタ基盤を増やしたくない、という事情があれば pgvector が寄せ先になります。規模・性能はDBインスタンスに依存するため、超大規模・高QPSの専用用途ではマネージドの専用エンジンに分があります（公式の横並び数値はないため、ここは定性的な傾向として扱います）。

判断木はあくまで「寄せ先の当たりを付ける」ためのもので、最終的には次節の連携要件やコスト構造との突き合わせで確定します。

Bedrock Knowledge Bases とどうつなぐか

RAGを Amazon Bedrock Knowledge Bases（KB）で組む場合、ベクトルストアの選択は連携のしやすさにも左右されます。S3 Vectors と OpenSearch Serverless は、いずれも Bedrock KB のベクトルストアとして選択できます。

KBを前提に新規で組むなら、サーバレスで運用が軽く、KBのベクトルストアとして素直に使える S3 Vectors が出発点になりやすい構成です。一方、すでに OpenSearch の資産や運用ノウハウがあるなら、それを再利用して OpenSearch Serverless に寄せる判断も合理的です。pgvector は Bedrock KB の標準的なベクトルストア選択肢とは位置づけが異なり、アプリケーション側でPostgreSQLと統合してRAGを組む構成に向きます。連携の前提（KBを使うか、アプリ側で組むか）を先に決めると、3択の絞り込みが進みます。

本番で気をつける落とし穴

選定の最後に、本番運用で踏みやすい点を確認します。

  • レイテンシ・QPSの定量比較は公式の横並び値がない: 3者を同条件で比較した公式値は存在しません。ベンチマークは条件依存になるため、「用途特性で選ぶ」という定性判断にとどめ、断定的な優劣付けは避けるのが安全です。
  • コスト額は変動する: 本記事の金額はいずれも2026年6月時点の参考値です。適用前に公式のpricingページで最新値を確認し、東京リージョンのOCU単価は us-east-1 とは異なる点に注意してください。
  • NextGenのアイドル0 OCUはコールドスタートに注意: 「アイドル10分で0 OCUへ縮退」は、低頻度でも常時課金が積み上がりにくくなったという趣旨で捉えます。縮退状態からの再ウォームではコールドスタートの体感が生じうるため、レイテンシ要件が厳しい用途では挙動を事前に確認します。
  • OpenSearch Serverlessのコレクション型は作成後に変更できない: ベクトル検索には vector search 型のコレクションが必要で、作成後に型は変えられません。最初の作成時に用途に合った型を選びます。

まとめ — 選定チェックリスト（4軸）

本番RAGのベクトルストアは「1つの正解」を探す問題ではなく、ワークロード特性に当てはめる問題です。最後に、4軸のチェックリストで3択を選び分けます。

判断軸S3 VectorsOpenSearch Serverlesspgvector（Aurora/RDS）
規模大規模（数十億〜数兆）に強い1インデックス最大1 TiB級DBインスタンス容量に依存
クエリ頻度・レイテンシ低〜中頻度・コスト優先高QPS・低レイテンシ・k-NN中規模・既存DBの応答性に依存
運用体制サーバレスで運用軽マネージド（NextGenで省力）既存DB運用に統合
連携Bedrock KB前提なら素直既存OpenSearch資産を再利用アプリ・PostgreSQLと統合

要点は3つです。第一に、違いの本質は機能ではなくコスト構造（クエリ従量／OCU容量課金／DB内包）にあります。第二に、OpenSearch Serverless の NextGen はアイドルで0 OCUへ縮退するため、低頻度での常時課金という従来の弱点が縮小しています。第三に、規模・クエリ頻度/レイテンシ・運用体制・連携の4軸で寄せ先を決め、額は時点を明記した参考値として扱います。ベクトルストア単体ではなく構成全体の費用試算が必要な場合は、RAG構成のTCOを扱う関連記事を、選定そのものの言語化には意思決定の型を扱う関連記事をあわせてご参照ください。S3 Vectors の機能詳細はAmazon S3 Vectors の解説記事で補足しています。

出典

For Freelancers

AWSフリーランス案件、お探しですか？

案件探しから単価交渉・契約手続き・参画後のフォローまで、専任コンサルタントが伴走します。 お名前とメールだけで、まずは無料でご相談いただけます。

案件を探す