狀態： 已採納（Accepted）
日期： 2026-04
決策者： Software Architect
背景
Arova Nexus 的 L4 Intelligence Layer 需要向量資料庫來：
- 儲存所有核心實體（工單、事件、KB 文件、資產、對話）的 embedding
- 支援語意搜尋（KB RAG、AI Copilot 上下文、相似告警合併）
- 支援跨實體的語意關聯（Semantic Graph 初期）
PRD Ch19（v1.3）原本列出三個候選：Qdrant、Milvus、pgvector。需要選一個作為 MVP 的向量儲存。
決策
採用 pgvector（PostgreSQL 擴充）。
理由
- On-Prem 部署複雜度最低 — 我們本來就需要 PostgreSQL 儲存業務資料，再加一個擴充比多部署一個獨立服務簡單得多
- 單一備份策略 — pg_dump 同時備份業務資料和向量資料，不需要兩套備份/還原流程
- Transactional 一致性 — 實體新增/更新時，業務資料和 embedding 可以在同一個 transaction 內更新，避免資料漂移
- MVP 資料量規模合適 — 預估 MVP 的實體總數 10 萬~100 萬筆（工單 + 事件 + KB chunk + 資產），pgvector 用 HNSW 索引綽綽有餘
- 運維團隊熟悉 — 客戶 IT 團隊多半已熟 PostgreSQL，Qdrant/Milvus 是新技能
- Mastra AI 原生支援 —
@mastra/pg 內建 pgvector 整合，不需要額外 adapter
考慮過的替代方案
| 方案 |
優點 |
缺點 |
| pgvector（選） |
單一資料庫、備份簡單、transactional、on-prem 友善 |
效能在千萬筆以上會不如專用向量 DB |
| Qdrant |
效能好、Rust 寫、API 直觀 |
多一個服務要部署/備份；客戶 IT 要學新東西；Mastra 整合不如 pgvector 緊密 |
| Milvus |
功能最完整、大規模效能最好 |
部署複雜（多個元件：etcd + MinIO + Pulsar）；過度 for MVP 規模 |
| Elasticsearch + vector |
全文檢索 + 向量一次滿足 |
記憶體吃重，on-prem 小客戶環境負擔大 |
影響
正面
- Docker Compose 的服務數量減少 1 個
- 開發時可以用 SQL JOIN 同時查詢業務資料和向量相似度
- 客戶只需要維運 PostgreSQL 一個資料庫
負面 / 取捨
- 效能天花板：到 1000 萬筆 embedding 以上時查詢會變慢，需升級方案
- 擴展性較差：pgvector 不支援分片，垂直擴展 PostgreSQL 是唯一選項（直到量大到需換 Milvus）
- 向量能力略有限：HNSW 參數調整不如 Qdrant / Milvus 靈活
需要追蹤的風險
- 升級路徑：當單客戶的向量總量超過 500 萬筆，或查詢 p95 超過 500ms，要啟動升級 POC（候選：Qdrant）
- Semantic Graph 擴展：Phase 2 如果上 Apache AGE（PostgreSQL 圖擴充），要確認和 pgvector 能共存
- Phase 3 SaaS 模式：multi-tenant 需要額外評估（可能需要每 tenant 獨立 pgvector schema 或轉 Qdrant）
觸發換方案的條件（不滿足時繼續用 pgvector）
只要以下任一條件達成，就啟動向量 DB 升級 POC：
- 單客戶向量總筆數 > 500 萬
- 向量查詢 p95 > 500ms（排除網路延遲）
- 需要 multi-tenant 細粒度隔離（Phase 3）
相關
- PRD v1.3 Ch19（AI Native 基礎設施）
docs/architecture/TECH_STACK.md（pgvector 已列入鎖定）
Arova Nexus Phase 0