Turbopuffer v3 引入新架構，將向量視為次級索引而非主鍵，藉此大幅降低寫入放大效應。此設計透過將向量搜尋與主要資料儲存解耦，旨在最佳化索引吞吐量。該方法挑戰了向量資料庫的主流設計，為搜尋速度與寫入效率的權衡提供潛在解決方案，並為 AI 基礎設施從業者提供更具擴展性且具成本效益的替代方案，特別適合大量資料匯入場景。其架構類似於 Postgres 和 MySQL 建立索引的方式，以重索引成本為代價來最佳化查詢成本。此外，系統利用物件儲存實現預設的強一致性，並允許透過最終一致性來降低冷啟動延遲。
事件背景
向量資料庫是專門用於儲存和查詢高維向量嵌入的系統，常見於語意搜尋和推薦引擎等 AI 應用。這些系統中的一個主要工程挑戰是管理寫入放大效應，即複雜的索引結構在資料更新時需要大量的計算開銷。傳統的向量資料庫通常將向量作為主鍵，這在處理高吞吐量寫入操作時可能會導致效能瓶頸。
社群觀察
社群成員指出其與傳統 SQL 資料庫的相似性，認為 Turbopuffer 從類似 Postgres 的設計模式轉向類似 MySQL 的模式。使用者也欣賞其與 LanceDB 方法的相似之處，即 ANN 索引是次級的且不移動資料列，同時也有人指出「向量資料庫」這個術語本身可能正成為過時的抽象概念。
