vector DB 變成宗教了。大家用 Hacker News 上的討論串或 benchmark chart 選工具 — 那些圖表在你產品的真實規模上大多沒意義。誠實的判斷:1000 萬 vector 以下的產品大多應該用 pgvector;以上才應該用 Qdrant 或 Pinecone;其他大部分人都不需要。
pgvector:90% 產品的正確預設
如果你有 Postgres(現在誰沒有),pgvector 幾乎肯定是對的答案。它是 Postgres 擴展;你既有的工具(備份、replication、transaction、JOIN)全部留下。vector 可以跟它們參照的原始資料放同一張表。大部分 production AI 功能(現有 table 的語義搜尋、help doc 的 RAG、推薦 embedding)這樣最強。
benchmark:pgvector 配 HNSW index,在普通 Postgres 機器上輕鬆處理千萬量級 vector。2025-2026 世代的 pgvector 改進(HNSW、平行 index 建立、pgvectorscale 的 ScaNN 量化)把跟專門 vector DB 的效能差距縮到很小。
pgvector 撐不住的時候:> 5 千萬 vector 而且延遲嚴格,或者極高寫入(每小時數百萬 vector 串進來)。到那個 scale 你會自己知道。
Qdrant:自架的最強專門 vector DB
Qdrant 是最強的開源專門 vector DB。Rust 寫的、快、部署簡單(單一 binary 或 Docker)、雲端產品定價合理。filter 故事是業界最強 — 可以在向量搜尋前做複雜 metadata 過濾,而且很有效率。
什麼時候用 Qdrant:pgvector 撐不住、要 hybrid search(BM25 + vector)內建、或者需要進階過濾。Qdrant Cloud 處理 ops;自架 Qdrant 在一台 $20/月 VPS 上處理 100 萬 vector 沒問題。
弱點:生態跟社群比 Pinecone 小。Stack Overflow 資料較少。產品變動快 — 2024 年的 tutorial 看到的,常常已經過時。
Pinecone:ops 不夠的團隊的對選擇
Pinecone 最貴也最簡單。你不用想 DB 的事。自動 scale。可靠性真的很強。團隊錢多 ops 不夠(大部分早期新創就這樣),Pinecone 把整類麻煩抹掉。
什麼時候用 Pinecone:需要它就 work、規模到了(> 1000 萬 vector)、沒人想跑 infra。serverless 方案把以前「最低 $70/月」的門檻拿掉,現在可以便宜開始再 scale up。
弱點:貴。規模化後 Pinecone 大概比自架 Qdrant 貴 5-10 倍。供應商鎖定:換掉不容易,因為 API 跟 index 選項跟開源標準不同。
Weaviate:內建 hybrid search 但偏重
Weaviate 很有自己想法。它包了自己的 data modeling 層、內建 hybrid search 跟 rerank、支援 embedding 生成的 module、整體設計也用心。開源自架可行;雲端產品穩。
什麼時候用 Weaviate:想要 hybrid search 跟內建 module 不用整合五個工具,或者需要對 vector 做 GraphQL query(很少見)。最近被更簡單的工具瓜分市場 — 「all-in-one」沒有「Postgres + 重要部分用一個小專家」這種組合受歡迎。
Milvus、Chroma、LanceDB、MongoDB Atlas、Elastic
- Milvus — 騰訊、字節跳動這類公司處理十億 vector 等級的高端選擇。維運很重。不到那個 scale 不要用。
- Chroma — 原型最好用的 DX。內嵌、不用 server、很 Pythonic。Jupyter notebook 跟 demo 用。production 換別的。
- LanceDB — 架構有意思(資料放 S3、多模態友善)。值得觀察。production 成熟度進步中,但還落後 Qdrant。
- MongoDB Atlas Vector Search — 已經在 MongoDB Atlas 就 OK。不要為了這個遷到 MongoDB。
- Elastic / OpenSearch — 已經跑 Elastic 就 OK。也不要為了這個遷過去。
- Redis Vector Search — 快、in-memory、貴。利基場景(即時 agent 需要 10ms 以下 vector query)。
benchmark chart 沒告訴你的
供應商發的 benchmark(「1 億 vector 在 5ms p99」)幾乎永遠跟你的 workload 不符。實際效能看:
- 你的 filter 基數(metadata filter 在搜尋前匹配多少 vector)
- 你的更新模式(頻繁寫入會 invalidate HNSW cache)
- 你的維度數(1536 vs 768 vs 384 全部都不一樣)
- 你的硬體(NVMe SSD vs 網路 storage 比 DB 本身重要)
如果 benchmark 在主導你的決策,用你自己的資料跑一次。沒 context 的「我的 DB 5ms」沒意義。
什麼時候完全不需要 vector DB
- 1 萬 vector 以下:用 NumPy 在 Python list 裡放著就好。加 DB 只增加維運成本沒好處。
- 靜態不變的資料集:全部預先算好,存 Parquet,FAISS 在 process 裡查。不需要 DB。
- 長 context 模型放得下你的資料:Gemini 2.5 Pro 1M+ context,小 corpus 有時可以完全跳過檢索。
- 關鍵字搜尋本來就更好:當 ILIKE 或 BM25 零成本就能解決你的問題,不要 vector 化。
很多「需要」RAG 的產品,其實只需要全文搜尋加上聰明的 prompt。先試簡單的方案。
遷移成本:挑你能離開的
鎖定很重要。誠實排序:
- pgvector:零鎖定(就是 SQL,容易 dump 跟搬)
- Qdrant 自架:低鎖定(開源、多個雲端供應商)
- Qdrant Cloud / Weaviate Cloud:中等
- Pinecone:高(專有、自訂 indexing 語義)
剛起步、不確定的話,從 pgvector 開始。之後從 pgvector 搬到別的工具,成本比從 Pinecone 搬出去低很多。
決策樹
- 已經跑 Postgres、< 1000 萬 vector:pgvector
- 要自架、專門、hybrid search:Qdrant
- ops 不夠、願意付錢:Pinecone
- 需要 GraphQL 或強 opinionated stack:Weaviate
- 在 Jupyter 做原型:Chroma
- 中文圈內部、十億規模:Milvus
下一步
- 有 Postgres 先試 pgvector — 5 分鐘能裝好
- 看一下 HNSW vs IVF index 了解調校旋鈕
- 研究 hybrid search(BM25 + vector)— 幾乎永遠贏純 vector
- 設好評估流程,讓你能用真實資料比 DB,不是看廠商 benchmark