個人〜小規模サービスにセマンティック検索を入れる場合、専用ベクトル DB（Pinecone、Qdrant 等）を増やすより、既存の PostgreSQL に pgvector 拡張を入れ、埋め込み生成は外部 API に任せる構成が費用・運用の両面で有利。managed PostgreSQL（Render 等）は pgvector を標準サポートしており CREATE EXTENSION だけで使える。埋め込み API（Gemini の embedding モデル等）は個人メモ規模なら月数円以下で済む。

設計の要点:

• embedding は本体テーブルに混ぜず、1:1 の別テーブル（<entity>_embeddings）に分離する。モデル変更による再生成・次元変更時に本体スキーマへ影響せず、未生成レコードの検出（LEFT JOIN で NULL）も簡単になる。
• embedding 生成は本体の保存トランザクションの成否に影響させない。保存成功後に同期生成し、失敗はログのみで縮退（そのレコードが検索に出ないだけ）。これで外部 API 障害がコア機能を壊さない。
• 既存データには backfill 用のバッチ処理を用意する。1 回あたりの件数上限と「残りがあるか」フラグを返すページング設計にすると、API レートやタイムアウトに収まる。新規・更新分は保存フックで自動生成されるので backfill は導入時の一回もの。
• 埋め込み API のタスクタイプは保存側を文書用（RETRIEVAL_DOCUMENT）、検索側をクエリ用（RETRIEVAL_QUERY）に分けると検索精度が上がる。

併用の判断: セマンティック検索は言い換えに強い一方、ID・コマンド名・固有名詞の完全一致に弱い。既存のキーワード検索（ILIKE / 全文検索）は廃止せず用途別に併存させ、必要になったらスコア統合（ハイブリッド検索）へ進化させる余地を残す。