ハクソク

世界を動かす技術を、日本語で。

さようなら、ベクターデータベース

2026年10月2日原文(turbopuffer.com)

概要

turbopuffer v3 はストレージアーキテクチャを刷新し、検索性能を大幅に向上。 ANNインデックス を主軸とした従来設計から脱却し、柔軟なクエリプランを実現。 ストレージ・書き込み・ベクトル化 の各面でボトルネックを解消。 SQLクエリや多様な検索 への対応力を強化。 今後、 パフォーマンスベンチマーク も公開予定。

turbopuffer v1からv3への進化

  • turbopuffer v1 は、IDとベクトルのみで構成されるドキュメント設計
    • オブジェクトストレージを真実のソースとし、NVMe SSD/メモリキャッシュで性能を確保
    • SPANNからSPFreshへ移行し、インクリメンタルインデックスに対応
    • ANN（Approximate Nearest Neighbor）インデックスを主軸としたクラスタリング構造
  • v2 で属性フィルタリング・全文検索（BM25）を追加
    • 属性値をANNアドレスにマッピングする倒立インデックスを実装
    • ドキュメント属性もID・ベクトルと共に保存
    • FTS（Full Text Search）では、BM25スコア算出用のメタデータも保持
  • v2以降、集計・正規表現・ファジーマッチ・スパースベクトル検索など多様なクエリエンジンを追加

ANNプライマリインデックスの課題

  • ストレージ増幅
    • マルチベクトルを持つドキュメントでは、非ベクトルデータが複数回保存されるため、ストレージ効率が低下
  • 書き込み増幅
    • SPFreshによるクラスタ再編成時、関連する全データ・インデックスも移動が必要
    • 1つのベクトル更新で数百の属性・インデックスが移動し、書き込み負荷が増大
  • ベクトル化の制約
    • クエリエンジンは最適なブロックサイズで処理したいが、ANNインデックス構造により制限
    • 例：全文検索のポスティングリストも初期はANNクラスタ境界で分割され、効率低下

v3でのアーキテクチャ刷新

  • ANNアドレスをプライマリキーとしない 構造への転換
    • ドキュメント単位でフラットに管理し、ANNはセカンダリインデックス化
    • すべてのクエリプランで最適なストレージ・ブロック設計が可能
  • パフォーマンス・スケーラビリティの向上
    • ストレージ・書き込み・ベクトル化の各課題を解消
    • SQLクエリや複雑な集計処理にも柔軟に対応
  • 開発進捗
    • v3のCIが100%パスし、今後パフォーマンス最適化へ移行
    • ベンチマーク結果も順次公開予定

turbopufferの現状と今後

  • 1兆件超のドキュメント管理、毎秒1,000万件超の書き込み、毎秒25,000件超のクエリ処理 を実現
  • v3でさらに多様なユースケース・高速検索をサポート
  • 今後もパフォーマンス向上・機能拡張を継続予定

まとめ

  • turbopuffer v3 は、ベクトル検索だけでなく、 全文検索・属性検索・SQLクエリ まで幅広く高速化
  • ストレージ設計の根本的な見直し により、今後の成長と新機能追加の基盤を構築
  • パフォーマンス改善の進捗も積極的に公開予定
  • Cursor・Notion・Linear など著名サービスでの実績
  • turbopufferは、今後も信頼できる 次世代検索基盤 として進化

Hackerたちの意見

この書き込みの増幅はかなり大きくて、インデックスのスループットを調整する努力が、効果が薄れてきてるんだ。 > ANNアドレスにこだわらないで。これがまさにturbopuffer v3が行う変更なんだ。想像できると思うけど、簡単な変更じゃないよ。これはPostgresとMysqlがインデックスを構築する方法と直接的に並行してる。君のデザイン選択はPostgresのデザインパターンからMysqlのものに変わったんだ。違いは、再インデックスのコストとルックアップのコストだ - Postgresはルックアップに最適化されていて、Mysqlは書き込み時のインデックスに最適化されてる。もっと正確に言うと、Postgresは良いスキーマデザインを使った場合に優れていて、Mysqlは同じテーブルに多くのインデックスが存在するような悪いデザインに最適化されてる。Postgresは常にインデックスをPostgres内の行IDにポイントさせていて、これは各更新時に変わる任意の値なんだ。Mysqlは、ストレージエンジンがプラグイン可能だと仮定して、プライマリインデックスエントリにポイントして、ルックアップに追加の間接参照を加えるんだ。つまり、Mysqlのインデックスは安定したIDにポイントするから、行のプライマリキーを更新しない限り、データに対して行ったすべての属性ルックアップのインデックスを更新する必要はないってこと。最近はあまりデータベースを扱ってないけど、NIMBLEファイルフォーマットのデザインにはこの特定のアイデア（ワイドテーブル）に関連する quirks がたくさんあるよ。でも、PostgresからMysqlに切り替えてインデックスの増幅を防ぐっていう古いUberの投稿は、この投稿に直接的に反映されてる。 [1] - https://www.uber.com/us/en/blog/postgres-to-mysql-migration/

└

Mysqlは悪いデザインに最適化されてた TIL、ずっとMysqlを使うべきだったな。

└

LLMの出力を引用して、それに反応してる人たちを見るのが面白い。元の著者たちがLLMに返事をもらえるといいな。

└

あなたのデザイン選択はPostgresのデザインパターンからMySQLのものに変わったね。違いは再インデックスコストとルックアップコストだよ。Postgresはルックアップに最適化されてて、MySQLは書き込み時のインデックスに最適化されてる。もっと正確に言うと、Postgresは良いスキーマデザインを使った結合に強くて、MySQLは正規化が少ない悪いデザインに最適化されてるから、同じテーブルに対して多くのインデックスが存在する。MySQLはインデックスがたくさんあるときは確かに良いけど、全体的なPostgresのアーキテクチャが良いスキーマデザインで優れてるってのは同意できないな。セカンダリインデックスがプライマリキーを指すことで、アンロギングみたいなことができるから、バキュームの必要がなくなるんだよね。バキュームはPostgresの中で一番面倒な部分だから。それに、プライマリキーのインデックスはほとんどキャッシュされるから、間接的なコストは最初に思うほど大きくないよ。

└

MSSQL（クラスタインデックス）やOracle（インデックス組織テーブル）なんかは、状況に応じて選べるからいいよね。PGに真のクラスタインデックスがないのは、MSSQLから来た身としては寂しいな。アクセスの大半がプライマリインデックスに集中する時に、インデックスルックアップからタプルルックアップへの間接的なコストを避けられるし、それが唯一のインデックスならスペースも節約できるからね。

マルチベクタの重複の件は納得できる。各ベクタごとに属性を一度コピーするだけで、すぐに膨れ上がるからね。新しいプライマリインデックスは何？

└

自動生成された内部ID：（セグメントID、ドキュメントID）。ユーザーが提供したプライマリキー（ドキュメント内のidというフィールド）は、ストレージ層でセカンダリインデックスに変わるんだ。

ベクターデータベースは、ベクターやデータストレージよりも取得に関するものだった。だけど、その用語があまりにも定着しちゃって、企業はちょっと長くそれにこだわってたね。ごめんね :)

└

それってただの検索エンジンじゃん。でも、今やElasticsearchやVespaみたいな伝統的なプレイヤーとも競争しなきゃいけないし、価格やパフォーマンス、機能、あとは「AI」って何回言えるかみたいな属性で勝負しなきゃならないよね。

RAGパイプラインについてはあまり詳しくないけど、誰かデータベースをニューラルネット自体にしようとしたことある？つまり、伝統的なデータベースを排除して、基本的にオートエンコーダーみたいなものにするってこと？

└

ある意味では、似たようなことをするデータベース圧縮スキームがあるかもしれないね。たいていの人は忠実度にこだわりすぎるけど。

ベクタープライマリインデックスの問題 トップKではこれをずっと前に気づいて、ゼロから柔軟なサーバーレス検索エンジンを構築したんだ。密な/疎なベクター、遅延インタラクション、レキシカル検索、インデックス付き正規表現、フィルタリング、カスタムスコアリングを1つのクエリでサポートしてる。 - https://www.topk.io/blog/vector-dbs-are-the-wrong-abstractio... - https://www.topk.io/blog/topk-embed-v1

Hacker Newsで議論の続きを見る