検索基盤の話は、一見すると地味です。けれど、裏側の設計が変わると、検索の速さだけでなく、できることの幅まで変わります。turbopufferはまさにそこをいじり始めました。ベクトル検索を売りにしてきた同社が、次の版では「ベクトルを主キーにしない」構造へ移ると宣言したのです。単なる内部改修ではなく、製品の性格そのものを変える話だと思います。
turbopufferは、検索基盤のストレージ設計を大きく変えると発表した。新しい版である turbopuffer v3 では、文書とインデックスの配置、書き込み、圧縮、クエリの扱い方まで見直す。狙いは単に vector search を速くすることではない。text search、regex search、そして将来的にはより多くの SQL クエリまで、全体を速くする土台を作ることにある。
このサービスは最初、serverless vector database として始まった。オブジェクトストレージを真実の保管場所にし、NVMe SSD とメモリの階層的なキャッシュで速度を出す設計だった。初期の利用者としては Cursor や Notion が挙げられている。その後 v2 では text search と regex search が強化され、Linear の同期エンジンのような検索以外の用途にも使われるようになった。ただし、内部のストレージ構造は長く変わらず、ANN vector index（近似最近傍探索のためのインデックス）が「主役」のままだった。
記事はまず、その設計の歴史を振り返る。v1 の文書は「ID と vector だけ」だった。ベクトルはクラスタにまとめられ、そのクラスタ自体もさらに上位のクラスタにまとめられる木構造で管理される。各データは ClusterId と LocalId の組み合わせ、つまり ANN address で管理される。v2 ではここに属性フィルタリングと全文検索が加わった。属性検索は、値から ANN address へ引く inverted index として実装され、全文検索では BM25 に必要な term count と document length も持つようにした。さらに aggregation、regex search、fuzzy matching、sparse vector search、attribute ordering なども、同じ vector-primary の土台の上に載せてきた。
ただ、この構造には限界がある。記事が挙げる問題は3つだ。第一に storage amplification。文書の内容が ANN address に紐づいているため、複数 vector を持つ表現では中身を何度も複製しなければならない。第二に write amplification。ベクトルの再配置が起きると、文書本体だけでなく、それを参照する属性インデックスや全文検索インデックスまで連鎖して動く。ベクトル1つの更新で、何百もの属性や索引が動くこともあるという。第三に limited vectorization。現代のクエリエンジンは、まとまった塊で処理したほうが速いが、今の設計ではクエリごとの最適な塊の大きさを選びにくい。たとえば FTS v1 では posting list が ANN のクラスタ境界に縛られ、中央値の block は約1.5 postings しかなかった。そこで v2 では固定の約256件ブロックに再設計し、インデックスは10倍小さく、クエリは最大20倍速くなった。
turbopufferは、ANN 主体の設計を限界まで押し進めたが、もうこれ以上は無理だと判断した。v3 では ANN address を主キーにしない。ANN は「二次インデックスのひとつ」になる。すでに CI は 100% 通っていて、今はまず正しさを固めた段階だという。これからはベンチマークを公開しながら、性能が同等になるところを超えて、実運用への展開を進めていく方針だ。
この発表で面白いのは、turbopufferがベクトル検索を捨てるわけではまったくないことだ。むしろ逆で、ベクトル検索を続けるために、ベクトルを中心に置くのをやめる。ここには、かなり成熟したプロダクトの匂いがあると思う。最初の設計は、ある一点に全力を振るときには強い。でも製品が広がると、中心に置いていた要素が今度は足かせになる。検索エンジンやDB系サービスでは、ままある話だ。
とくに気になったのは、storage amplification と write amplification を正面から問題にしている点だ。高速化の話はたいてい「新しいアルゴリズムで速くなりました」で終わる。だが実際には、速度の差を決めるのはアルゴリズムより、どの単位でデータを持ち、どの単位で更新するかだったりする。turbopufferはそこを隠さず、文書と索引の置き場所そのものを変えると言っている。これはかなり本質的な変更だと思う。
記事には、単一インデックスで 100B+ vectors、p99 200ms、1k+ QPS という数字が出てくる。ここまで動いているものを壊してまで作り直すのは、普通の企業なら相当怖いはずだ。しかも ANN は object storage 上でうまく動いてきた実績がある。だからこそ、v3 は「理屈としては正しい」だけでは進めない案件になる。
この点で、まず correctness を固め、次に performance を詰めるという進め方は筋がいい。先に速さを追いかけると、どこかで既存の ANN 性能を落としやすい。しかもユーザーから見ると、検索が少し速くなる代わりに、今まで通りの recall や安定性が崩れるなら意味がない。turbopufferはその危険をよく分かっているように見える。だから CI 100% を通した段階で公開し、ベンチマークも外に出すと言っているのだろう。自信があるというより、作り変えの難しさを隠していない印象だ。
もうひとつ興味深いのは、vectorization の話をかなり早い段階で持ち出していることだ。DuckDB は 2,048 行単位、ClickHouse は約 65k、Lucene の posting block は 256 docs といった例を並べ、「計算を効率よく回すには塊が必要だ」と説明している。要するに、CPU をうまく回すには、検索データの置き方そのものが重要だということだ。
ここでの本質は、ANN のクラスタサイズが小さいことそのものではないと思う。問題は、クラスタサイズが他のクエリにまで強制されることだ。全文検索のように 256 件単位で回したい処理と、集計のようにもっと大きな塊で回したい処理が、同じ設計に縛られている。v2 の FTS 改修で 10倍小さく、20倍速くできたのなら、なおさら「土台が違えば、まだ伸びる余地がある」という判断になるはずだ。turbopuffer v3 は、その余地を取りにいく改修に見える。
記事は、v3 が「多くの SQL queries」を fast にする基盤になるとも述べている。ここはかなり重要だと思う。ベクトル検索専業の話に見えて、実際にはもっと広いデータベース競争に向かっているからだ。検索、全文、regex、集計、フィルタ、そして SQL 的な問い合わせまで、全部をひとつの基盤で扱えるなら、使いどころは一気に増える。
ただし、ここには期待と同時に難しさもある。検索エンジンの設計で SQL を速くするのは簡単ではない。SQL は自由度が高いぶん、最適化の逃げ道も多いからだ。だから v3 の価値は、「何でもできる」ことより、いろいろなクエリをそれぞれの形に合わせて回せることにあるのだと思う。ベクトルを主役から外すのは、そのための第一歩だろう。turbopufferは、検索エンジンから広めの query engine へ、少しずつ名前の通りの領域を広げているように見える。
