Aurora PostgreSQL の pgvector は、CREATE EXTENSION vector; の1行で有効になります。手が止まるのはその手前と先です。入る拡張の版はエンジンのマイナー版で決まり、選んだ版によっては絞り込み検索の件数欠けを防ぐ機能が使えません。Bedrock のナレッジベースに繋ぐなら、表の列と索引に決まった形があります。この記事では、エンジン版と pgvector の版の対応、HNSW インデックスの作り方と Optimized Reads の条件、aws_ml 拡張で SQL から Bedrock の埋め込みを作る方法、既存の Aurora をナレッジベースのベクトルストアにする設定までを、2026年11月時点の AWS 公式ドキュメントに沿って SQL と CLI の例付きで並べます。
まとめ：Aurora PostgreSQLでpgvectorを使う前に決めるエンジン版と構成
結論から書きます。Aurora で pgvector を使うなら、pgvector 0.8.0 以上が入るエンジン版を選んでください。2026年11月時点で 0.8.2 が入るのは 18.4 以降・17.10 以降・16.14 以降・15.18 以降・14.23 以降です。0.8.0 未満では、メタデータで絞り込んだ検索が LIMIT の件数に届かない問題を設定で解消できません。
構成は2択です。検索 SQL を自分で書くなら、業務データと同じクラスタにベクトル列を足します。Bedrock のナレッジベースに取り込みと検索を任せるなら、専用のスキーマと必須列の表を用意し、Data API と Secrets Manager を有効にします。どちらでも、ナレッジベースのクイック作成が作るクラスタは検証用と割り切ってください。
ベクトル件数が数百万件までで、業務データと結合して返す検索があるなら、Aurora で押し切って構いません。
Aurora PostgreSQLのエンジン版から使えるpgvectorの版を確かめる手順
Aurora の pgvector は、コミュニティの最新版がすぐ入るわけではありません。AWS が検証した版がエンジンのマイナー版に紐づいて提供されます。pgvectorのGitHubリポジトリのインストール手順は2026年11月時点で v0.8.7 を指していますが、Aurora で入る最新は 0.8.2 です。
マイナー版ごとのpgvector同梱版と0.8.0以上を選ぶ理由
Aurora PostgreSQLの拡張機能一覧から、主なマイナー版を抜き出すと次のとおりです（2026年11月8日時点）。
| メジャー | 0.8.2が入る版 | 0.8.1 | 0.8.0未満が残る版 |
|---|---|---|---|
| 18系 | 18.4・18.6 | 18.3 | なし |
| 17系 | 17.10・17.11 | 17.9 | なし（17.4〜17.7は0.8.0） |
| 16系 | 16.14・16.15 | 16.13 | 16.6以前（16.2は0.5.1） |
| 15系 | 15.18・15.19 | 15.17 | 15.10以前（15.7は0.7.0） |
| 14系 | 14.23・14.24 | 14.22 | 14.15以前 |
0.8.0 を境目にするのは、反復インデックススキャン（iterative scan）がこの版で入ったためです。AWSの0.8.0対応の告知も、フィルタ条件付きのクエリ性能と使い勝手の改善を挙げています。メジャー版そのものの選び方と標準サポート終了日はAurora PostgreSQLの対応バージョンと拡張機能の記事で扱っています。
describe-db-engine-versionsとSQLによる実機の拡張版確認手順
表は公開時点の写しです。構築前に CLI でリージョンに実在する版を並べ、構築後は SQL で入った版を確かめます。
# 東京リージョンで作成できる17系のエンジン版を並べる
aws rds describe-db-engine-versions \
--engine aurora-postgresql \
--region ap-northeast-1 \
--query "DBEngineVersions[?starts_with(EngineVersion, '17.')].EngineVersion" \
--output text
-- 接続後：拡張を有効化し、入った版と入れられる版を確かめる
CREATE EXTENSION IF NOT EXISTS vector;
SELECT extversion FROM pg_extension WHERE extname = 'vector';
SELECT name, default_version, installed_version
FROM pg_available_extensions
WHERE name = 'vector';拡張名は vector で、pgvector と書くと見つからないと言われます。この取り違えとエラーの読み方はpgvectorのインストール手順と使い方の記事にまとめています。
エンジンのマイナー更新後にALTER EXTENSIONで拡張を上げる作業
エンジンを上げても、既にデータベースに入っている拡張の版は自動では変わりません。pg_available_extensions の default_version が上がったのを確かめてから、拡張を更新します。
ALTER EXTENSION vector UPDATE;
SELECT extversion FROM pg_extension WHERE extname = 'vector';見落としやすいのは、マイナー版の自動アップグレードを有効にしたままのクラスタです。エンジンは上がったのに拡張は古いまま、という状態が気付かれずに残ります。iterative scan の設定を入れて「効かない」と感じたら、まず extversion を見てください。
Aurora上でベクトル列とHNSWインデックスを作るSQLと構築時の設定
表と索引の作り方は、素の PostgreSQL と同じです。Aurora で考えることは、構築時のメモリと、読み取りを支えるインスタンスクラスの選び方の2点に絞られます。
埋め込み次元に合わせたテーブル定義と1行あたりの容量見積もり
列の次元数は埋め込みモデルの出力に合わせます。Bedrock の Titan Text Embeddings V2 なら 1,024・512・256 次元から選べ、既定は 1,024 です（Titan Text Embeddingsのパラメータ）。
CREATE TABLE documents (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
category text NOT NULL,
body text NOT NULL,
embedding vector(1024)
);容量は pgvector の README にある「4 × 次元数 + 8 バイト」で見積もります。1,024 次元なら1行あたり 4,104 バイトで、100万チャンクで約 4.1GB がベクトルだけで埋まる計算です。Aurora のストレージは使った分の課金なので、次元を 512 に落とすとこの部分が半分になります。精度との兼ね合いは、検索結果を並べて比べてから決めてください。
HNSW作成時のmaintenance_work_memと並列ワーカーの設定
HNSW の構築は、グラフが maintenance_work_mem に収まると大幅に速くなる、と README は説明しています。並列ワーカーの既定は2です。Aurora ではセッション単位で上げてから索引を作ります。
SET maintenance_work_mem = '4GB';
SET max_parallel_maintenance_workers = 3;
CREATE INDEX documents_embedding_hnsw
ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
-- 絞り込みの条件に使う列にはB-treeも張る
CREATE INDEX documents_category_idx ON documents (category);メモリの設定値は、インスタンスの総量を使い切らない範囲に抑えてください。README も、サーバーのメモリを枯渇させるほど高く設定しないよう注意しています。Serverless v2 で構築するなら、索引を作る間だけ最大 ACU を上げ、終わったら元の設定値に戻す運用が可能です。ACU の決め方はAurora Serverless v2の料金と最小ACUの記事で試算しています。
Optimized Readsの階層キャッシュがHNSW検索を速くする条件
Aurora Optimized Readsのドキュメントは、効果が出る用途として「数百万件の埋め込みを pgvector で近傍検索する生成 AI アプリケーション」を名指ししています。インスタンスのローカル NVMe をキャッシュに使い、メモリに載らないデータを Aurora ストレージより近い場所から読む仕組みです。
条件は3つあります。インスタンスクラスが NVMe 付きの r6gd・r6id・r8gd であること、クラスタのストレージ構成が I/O-Optimized であること、エンジン版が対応範囲にあること（r6gd・r6id は 16.1 以降、r8gd は 16.3 以降・17.4 以降など）です。Standard 構成では一時オブジェクトにしか使われず、階層キャッシュは効きません。キャッシュ容量はインスタンスメモリの最大5倍までです。HNSW の索引がメモリに収まらず、検索の遅延がストレージ読み出しで伸びている場合に検討してください。効いているかは EXPLAIN (ANALYZE, BUFFERS) の aurora_orcache_hit で確かめられます。
aws_ml拡張でAurora内からBedrockの埋め込みを生成するSQL
埋め込みはアプリ側で作るのが一般的ですが、Aurora には SQL から Bedrock のモデルを呼ぶ aws_ml 拡張があります。バッチで既存行に埋め込みを付けたいとき、アプリを書かずに済みます。
IAMロールをBedrock機能としてクラスタに関連付ける手順
Aurora machine learningのドキュメントの手順は次の順です。
- IAM で
bedrock:InvokeModelを許可するポリシーを作る - そのポリシーを付けたロールを RDS 用に作る
- RDS コンソールでクラスタの「接続とセキュリティ」を開き、ロールを機能「Bedrock」で追加する
- 書き込みインスタンスに接続し、
CREATE EXTENSION IF NOT EXISTS aws_ml CASCADE;を流す
Bedrock はクラスタと同じリージョンで動いている必要があります。Bedrock 用の関数が入るのは aws_ml 2.0 からで、拡張一覧では 14.10 以降・15.5 以降・16系・17系・18系が 2.0 です。関数の EXECUTE 権限は既定で PUBLIC から外されているため、アプリ用のロールには rds_superuser から付与します。
invoke_model_get_embeddings戻り値をvector型へ変換・保存
aws_bedrock.invoke_model_get_embeddings は、モデルの JSON 応答から指定したキーの配列を float8[] で返します。ドキュメントは「拡張はベクトルのインターフェースを持たない」と明記しているため、保存時に vector 型へキャストします。
UPDATE documents
SET embedding = aws_bedrock.invoke_model_get_embeddings(
model_id := 'amazon.titan-embed-text-v2:0',
content_type := 'application/json',
json_key := 'embedding',
model_input := json_build_object(
'inputText', body,
'dimensions', 1024,
'normalize', true)::text
)::vector
WHERE embedding IS NULL
AND id IN (SELECT id FROM documents WHERE embedding IS NULL LIMIT 100);この関数は1行ずつ Bedrock を呼び、バッチ呼び出しや並列呼び出しには対応していません。数万行を一度に流すと長いトランザクションになるため、上のように100件ずつに区切って繰り返します。model_input を文字列連結で組むと、本文に二重引用符が入った行で JSON が壊れます。json_build_object で組むのはそのためです。
Bedrockナレッジベースのベクトルストアに既存のAuroraを使う設定
ナレッジベースのベクトルストアに Aurora を選ぶと、取り込み・チャンク分割・埋め込みは Bedrock が行い、Aurora は保存と検索だけを受け持ちます。そのため、表の形は Bedrock の決まりに合わせた構成が必要です。ナレッジベース全体の設計はナレッジベースとRAGの違いと権限制御の記事、Managed 型との比較はAmazon BedrockでRAGを実装する手順の記事で扱っています。
bedrock_integrationスキーマと必須4列の表を作るSQL
Aurora PostgreSQLをナレッジベースに使う手順は、Bedrock 専用のスキーマとロールを作り、そのロールで表を作る流れです。クラスタは Data API を有効にし、資格情報を Secrets Manager で管理します。
-- マスターユーザーで実行
CREATE EXTENSION IF NOT EXISTS vector;
CREATE SCHEMA bedrock_integration;
CREATE ROLE bedrock_user WITH PASSWORD 'change-me' LOGIN;
GRANT ALL ON SCHEMA bedrock_integration TO bedrock_user;
-- bedrock_userで実行（Titan V2の1,024次元）
CREATE TABLE bedrock_integration.bedrock_kb (
id uuid PRIMARY KEY,
embedding vector(1024),
chunks text,
metadata json,
custom_metadata jsonb
);先頭の4列は必須で、custom_metadata はメタデータで絞り込むときに使う任意列です。列名は変えられますが、Bedrockのベクトルストア前提条件は、ナレッジベース作成後にこの対応付けを更新できないと書いています。クラスタの配置先も、ナレッジベースと同じ AWS アカウントであることが条件です。接続確認は Data API から流すと、ナレッジベースが使う経路と同じで確かめられます。
aws rds-data execute-statement \
--resource-arn "arn:aws:rds:ap-northeast-1:123456789012:cluster:kb-cluster" \
--secret-arn "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:kb-secret-AbCdEf" \
--database postgres \
--sql "SELECT extversion FROM pg_extension WHERE extname = 'vector'"GINインデックスとiterative_scanで絞り込み検索の件数欠けを防ぐ
索引は3本です。ベクトル列の HNSW と、本文 chunks の全文検索用 GIN が必須で、custom_metadata を作ったならその GIN も要ります。
CREATE INDEX ON bedrock_integration.bedrock_kb
USING hnsw (embedding vector_cosine_ops) WITH (ef_construction = 256);
CREATE INDEX ON bedrock_integration.bedrock_kb
USING gin (to_tsvector('simple', chunks));
CREATE INDEX ON bedrock_integration.bedrock_kb
USING gin (custom_metadata);
-- pgvector 0.8.0以上：絞り込み時に索引を追加で読ませる
ALTER DATABASE postgres SET hnsw.iterative_scan = 'relaxed_order';
ALTER DATABASE postgres SET hnsw.max_scan_tuples = 20000;Bedrock のドキュメントは、メタデータで絞り込むなら iterative scan を有効にするよう勧めています。絞り込みが HNSW の走査の後に掛かるため、該当行が少ない条件では返る件数が期待を下回るからです。データベース単位の設定は新しいセッションから効き、Data API の接続プールが入れ替わるまで数分かかります。
日本語の文書では、全文検索索引の 'simple' 設定による語の区切り方に注意が必要です。この設定は空白や記号で語を区切るため、空白の無い日本語の文は長いひと続きの語として索引されます。この語の区切り方が、ハイブリッド検索のキーワード側で日本語が当たりにくい理由です。キーワード検索の組み方はハイブリッド検索とRRFの記事で比べています。
クイック作成のServerless v2構成を本番に持ち込まない理由
Bedrock のコンソールには、Aurora のベクトルストアを自動で作るクイック作成があります。クイック作成のドキュメントによると、作られるのは Serverless v2 のクラスタで、ACU は 0〜16、既定 VPC に置かれ、エンジンは 15.7 です。ドキュメント自身が、検証と素早い立ち上げ向けで本番には向かず、自社の VPC へそのまま移せないと書いています。
見落とされやすいのはエンジン版です。15.7 に入る pgvector は 0.7.0 で、前の h3 の iterative scan が使えません。メタデータで絞り込むナレッジベースを作るなら、クイック作成で動作を確かめた後、0.8.0 以上が入る版で自分のクラスタを作り直してください。手作業で組むクラスタの作り方はAuroraのCLI構築手順の記事にまとめています。
Aurora pgvector採用とOpenSearch・S3 Vectorsの選択基準
ベクトル検索の置き場を Aurora にするかどうかを、条件で言い切ります。
Auroraで押し切ってよい条件と、別のベクトルストアへ寄せる場面
次の3つが揃うなら、Aurora の pgvector で押し切ってください。第一に、業務データが既に Aurora PostgreSQL にあり、検索結果を顧客や商品の行と結合して返すこと。第二に、ベクトルの件数が数百万件までで、検索の負荷が業務の書き込みを圧迫しないこと。第三に、文書の更新とベクトルの更新を同じトランザクションで揃えたいことです。別のストアに分けると、この結合と整合を自前で書くことになります。
見送る場面も明確です。検索の大半がベクトル検索だけで業務データとの結合が無く、問い合わせ頻度も低いなら、Aurora のインスタンスを常時動かす理由が薄れます。この場合、費用を抑えるための選択肢は Bedrock のナレッジベースで使う S3 Vectors です。埋め込みをバイナリで持って容量を削りたい場合は OpenSearch を選びます。前提条件ページによると、ナレッジベースでバイナリのベクトルを保存できるのは OpenSearch Serverless と OpenSearch のマネージドクラスタだけで、Aurora は浮動小数点のベクトルに限られます。数千万件規模で高頻度の検索を業務 DB と同居させる構成も避けるべきで、片方の負荷がもう片方の応答に影響するためです。別のストアを選ぶ場合の比較は、AWSのベクトルデータベースの選び方で8サービスの上限値とBedrock対応を並べています。RDS for PostgreSQL と迷っているなら、費用とフェイルオーバーの差をRDSとAuroraの違いを実測で比べた記事で確認できます。
Supabase で同じ pgvector を組む場合との違いは、Supabase pgvectorの実装手順の記事と並べると見えてきます。どの基盤でも、チャンクの切り方、埋め込みモデル、権限の持ち方は置き場より先に決める事項です。社内文書の検索基盤をこれから選ぶ段階なら、RAG構築支援として要件整理から相談を受けています。
よくある質問
Aurora で pgvector を使い始めるときに出やすい疑問をまとめます。
Aurora PostgreSQLでpgvectorの最新版は使えますか？
コミュニティの最新版がすぐに入るわけではありません。2026年11月時点で pgvector の GitHub は v0.8.7 を案内していますが、Aurora で入る最新は 0.8.2 で、18.4 以降や 17.10 以降などの新しいマイナー版に限られます。使える版はエンジンのマイナー版で決まるため、必要な機能が入る拡張の版から逆算してエンジン版を選んでください。
エンジンを更新したのにpgvectorの版が古いままなのはなぜですか？
エンジンの更新は、データベースに入っている拡張の版までは変えないためです。pg_available_extensions の default_version が上がっていることを確かめてから、ALTER EXTENSION vector UPDATE; を流します。データベースが複数あるなら、それぞれで実行が必要です。
Aurora Serverless v2でもpgvectorは使えますか？
Serverless v2 でも pgvector は使用可能です。Bedrock のクイック作成も Serverless v2 で Aurora を作り、ACU を 0〜16 に設定します。注意が必要なのは HNSW の構築です。メモリが足りない場合、索引の作成が遅くなるため、構築時のメモリ量を確認してください。構築の間だけ最大 ACU を上げ、終わったら戻す運用が向いています。拡張の版はプロビジョンド型と同じく、エンジンのマイナー版で決まります。
Bedrockのナレッジベースで絞り込むと結果が少ないのはなぜですか？
メタデータの絞り込みが HNSW の走査の後に掛かるためです。該当する行が少ない条件では、索引から集めた候補の大半が条件で落ち、返る件数が指定より減ります。pgvector 0.8.0 以上なら、データベースに hnsw.iterative_scan = 'relaxed_order' を設定すると、足りない分を索引から追加で読むようになります。
RDS for PostgreSQLとAuroraでpgvectorの使い方は違いますか？
拡張そのものと SQL は同じです。違いは周辺の機能に出ます。Aurora には NVMe をキャッシュに使う Optimized Reads、SQL から Bedrock を呼ぶ aws_ml 拡張、ナレッジベースのクイック作成があり、ベクトル検索を Aurora の中で完結させやすい作りです。入る pgvector の版は両者で異なることがあるため、それぞれの拡張一覧で確かめてください。
関連記事
- Aurora PostgreSQLとは？対応バージョン・拡張機能とBabelfish・RDSからの移行判断を実装者目線で解説：エンジン版の選び方です。
- pgvectorとは？インストール手順（Windows・Ubuntu・Docker Compose）と使い方【0.8.7対応】：拡張そのものの仕組みと演算子です。
- Supabase pgvectorの実装手順：RPC検索関数・HNSW・RLS併用のRAG構成：別基盤での同じ実装です。
- Amazon BedrockでRAGを実装する手順｜Managed Knowledge Baseのboto3実装と東京リージョンの制約【2026年11月】：ナレッジベース側の実装です。
- Aurora Serverless v2とは？東京のACU料金と損益分岐・最小ACUの決め方：構築時のACUの考え方です。
