この記事で分かること／分からないこと
- 分かること: ベクトル件数が増えたとき、どの資源が先に上限になるか(公式ドキュメントで確認できた範囲)
- 分かること: 索引の種類(HNSW / IVFFlat)によって、規模に対する振る舞いがどう違うか
- 分からないこと: 自社のデータで何件まで1台で持てるか(次元数・メモリ量・索引パラメータで変わるため一般化できない)
- 分からないこと: 各サービスの具体的な上限値(公式の上限一覧は種類別のページに分かれており、本稿では個々の数値を転記していない)
編集部の自社RAG基盤は、有界ドメインのため索引による確定配信で足りており、ベクトルDBを使っていない(出所: /home/sol/convai-platform/docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。したがって本稿は自社の実測ではなく、各サービスの公式ドキュメントで確認できた性質の整理である。自社の構成を推奨として書いているわけではない点は、そもそもベクトルDBが要らない場合で述べたとおりである。
規模で先に詰まるのは検索速度ではなくメモリ
直感的には「件数が増えると検索が遅くなる」と思いがちだが、公式ドキュメントが最初に挙げるのはメモリである。Weaviateの資源計画のページは、メモリがサポートできるデータセットの最大サイズを決めること、そしてメモリはクエリ速度に直接は影響しないことを明記している。必要なメモリ量はデータセットのサイズに直結し、データセットのサイズと現在のクエリ負荷には相関がない、とも書かれている(出所: https://weaviate.io/developers/weaviate/concepts/resources 、確認日2026-09-06)。
つまり、件数が増えたときに最初に効いてくるのは「載るか載らないか」であって、「速いか遅いか」ではない。この区別を持っていないと、負荷試験で速度だけを見て安心し、データを増やした段階でメモリ不足に当たる。
索引の種類で、規模への強さが違う
pgvectorのREADMEは、HNSWとIVFFlatの2種類の索引を提供し、その性質の差を明記している。HNSWは多層グラフを作る方式で、速度と再現率のトレードオフではIVFFlatより良いクエリ性能を持つが、構築が遅くメモリを多く使う。IVFFlatはベクトルをリストに分割し、クエリに近いリストの一部だけを探す方式で、構築が速くメモリが少なくて済む(出所: https://raw.githubusercontent.com/pgvector/pgvector/master/README.md 、確認日2026-09-06)。
同じREADMEには、HNSW索引の構築において、グラフが maintenance_work_mem に収まらなくなると構築が大幅に遅くなる旨の注意があり、目安として10万タプルを超えたあたりで収まらなくなる場合がある、という趣旨の記述がある(同上)。規模が大きくなるほど、索引を「作れるか」「作り直せるか」が問題になる。
IVFFlatについては、リスト数の設定例として lists = 100 と lists = 1000 の2つが示されており、件数に応じてリスト数を変える前提になっている(同上)。規模を見誤ってリスト数を固定すると、再現率か速度のどちらかが落ちる。
分割の単位が増えると、その単位ごとの固定費が効いてくる
規模の問題は件数だけでなく、「いくつに分けるか」でも出てくる。Qdrantのマルチテナントに関するガイドは、テナントごとにコレクションを分けるのは効率的でないことが多いと述べ、その理由として、各コレクションがそれぞれ資源のオーバーヘッドを持つため、多数のコレクションを作るとすぐに高くつく、と書いている(出所: https://qdrant.tech/documentation/guides/multiple-partitions/ 、確認日2026-09-06)。
件数の規模と分割数の規模は別の軸で、後者は「1単位あたりの固定費 × 単位数」で効いてくる。マルチテナントの設計についてはマルチテナントの分け方で別に扱う。
規模の見積もりで最初に決めるべきこと
公式ドキュメントで確認できた性質から、規模を見積もるときに先に決めておくべきことは3つに絞れる。
1つ目は次元数と件数からメモリ量を出すこと。Weaviateのドキュメントが言うように、メモリが最大サイズを決める。2つ目は索引を作り直す頻度である。データの増え方によっては、索引構築の遅さが運用の律速になる。この点は更新頻度で変わる選択で扱う。3つ目は絞り込みの有無で、絞り込みが多いと索引の効き方が変わる。これはメタデータ絞り込みが要るかで扱う。
いずれも、実際の数値は自社のデータで測る必要がある。本稿はどの資源が先に上限になるかの見当をつけるためのものであり、何件まで持てるかを保証するものではない。
よくある質問
Q1. ベクトルの件数が増えると、まず何が問題になるか
公式ドキュメントで確認できた範囲では、検索速度より先にメモリが問題になる。Weaviateの資源計画のページは、メモリがサポートできるデータセットの最大サイズを決め、クエリ速度には直接影響しないと明記している。載るかどうかが先で、速いかどうかは後である。
Q2. HNSWとIVFFlatはどちらを選べばよいか
pgvectorのREADMEによれば、HNSWは速度と再現率のトレードオフで優れるが構築が遅くメモリを多く使い、IVFFlatは構築が速くメモリが少ない。規模が大きく、かつ索引を頻繁に作り直す必要があるなら、構築の遅さが効いてくる。どちらが良いかは件数と更新頻度の組み合わせで決まる。
Q3. テナントや用途ごとにコレクションを分けても問題ないか
Qdrantのガイドは、コレクションごとに資源のオーバーヘッドがあるため、多数のコレクションを作るとすぐに高くつくと述べている。件数の規模とは別に、分割数の規模が固定費として効いてくる。
Q4. 自社では何件まで扱えているのか
編集部の自社RAG基盤はベクトルDBを使っておらず、索引による確定配信で運用しているため、ベクトル件数の上限に関する自社の実測は持っていない。本稿の内容は各サービスの公式ドキュメントで確認できた性質に基づく。
規模の見積もりは、資源のどこが先に詰まるかを知ってから始めた方が手戻りが少ない。自社のデータ量でどう構成すべきか相談したい方は、お問い合わせから編集部までご連絡いただきたい。
- ハブ記事: RAGサービス比較15選
- 関連記事: RAGのレイテンシをどこで測るか
- 関連記事: 更新頻度で変わる選択
- 関連記事: メタデータ絞り込みが要るか
- 関連記事: そもそもベクトルDBが要らない場合