Turbopuffer v3 begräbt den primären Vektor-Index - Architektur-Leaktion für RAG

Turbopuffer, die Serverless-Suche hinter Cursor, Notion und Linear, begraeibt in Version 3 seine ursprüngliche Kernarchitektur: den primären Vektor-Index. Das Engineering-Team erklärt im Blog ausführlich, warum - und das ist eine Lektion für jeden, der RAG- oder Suchsysteme plant.

Vektor-primale Architektur und ihre Kosten

Seit v1 lag bei turbopuffer alles an der “ANN-Adresse” (Cluster-ID plus Lokal-ID) des Vektors: Dokumentinhalte, Attribut-Inverted-Index, BM25-Postings. Drei Probleme entstehen aus diesem Design:

• Storage-Verstärkung: Multivektor-Dokumente (Chunking, Late Interaction) duplizieren sämtliche Inhalte pro Vektor - Ursache etlicher Plattform-Limits
• Write-Verstärkung: SPFresh-Rebalancing verschiebt ganze Dokumente samt Inverted-Indizes; ein einziger Vektor-Update kann hunderte Attribute bewegen
• Blockierte Vektorisierung: Cluster von 100-200 Dokumenten bestimmen die Blockgröße aller Abfragepläne - DuckDB arbeitet mit 2.048er-Blöcken, ClickHouse mit rund 65.000, Lucene mit 256

Den Beweis, dass Separation lohnt, brachte FTS v2: Postings in festen 256er-Blöcken machten den Index 10x kleiner und Queries bis zu 20x schneller.

v3: ANN wird nur noch ein Sekundärindex

Die Lösung ist simpel und radikal: nicht mehr nach ANN-Adresse keyen. Die Vektorsuche wird “nur noch ein” Sekundärindex neben Attribut- und Fulltext-Strukturen. Die CI läuft inzwischen zu 100 Prozent auf v3; die Benchmarks veröffentlicht das Team während der Optimierung öffentlich und rückblickend - ein selten transparenter Einblick in Suchmaschinen-Reengineering.

Quelle: turbopuffer Blog