4 種能上線的向量資料庫選擇
4 種可上線的向量資料庫方案，從過濾、延遲到建索時間比較，幫你決定 RAG 該選哪個。
生產環境做 RAG，向量資料庫到底該選哪一個？
這份清單比較 4 種可上線的向量資料庫方案，幫你從過濾、延遲和建索時間做決定。
| 項目 | 最佳情境 | 過濾能力 | 營運輪廓 |
|---|---|---|---|
| PostgreSQL + pgvector | 多數團隊 | SQL WHERE 很強 | 營運成本最低 |
| Elasticsearch + dense_vector | 本來就用 Elastic 的團隊 | 混合搜尋很強 | 資源吃得多 |
| Pinecone | 想用代管服務快速上線 | 夠用，但綁供應商 | 起步簡單，後期較貴 |
| Qdrant | 重視低延遲搜尋 | 過濾能力很突出 | 速度快，生態較小 |
| Weaviate | 想兼顧混合搜尋與成熟度 | 混合檢索表現穩定 | 平衡型選擇 |
1. PostgreSQL + pgvector
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
對很多團隊來說，pgvector 是最穩的起點，因為它直接把向量搜尋放進你已經熟悉的 PostgreSQL。SQL、交易、備份、權限和一般查詢都還在同一套系統裡，做原型到上線的切換成本很低。
它最適合資料量還沒大到失控、但篩選條件很複雜的 RAG。你可以把相似度搜尋和業務欄位條件一起寫進查詢，少掉很多同步與維運麻煩。
- 適合已經在跑 PostgreSQL 的團隊
- 很適合 metadata 很多的文件檢索
- 備份與 replication 都很成熟
2. Elasticsearch + dense_vector
Elasticsearch 適合本來就很依賴關鍵字搜尋的團隊。它的 dense_vector 加上 BM25，讓混合搜尋變成原生能力，對法務、客服、商品搜尋這類要同時看字面與語意的場景特別實用。
代價是系統重量。記憶體、儲存和調校成本都高，若你的團隊沒有既有 Elastic 基礎，導入門檻會比 pgvector 高得多。
- 已經有搜尋叢集時最順手
- 適合精確詞與語意一起查
- 硬體與調校成本都偏高
3. Pinecone
Pinecone 的優勢是快，從試跑到正式環境的路徑很短。代管模式把大部分基礎設施工作包起來，團隊可以先把重點放在 embedding、切 chunk 和檢索策略，而不是索引怎麼養。
缺點也很明確，就是成本與控制權。規模一大，費用容易上升，而且沒有自建退路。若你要的是最少維運，這是好選項；若你要的是長期壓成本，它就不一定划算。
- 最適合快速從 prototype 進 production
- 幾乎不用自己管基礎設施
- 規模變大後費用壓力明顯
4. Qdrant
Qdrant 很適合把低延遲和過濾當成第一優先的團隊。它用 Rust 寫成，實際感受通常是查詢速度穩、負載上來也比較可預期，特別是在每次請求都要帶條件篩選的情況下。
它的弱點不是功能，而是生態。整體整合數量和社群規模都比大廠小一些，所以如果你很在意現成工具鏈，可能會覺得要自己多補幾塊拼圖。
- 低延遲檢索表現很有競爭力
- 適合每次查詢都帶 filters
- 生態比主流大廠小
5. Weaviate
Weaviate 是這份清單裡最均衡的專用向量資料庫。它把向量與關鍵字混合搜尋做得很自然，對大多數文件檢索型 RAG 來說，這正是最常需要的能力組合。
如果你的目標不是追求單一指標冠軍，而是要一個能長期維持、工具鏈也夠完整的方案，Weaviate 很值得看。它通常不是最便宜或最快，但常常是最不容易後悔的專用選擇。
- 混合檢索能力完整
- 適合文件型與知識庫型應用
- 成熟度和功能平衡感不錯
哪種適合你
如果你要的是最低風險預設值，先選 PostgreSQL + pgvector。若搜尋本來就是系統核心，而且團隊已經在用 Elastic，就直接看 Elasticsearch。想把維運壓到最低，Pinecone 最快上手。若你最在意延遲和過濾，Qdrant 很值得優先測試；而 Weaviate 則適合想要混合搜尋、又希望方案夠均衡的團隊。
真正該拿來決定的，不是宣傳分數，而是你自己的 embedding、recall@10、filtered query latency 和 index build time。先用真實資料測一次，通常就會知道哪個方案能撐到上線後。