turbopuffer v3 to run every query through a fully vectorized pipeline

October 26, 2026Source: turbopuffer

turbopuffer says that when v3 reaches production later this year, every query will run through an end-to-end vectorized pipeline. According to the company, this would make it the first and only search engine to adopt fully vectorized execution, an architecture more commonly found in analytical databases.

Key points

turbopuffer says v3 will run every query through an end-to-end vectorized pipeline.
The company claims, to its knowledge, that it will be the first and only search engine with fully vectorized execution.
Production release is planned for later this year, according to the company.
The post contrasts the approach with the older Volcano model, which pulls rows one at a time.
No benchmark numbers are given in the available text.

What turbopuffer is promising

In a post dated October 26, 2026, engineer Adrien Grand wrote that turbopuffer v3 will use vectorized execution for all queries when it goes to production later this year. The company states that, "to our knowledge", this makes turbopuffer the first and only search engine to take this approach. The claim is the company's own and the source does not offer independent verification.

The post argues that the design suits current hardware. According to turbopuffer, modern CPUs reward predictable, batch-oriented access patterns, and search is evolving beyond narrow retrieval mechanisms. The company says vectorized execution makes the best use of hardware, so v3 can deliver very strong performance on many types of queries. The excerpt does not include benchmark figures, so the performance claim is not quantified.

From the Volcano model to vectorized execution

The post sets out the background by describing how query engines have evolved. Historically, database query processing used the Volcano model, which organizes execution as a pipeline of generic operators. In this model, each operator implements a generic function to pull rows one at a time from its children.

To illustrate, the post uses a simple query: SELECT sum(price) FROM product WHERE price <= 32. A possible plan has three operators:

SequentialScan scans the product table to produce its rows.
Filter drops rows that do not match price <= 32.
Aggregate accumulates the sum on the surviving rows.

The post then walks through an example table with four products priced at 128, 32, 16 and 32. Processed row by row, the 128 row is dropped by the filter, and the remaining values add up step by step to a sum of 80. The excerpt then begins a second walkthrough that uses a narrower table with only name and price columns, but the available text cuts off before the vectorized approach is fully explained.

What it means for users

The source is an early look at an upcoming release rather than a launch. turbopuffer has set up a page for readers to follow v3 progress, and gives only a timeframe of later this year for production availability. The excerpt provides no pricing, no detailed release date and no measured speedups.

For teams that rely on turbopuffer for search, the stated goal is stronger performance across many kinds of queries, not only a single retrieval type. How large the gains will be remains to be shown once v3 ships and results can be tested.