編按：本文綜合整理自 turbopuffer 官方部落格、turbopuffer v3 進度頁、ANN v3 技術文、SPFresh 論文、SPANN 論文，並加入 Siami 編輯部觀點與分析。
一句話總結這篇報導
向量資料庫從 2023 年開始被當成 RAG（檢索增強生成）的基礎建設，現在它的主要發明者 turbopuffer 親手宣告：「向量索引不該是 primary index」。他們要把 ANN（近似最近鄰搜尋）從核心降級為「另一個次級索引」，改用一個更通用的主索引來同時撐起文字、屬性與向量搜尋。
這是一篇由 turbopuffer 工程師 Dan Harrison 在 2026 年 9 月 30 日發布的內部技術回顧，標題刻意致敬「RIP, [服務名稱]」這個技術圈用語。
從 v1 到 v2：向量索引一路當主角
turbopuffer 在 2023 年以「無伺服器向量資料庫」之姿問世。當時的設計哲學很單純：向量搜尋就應該用一個專門打造的極佳向量引擎負責。物件儲存（object storage，例如 S3、GCS）當作資料真相來源，分層的 NVMe SSD 與 RAM 快取負責速度。
這樣的取捨被早期客戶驗證了，包括 Cursor 與 Notion。
後來客戶要求加屬性篩選與 BM25 全文搜尋，於是 v2 加入了反索引（inverted index），把屬性值對應到 ANN 位址。但儲存架構沒變：ANN 仍然是目前所有索引與查詢計劃圍繞的核心軸。
這個設計讓 GROUP BY 與聚合（aggregation）這類非向量查詢受限。turbopuffer 在這個向量優先的架構上撐到了極限：單一索引可以裝下 1000 億個向量、在 1000+ QPS 下維持 200ms 的 p99 讀取延遲。
但有問題。
三個具體瓶頸
儲存放大
目前每份文件的所有內容都放在它的 ANN 位址底下。如果文件只有一個向量，非向量資料只會與向量一起被存一次。但如果文件有多個向量（像是文件巢狀或 late interaction 這類多向量表示），所有非向量內容都必須為每個向量各複製一份。這是 turbopuffer 文件中「每個命名空間最多向量欄位數」限制的由來。
寫入放大
任何文件被插入、更新或刪除時，SPFresh 可能會重新平衡（rebalance）整個向量群，以確保叢集品質不退化。問題是，因為整份文件都是用向量的 ANN 位址當作鍵，這個重新平衡會把所有文件內容、以及所有相關的反索引（屬性與 FTS）都連帶搬動。改一個向量，背後可能會牽動一大串搬運工作。
向量化受限
因為資料布局不是針對屬性查詢做最佳化，向量化技術（vectorization，例如 SIMD 或平行掃描）在很多查詢計劃下用不上。
RIP, primary vector index
「The solution to these problems is simple: don’t key on the ANN address.」 解法很簡單：不要用 ANN 位址當鍵。
這正是 turbopuffer v3 做的事：換掉主索引結構，把 ANN 降為「另一個次級索引」。
這個改動一點也不簡單。v3 是全新的基礎，要讓所有查詢計劃的效能都獲得顯著提升。turbopuffer 透露 v3 的 CI 100% 通過了，接下來要開始「效能研磨」階段，公開釋出基準測試數字，朝效能打平甚至超越現有版本推進。
為什麼這件事重要
向量資料庫是這一波生成式 AI 浪潮的基礎建設。2023 到 2025 年，每家 AI 應用廠商幾乎都會問：「要選 Pinecone、Qdrant、Weaviate、Milvus，還是 pgvector？」現在做出這個關鍵基礎架構設計的廠商（Cursor 與 Notion 用的同一個底層）親口說：「向量不該當主角。」這不只是某家公司的內部改版，而是整個賽道的方向訊號。
幾個值得注意的點：
- RAG 不是向量資料庫唯一用途。很多 RAG 工作負載已經把 BM25、屬性、regex、聚合查詢全部摻在一起用。從一開始就讓向量索引當主索引，等於把整個查詢引擎綁在向量叢集品質的穩定度上。
- 物件儲存原生設計的極限測試。turbopuffer 是「object storage-native」派的代表，意思是把物件儲存當成真相來源、用 NVMe 與 RAM 做快取。如果連這個派別都要改主索引，代表「向量優先」的設計哲學在規模實踐時真的撐不住。
- HN 熱度：這篇文章在 Hacker News 拿下 301 點、82 則留言，工程師社群的核心討論圍繞在「為什麼不該把 ANN 當主索引」以及「物件儲存原生設計的真實取捨」。
這篇報導本質上是 turbopuffer 的內部技術回顧，把他們如何從向量優先的架構走到「向量只是另一個次級索引」的決定完整公開。它的價值在於讓所有正在自建或選用向量資料庫的團隊重新思考：你的資料模型，真的只有向量嗎？
數據解讀與質疑
幾個值得獨立查證與延伸思考的點：
- 效能承諾：turbopuffer 說 v3 會「在所有查詢計劃上顯著提升」，但同時也承認「現在還沒跟現有版本效能打平」。CI 100% 通過只是正確性達標，並不等於生產部署達標。從 CI 到對外服務，中間還有大量壓測、相容性測試、客戶案例驗證的工程。
- 100B+ 向量、200ms p99 這個基準是 2026 年 5 月 ANN v3 文公佈的數字。把它當作業界標竿合理，但要記得這是 turbopuffer 自己的測試環境數字，不是跨廠商獨立基準。獨立驗證的版本還沒出現。
- 「RIP vector database」這個標題有行銷味。整篇內容其實在講的是 turbopuffer 自己產品的內部架構變更，並不是宣告向量資料庫這個類別死亡。Pinecone、Qdrant、Weaviate 這類廠商都還在、也都還在出產品。「RIP」是內部轉型的儀式感，不是給同業開的訃聞。
相關影片
Siami 後續追蹤清單
- turbopuffer v3 公開基準測試數字（他們承諾會在
/v3進度頁持續更新） - 其他向量資料庫廠商（Pinecone、Qdrant、Weaviate）是否也跟進「向量只是次級索引」的架構
- Notion 與 Cursor 兩個早期客戶在 v3 部署後的實際體驗
參考資料