100K 向量以下，pgvector 就夠了，不該當預設
我主張 pgvector 應該是 100K 向量以下的預設選擇；只有當規模、延遲與檢索複雜度上來時，才值得上專用向量資料庫。
100K 向量以下，pgvector 通常就夠用；當延遲、規模與檢索複雜度上升時，才該換專用向量資料庫。
把 pgvector 當預設，不是保守，而是務實：在 100K 向量以下，PostgreSQL 已能處理多數內部搜尋、早期 RAG 與小型語意檢索，沒必要先把架構做重。
第一個論點
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
100K 這條線很重要，因為它對應的是大多數團隊的真實起點。內部知識庫、產品目錄語意搜尋、客服文件檢索，常常只有數萬到十多萬筆向量。這種量級下，pgvector 直接掛在既有 PostgreSQL 上，通常就能把召回、過濾與權限控制一起做完。
更關鍵的是，PostgreSQL 已經自帶交易、備份、存取控制與 SQL join。若你的團隊本來就有一套成熟的 Postgres 維運流程，新增 pgvector 幾乎不增加心智負擔。相比之下，為了還沒證明會成長的向量檢索，先引入另一套資料庫，反而是在替未來的複雜度提前付費。
第二個論點
專用向量資料庫的優勢，主要出現在規模和延遲開始成為產品指標之後。像 Milvus、Qdrant、Weaviate 這類系統，之所以在 1bench 類型的排名裡靠前，不是因為名字新，而是因為它們就是為 ANN、索引結構與相似度查詢設計的。
GitHub star 也能側面說明成熟度：Milvus 約 45.2k、Qdrant 約 33.3k、Weaviate 約 16.6k。這代表社群、文件與實戰案例都已累積到一定程度。當資料量進到百萬級、查詢延遲要壓到嚴格 SLO，專用引擎在記憶體布局、索引更新與 top-k 搜尋上的優勢，會直接反映在產品體感上。
反方可能怎麼說
最強的反對意見是：pgvector 只是「先能用」，不是「最終解」。如果團隊明知資料會快速膨脹、查詢量會暴增，先上專用向量資料庫可以少一次遷移，也能提早拿到混合檢索、向量過濾與水平擴展的能力。
另一個合理批評是，AI 團隊想要的是語意檢索原生體驗。專用向量資料庫把 embedding、similarity search、RAG 這些概念包成同一個產品語言，整合成本較低，對人少、節奏快的新團隊尤其有吸引力。
但這些理由只在規模與複雜度已經可見時成立。若資料集仍小、流量仍低、而且團隊本來就運行 PostgreSQL，那麼多一套系統帶來的部署、監控、備援與故障排查成本，通常比 pgvector 的性能上限更早成為問題。先用 pgvector，等延遲或召回真的卡住，再升級，才是把錢和時間花在刀口上。
你能做什麼
如果你是工程師，先用 PostgreSQL + pgvector，並設定明確門檻：資料量、p95 延遲、召回率、以及是否需要混合檢索。若你是 PM 或創辦人，把專用向量資料庫視為一筆和產品指標綁定的基礎設施投資，不要把它當成 AI 形象工程。當向量檢索只是功能之一，pgvector 是更好的預設；當向量檢索就是核心路徑，才輪到 Qdrant、Milvus、Weaviate 這類專用系統上場。