多數已使用 PostgreSQL 的 RAG 專案，第一版先選 pgvector；沒有資料庫維運人力則先看 Pinecone。 Qdrant 適合把複雜 metadata filter 當核心需求的團隊，Weaviate 強在可調的 keyword／vector hybrid search 與多租戶，Milvus 適合願意管理分散式基礎設施、需要多種索引或 GPU 加速的大型工作負載。
不要用「向量超過 100 萬就一定要換資料庫」當規則。同樣是一百萬筆向量，768 維與 3,072 維的記憶體需求不同；只查 top 5 與同時服務 500 個查詢的負載也完全不同。filter 選擇率、更新頻率、召回率目標、備份與資料所在地，往往比總筆數更早決定選型。
五種向量資料庫快速比較
| 方案 | 優先考慮的情境 | 主要代價 |
|---|---|---|
| pgvector | 已用 PostgreSQL、要 SQL／JOIN／交易一致性、團隊不想多管一套服務 | HNSW 記憶體、filter 後召回、水平擴展要自己設計 |
| Pinecone | 想用全託管服務快速上線、希望少管叢集與索引 | SaaS 成本、區域與供應商限制；資料更新為 eventual consistency |
| Qdrant | metadata filter、多租戶、dense／sparse／multivector 與部署彈性 | 自架仍要處理高可用、容量、備份與升級 |
| Weaviate | 需要 BM25＋向量融合、named vectors、多租戶和可調 ranking | schema 與 hybrid 權重需要治理，功能多也增加設定面 |
| Milvus | 大型分散式工作負載、多索引、GPU、hot／cold storage | 系統元件與維運複雜度最高，小團隊容易過度工程 |
這五種方案的功能有大量重疊。Pinecone、Qdrant、Weaviate、Milvus 都能處理向量搜尋與條件過濾，pgvector 也有 HNSW、IVFFlat、halfvec、sparsevec 和 iterative scans。表格的用途是縮小 PoC 候選，不是替代實測。
授權與部署也要先分清楚：Pinecone 是專有託管服務；pgvector、Qdrant、Weaviate 與 Milvus 都有可自架的開源版本，另有不同廠商提供託管方案。開源不等於零成本，正式採用前仍要確認授權版本、升級責任、備份、高可用與技術支援由誰負責。
什麼情況先選 pgvector？
產品已把使用者、文件權限、訂單或案件資料放在 PostgreSQL 時，pgvector 可以讓 embedding 與原始資料共用交易、備份、權限和 SQL 工具。對第一版知識庫、內部搜尋或中小型 SaaS，少一套分散式系統通常比理論上的極限吞吐更有價值。
pgvector 預設可做 exact nearest-neighbor search，也支援 HNSW 與 IVFFlat。官方說明中，HNSW 通常有較好的 speed-recall trade-off，代價是建置較慢、使用更多記憶體；IVFFlat 建置快、記憶體較省，但要依資料量調整 lists 與 probes。
filter 是常見陷阱。近似索引可能先找候選，再套 WHERE 條件，當 tenant、權限或日期 filter 很嚴格時，最後回傳筆數與召回率可能下降。pgvector 0.8 之後的 iterative index scan 能繼續掃描候選，也可以搭配一般欄位索引、partial index 或 partitioning。這些方法仍達不到目標時，才有充分理由比較專用資料庫。
需要先理解 embedding 維度、距離函數與 chunk 如何影響結果，可先讀 Embedding 完整指南；資料庫無法修正錯誤的切塊與評估集。
Pinecone、Qdrant、Weaviate、Milvus 分別適合誰？
Pinecone 適合把維運時間看得比底層控制更貴的團隊。 它提供 serverless index、metadata filter、dense／sparse 與 hybrid search，也有整合 embedding 的路線。採購前要確認區域、資料主權、eventual consistency 對更新可見性的影響，以及查詢、寫入、儲存和 rerank 的總成本。
Qdrant 適合搜尋必須同時套複雜業務條件的產品。 payload filter 支援巢狀 AND、OR、NOT，官方也建議替常用 filter 欄位先建立 payload index。它提供 managed、hybrid、private 與開源部署選項，適合需要逐步調整資料控制程度的團隊。
Weaviate 適合把 keyword 與 semantic retrieval 一起調整的應用。 Hybrid search 會平行執行 BM25 與向量搜尋，再以 fusion 方法與 alpha 權重合併。它也支援 named vectors 與 collection-level multi-tenancy。若文件同時包含標題、正文、圖片描述與產品屬性，這些能力會比單一 embedding 欄位好管理。
Milvus 適合有平台工程能力的大型部署。 官方文件列出 HNSW、IVF、SCANN、DiskANN、GPU index、replica、hot／cold storage、BM25 與多層級 multi-tenancy。這些能力能處理複雜規模，卻也帶來更多容量規劃、監控、升級與故障排除工作。沒有明確瓶頸時，功能最完整不代表總成本最低。
Hybrid search 何時有必要？
使用者會輸入產品型號、法條編號、股票代號、人名、縮寫或錯字時，純 semantic search 容易漏掉精確字串。只做 BM25 又會漏掉同義詞與改寫。Hybrid search 把 lexical 與 dense retrieval 合併，適合企業知識庫、電商搜尋、技術文件與客服內容。
不能把兩種分數直接相加就上線。Pinecone 官方提醒 dense 與 sparse 分數範圍不同，需要正規化和顯式權重；Weaviate 也讓使用者調整 fusion 與 alpha。實務上應建立一組含精確詞、自然語句、時間條件與權限 filter 的查詢集，再測純 keyword、純 vector、hybrid 和 rerank 四條路線。
如果 RAG 架構本身還沒穩定，先完成 LangChain RAG 實作與檢索流程，再評估要不要換儲存層。過早搬資料庫，常常只會把 chunk、prompt 或 evaluation 的問題一起搬走。
用自己的資料做 60 分鐘 benchmark
先從真實搜尋紀錄抽出 50 到 200 個查詢，由熟悉內容的人標出應該出現的文件。資料集要包含一般問句、專有名詞、無答案問題、時間範圍與不同 tenant／權限組合。
每個候選方案使用相同 embedding、chunk、top K 與 reranker，量測四組結果：
- 檢索品質：Recall@K、MRR 或 nDCG@10，不能只看回答讀起來順不順。
- 延遲：記錄 P50、P95、P99，分開測無 filter、10% filter 與高度選擇性 filter。
- 更新行為：新增、修改、刪除後多久能被查到，索引重建時是否影響服務。
- 總成本：納入資料庫、embedding、rerank、網路、備份、監控和工程師維運時間。
測試時逐步增加並行量，不要只在筆電上連續送單一查詢。檢索評估方法可配合 LLM 與 RAG 評估指南 建立固定 regression set，之後換模型、切塊或索引參數才知道是否退步。
什麼時候該從 pgvector 搬走？
總向量數增加只能當預警，不能單獨觸發遷移。出現下列任一證據時，才值得做雙寫 PoC：目前硬體和調校後仍達不到 P95／P99 SLO；高選擇性 filter 讓 Recall@K 持續低於門檻；索引建置、vacuum 或 replica 已干擾交易工作；租戶隔離、資料區域或可用性需求超出現有 PostgreSQL 架構；維運成本高於託管服務報價。
遷移時先雙寫新舊系統，用同一批查詢比較結果，再逐步切讀取流量。保留原始文件、embedding model 版本、chunk ID 與 metadata schema，避免換資料庫後無法重建索引。把回滾路徑寫進計畫，比一次搬完更安全。
最後建議：先選最少的新系統
已經有 PostgreSQL 的團隊，先用 pgvector 建立可重複的 evaluation；全新小團隊又不想維運，可從 Pinecone 做 PoC。當 metadata filtering、hybrid ranking、多租戶或大規模分散式能力成為已量測的瓶頸，再讓 Qdrant、Weaviate 或 Milvus 進入比較。
向量資料庫只是檢索鏈的一段。embedding、chunk、filter、hybrid 權重、reranker 與答案引用，任何一段都可能比資料庫品牌更影響結果。能用同一組查詢證明品質、延遲和成本改善的方案，才是適合你的選擇。
常見問題
向量資料庫一定要用 Pinecone 或 Milvus 嗎？
不一定。已使用 PostgreSQL 的專案可先用 pgvector；它支援 exact search、HNSW、IVFFlat 與多種向量型別。只有在延遲、召回率、filter、可用性或擴展需求經實測無法達標時，才需要引入專用系統。
pgvector 可以存多少向量？
沒有一個適用所有專案的固定上限。容量取決於維度、型別、索引、記憶體、磁碟、filter、並行量和延遲目標。用自己的資料逐步壓測，會比套用「超過一百萬就搬家」更可靠。
FAISS 和向量資料庫差在哪裡？
FAISS 是向量搜尋函式庫，適合單機研究、離線索引與 PoC。資料庫還要處理持久化、更新、metadata、權限、備份、並行與高可用。正式服務若用 FAISS，這些能力要由團隊自行補齊。
RAG 一定需要 hybrid search 嗎？
不一定。內容以自然語言為主、查詢少有精確代號時，dense search 可能已足夠。若查詢包含 SKU、法條、姓名、日期或專有名詞，應把 BM25／sparse 與 dense hybrid 納入測試，再用 Recall@K 和 nDCG 比較。
參考來源
- pgvector GitHub：Indexing, filtering, scaling and monitoring（2026-08-12 查閱）
- Pinecone Docs：Create an index（2026-08-12 查閱）
- Pinecone Docs：Hybrid search（2026-08-12 查閱）
- Qdrant Documentation：Filtering（2026-08-12 查閱）
- Weaviate Documentation：Hybrid search（2026-08-12 查閱）
- Milvus Documentation：What is Milvus（2026-08-12 查閱）