turbopuffer v3 schickt jede Abfrage durch eine vollständig vektorisierte Pipeline
Wenn v3 noch in diesem Jahr in den Produktivbetrieb geht, läuft laut turbopuffer jede Abfrage durch eine durchgängig vektorisierte Pipeline. Damit wäre das Unternehmen nach eigenen Angaben die erste und einzige Suchmaschine mit vollständig vektorisierter Ausführung, einer Architektur, die man bislang eher von analytischen Datenbanken kennt.
- turbopuffer sagt, v3 werde jede Abfrage durch eine durchgängig vektorisierte Pipeline schicken.
- Das Unternehmen behauptet, nach eigenem Wissen die erste und einzige Suchmaschine mit vollständig vektorisierter Ausführung zu sein.
- Die Produktivschaltung ist laut Unternehmen noch in diesem Jahr geplant.
- Der Beitrag stellt den Ansatz dem älteren Volcano-Modell gegenüber, das Zeilen einzeln abruft.
- Im vorliegenden Text werden keine Benchmark-Zahlen genannt.
Was turbopuffer verspricht
In einem Beitrag vom 26. Oktober 2026 schreibt Entwickler Adrien Grand, turbopuffer v3 werde bei der Produktivschaltung noch in diesem Jahr für alle Abfragen vektorisierte Ausführung nutzen. Das Unternehmen erklärt, turbopuffer sei damit „nach unserem Wissen“ die erste und einzige Suchmaschine mit diesem Ansatz. Die Aussage stammt vom Unternehmen selbst, die Quelle liefert dafür keine unabhängige Bestätigung.
Der Beitrag argumentiert, das Design passe zur aktuellen Hardware. Laut turbopuffer belohnen moderne CPUs vorhersehbare, stapelorientierte Zugriffsmuster, und die Suche entwickle sich über enge Retrieval-Mechanismen hinaus. Vektorisierte Ausführung nutze die Hardware am besten aus, sodass v3 bei vielen Abfragetypen sehr hohe Leistung liefern könne. Der vorliegende Auszug enthält keine Benchmark-Werte, die Leistungsaussage ist also nicht beziffert.
Vom Volcano-Modell zur vektorisierten Ausführung
Als Hintergrund skizziert der Beitrag die Entwicklung von Abfrage-Engines. Traditionell nutzte die Abfrageverarbeitung in Datenbanken das Volcano-Modell, das die Ausführung als Pipeline generischer Operatoren organisiert. Dabei implementiert jeder Operator eine generische Funktion, um Zeilen einzeln von seinen untergeordneten Operatoren abzurufen.
Zur Veranschaulichung dient eine einfache Abfrage: SELECT sum(price) FROM product WHERE price <= 32. Ein möglicher Plan besteht aus drei Operatoren:
- SequentialScan durchsucht die Tabelle product und liefert deren Zeilen.
- Filter verwirft Zeilen, die nicht price <= 32 erfüllen.
- Aggregate summiert die übrig gebliebenen Zeilen auf.
Der Beitrag geht dann ein Beispiel mit einer Tabelle durch, die vier Produkte zu den Preisen 128, 32, 16 und 32 enthält. Bei zeilenweiser Verarbeitung fliegt die Zeile mit 128 durch den Filter raus, die übrigen Werte addieren sich Schritt für Schritt zur Summe 80. Der Auszug beginnt anschließend ein zweites Beispiel mit einer schmaleren Tabelle, die nur die Spalten name und price hat, bricht aber ab, bevor der vektorisierte Ansatz vollständig erklärt wird.
Was das für Nutzer bedeutet
Die Quelle gibt einen frühen Einblick in eine kommende Version, keine Markteinführung. turbopuffer hat eine Seite eingerichtet, auf der Interessierte den Fortschritt von v3 verfolgen können, und nennt für die Produktivverfügbarkeit lediglich den Zeitrahmen „noch in diesem Jahr“. Preise, ein genaues Veröffentlichungsdatum oder gemessene Geschwindigkeitsgewinne enthält der Auszug nicht.
Für Teams, die turbopuffer für die Suche einsetzen, lautet das erklärte Ziel mehr Leistung bei vielen Abfragearten, nicht nur bei einem einzelnen Retrieval-Typ. Wie groß die Verbesserungen ausfallen, muss sich zeigen, sobald v3 erscheint und Ergebnisse getestet werden können.
turbopuffer: The first search engine with fully vectorized query execution
